Mysterieuze programmeertaal Duqu blijkt 'C-dialect'

Een module van de Duqu-trojan die volgens Kasperky Lab in een onbekende programmeertaal was geschreven, zou gebaseerd zijn op een objectgeoriënteerd C-dialect. De module is gecompileerd met de Microsoft Visual Studio Compiler 2008.

Kaspersky Lab vroeg onlangs de hulp van programmeurs om te kunnen bepalen in welke programmeertaal een module van de Duqu-trojan was geschreven. Deze payload-module zorgt voor het contact met een command and control-server. Hoewel de overige onderdelen in C++ waren geschreven en met behulp van de Microsoft Visual C++ 2008-compiler gecompileerd waren, kon het Russische beveiligingsbedrijf niet achterhalen in welke taal de module was geschreven.

Inmiddels zegt Kaspersky Lab dat de programmertaal is geïdentificeerd dankzij de input van lezers. Volgens een aantal programmeurs zou de code geschreven zijn in 'OO C', een objectgeoriënteerd dialect van de C-programmeertaal. Ook zou de binary aanwijzingen bevatten dat de Microsoft Visual Studio Compiler 2008 zou zijn gebruikt voor het compileren van de betreffende Duqu-module.

Kaspersky Lab meldt dat het na diverse tests met de Visual Studio Compiler 2008 in combinatie met een aantal flags code heeft geproduceerd die vergelijkbaar is met de 'mysterieuze' Duqu-module. De extra parameters die werden gebruikt zouden compactere code opleveren.

Volgens de beveiligingsonderzoekers kan met de keuze voor het C-dialect gesteld worden dat de ontwikkelaars een old school-programmeermethode hebben gebruikt die niet vaak wordt toegepast door malware-schrijvers. De objectgeörienteerde benadering zou vooral binnen commerciële software gehanteerd worden. Ook de keuze voor C in plaats van het modernere C++ zou wijzen op programmeurs met een behoudende wijze van programmeren. Verder zou de keuze voor C als voordeel hebben dat de geschreven broncode van de malware ook relatief eenvoudig voor andere platformen gecompileerd kan worden, zodat malware die bedoeld is voor servers of mobiele-besturingssystemen snel opgeleverd kan worden.

Reacties (42)

[johnbetonschaar]

Volgens de beveiligingsonderzoekers kan met de keuze voor het C-dialect gesteld worden dat de ontwikkelaars een old school-programmeermethode hebben gebruikt die niet vaak wordt toegepast door malware-schrijvers.

Waarschijnlijk omdat de meeste malware schrijvers zich op vrij gangbare desktop PC's richten, die over het algemeen over alle nodige runtimes zoals de Visual Studio C++ runtime beschikken, en het dus weinig zin heeft om moeilijk te gaan doen met een object-georienteerd framework geschreven in C.

De objectgeörienteerde benadering zou vooral binnen commerciële software gehanteerd worden

Dit vind ik een vreemde uitspraak, je zou verwachten (en dat is ook mijn ervaring) dat object-georienteerde commerciele software 'gewoon' met gangbare talen als C#, Java, C++ en Delphi (jaja het wordt nog steeds gebruikt) geschreven wordt, en niet met C plus een OO framework.

Ook de keuze voor C in plaats van het modernere C++ zou wijzen op programmeurs met een behoudende wijze van programmeren.

Object-georienteerd programmeren in C zou ik persoonlijk niet behoudend willen noemen maar vrij experimenteel. Waarom zou je jezelf allerlei beperkingen opleggen door C als taal te kiezen als je object-georienteerd wilt programmeren?

Verder zou de keuze voor C als voordeel hebben dat de geschreven broncode van de malware ook relatief eenvoudig voor andere platformen gecompileerd kan worden, zodat malware die bedoeld is voor servers of mobiele-besturingssystemen snel opgeleverd kan worden

Fatsoenlijk geschreven C++ code is net zo portable als fatsoenlijk geschreven C code, dus ook deze stelling volg ik niet helemaal.

Wat ik me zou kunnen voorstellen is dat de delen die op deze manier geschreven zijn wellicht ook op embedded systemen moeten kunnen werken waar je niet zomaar C++ met al zijn afhankelijkheden mee kunt linken. Voor veel embedded hardware zijn niet eens C++ compilers beschikbaar bijvoorbeeld. Wellicht wordt het bewuste stuk code voor meer gebruikt dan alleen in deze Duqu worm? Er waren toch ook hints dat Duqu en Stuxnet op de een of andere manier verwant waren aan elkaar? Stuxnet bevatte als ik me niet vergis onderdelen die op PLC's van uranium centrifuges moesten draaien, dus zo'n overweging lijkt me meer voor de hand liggen dan 'behoudende programmeurs' of iets dergelijks.

Volgens mij zou dit het framework moeten zijn trouwens:
http://sourceforge.net/projects/oocframework/

[Reactie gewijzigd door johnbetonschaar op 26 juli 2024 21:44]

[tofus]

Object-georienteerd programmeren in C zou ik persoonlijk niet behoudend willen noemen maar vrij experimenteel. Waarom zou je jezelf allerlei beperkingen opleggen door C als taal te kiezen als je object-georienteerd wilt programmeren?

De meeste C programmeurs die bewust object-georienteerde code in C schrijven, doen dat vaak omdat ze een taal als C++ te bloated en/of overbodig vinden. Of dit daadwerkelijk ook zo is, is natuurlijk een heel andere discussie, maar m.b.t. de uiteindelijke executable zie je inderdaad vaak dat C na compilatie vaak compactere en snellere code produceert dan functioneel overeenkomstige C++. Vandaar ook dat bijvoorbeeld de kernel van bijna elk modern OS in C is geschreven, terwijl de overige code (libraries, API's, etc.) waarbij compactheid en snelheid minder van belang zijn, vaak 'gewoon' in C++ worden geschreven.

Ik denk dat in dit geval met name de compactheid van de uiteindelijke executable hier van belang is geweest, en dan is C een logische keuze.

Maar dit is inderdaad allemaal vrij 'old-school', en zeker in een tijd waarin JavaScript-trojans ronddolen kan dit toch op z'n minst als 'behoudend' worden gezien.

[Verwijderd]

Waarschijnlijk omdat de meeste malware schrijvers zich op vrij gangbare desktop PC's richten, die over het algemeen over alle nodige runtimes zoals de Visual Studio C++ runtime beschikken, en het dus weinig zin heeft om moeilijk te gaan doen met een object-georienteerd framework geschreven in C.

Als je oplet wat je doet, kun je prima in C++ programmeren zonder runtimes nodig te hebben.

Object-georienteerd programmeren in C zou ik persoonlijk niet behoudend willen noemen maar vrij experimenteel. Waarom zou je jezelf allerlei beperkingen opleggen door C als taal te kiezen als je object-georienteerd wilt programmeren?

De theorie is dat je enorm op moet letten als je C++ programmeert welke code-paden er (onbewust) ontstaan. Neem bv. dingen als copy constructors e.d. Op zo'n manier zou je e.e.a. makkelijker onder controle kunnen houden. Maar ik deel die mening niet.

Fatsoenlijk geschreven C++ code is net zo portable als fatsoenlijk geschreven C code, dus ook deze stelling volg ik niet helemaal.

De theorie daarover was dat vroeger C++ nog niet fatsoenlijk gestandaardiseerd was.

[SKiLLa]

Het gaat erom dat er meer platformen zijn waarvoor alleen een C compiler beschikbaar is en niet een C++ compiler.; denk aan oudere (< 1990) legacy of exotische hardware platformen.

[Verwijderd]

De hele Linux kernel is OO in C. Zo vreemd is het niet maar je kunt je wel afvragen of het niet efficienter is om C++ te gebruiken. Moderne C compilers zijn echt heel goed in het optimaliseren!

[Zoijar]

Ik blijf het idee hebben dat dit gewoon een home-made DSL (domain specific language) is die naar C compileert. Dat het lijkt op een OO vorm van C wil niet zeggen dat het daar rechtstreeks in geschreven is. Als je een compiler voor een eigen taal schrijft is het vaak het makkelijkste om naar C te compilen zodat je vrij low-level code kan genereren en daarna bestaande C compilers kan gebruiken.

Maar goed, ik heb me eerlijk gezegd niet in dit geval verdiept, dus het is zo maar een gedachte...

[J.J.J. Bokma]

Kan, of een simpele preprocessor. Beiden zijn niet zo heel ingewikkeld te maken. Vrij verkrijgbare tools genoeg die dit in korte tijd mogelijk maken (denk 1 week).

[Pep7777]

Ze hebben het over OO-C, maar zou het niet "gewoon" objective C kunnen zijn.

Dat is nog steeds veel in gebruik en lijkt ook meer op "C" dan "C++".
(ik programmeer niet voor apple aparaten maar daar is Objective C geloof ik
zowat de standaard).

De programmeer omgeving voor Objective C heeft volgens mij genoeg libraries
en interne taal structuren om asynchroon programmeren mogelijk te maken.

Als dat zo is dan wordt alles gelijk een stuk minder "exotisch" (en minder romantisch).
En wat mij betreft waarschijnlijker. Niks groot geld/budget maar meer een kwestie
van goed libraries hergebruiken.

Een (C) compiler die flink optimaliseert kan iedere pointer (adres verwijzing/indirectie) in ieder daarvoor geschikt register gooien zodaning dat en de stack ontzien wordt en de registers zo min mogelijk van inhoud wisselen.

Wat denken jullie daarvan?

[J.J.J. Bokma]

Zoals in het eerste bericht hierover op Tweaker uitvoerig uitgelegd is (edit: in de reakties): een taal laat een bepaalde handtekening achter, en zo ook een compiler. Als die "gewoon" objective C was, had men dat allang gezien.

Gokken zonder kennis van zaken maken dingen niet waarschijnlijker. En het maken van dit soort dingen is echt niet zo heel ingewikkeld, er zijn tal van tools vrij beschikbaar die dit mogelijk maken (eigen C dialect maken, enz.). Zelfs met wat weinig Perl is een eenvoudige C pre-processor te maken. Verder is dit niet ongewoon, Qt gebruikt ook een eigen trukendoos: MOC

[Reactie gewijzigd door J.J.J. Bokma op 26 juli 2024 21:44]

[gimbal]

"blijkt 'C-dialect'"

Nee, het is gewoon C, maar dan met een onorthodoxe code architectuur. Visual C++ gaat niet magisch andere dialecten kunnen compileren.

[MSalters]

Jawel, dat doen het wel, als je een pre-processing stap gebruikt. MSBuild ondersteunt dat gewoon; zo hadden wij de FireFox IDL compiler geintegreerd. Onze *.idl files leverden .h files op, en die werden gewoon meegecompileerd.

Omdat je dan feitelijk twee stappen gebruikt, kun je aan de output niet zomaar herkennen welke stap de eerste was.

[Shyva]

Visual Studio Compiler 2008 compileert geen Objective C, dus als die bewering uit het artikel klopt, dan kan wat jij zegt sowieso niet.

[BadRespawn]

Niks groot geld/budget maar meer een kwestie van goed libraries hergebruiken.

Wat denken jullie daarvan?

Als er wel groot geld achter zit betekent dat toch niet dat er dan dus niet goed libraries hergebruikt worden?

Dat zegt op zich dus niets over of er wel of niet groot geld of groot belang achter kan zitten.

Duqu is nauw verwant aan Stuxnet, en Stux richt zich op nogal ongewone doelen. Ik kan wel ander partijen dan 'gewone hackers' bedenken die meer belang zouden kunnen hebben bij het saboteren van industriële machines, en dan nog wel de uranium opwerking in Iran.

Hoe waarschijnlijk is het dat Duqu niet is ontwikkeld door, en wordt ingezet door dezelfde partij die verantwoordelijk is voor Stuxnet?

[marino_centrino]

En waarom is het belangrijk om te weten om welke programmeertaal het gaat? Is het dan te 'decompilen'/'reverse engineeren'? (ben de juiste term even kwijt)

[Verwijderd]

first post ( en mijn andwoord ); volgens mij is het een stuk makkelijker om een heuristic fingerprint the maken as je de compiler weet welke gebruikt is.

[Morrar]

Lijkt me inderdaad vooral een kwestie van fingerprinten van varianten. Deze versie hebben we nu wel de fingerprint van, maar het wordt waarschijnlijk de basis van een hele reeks varianten. Met een paar aanpassingen kan de virusscanner weer een tijdje ontdoken worden, todat er weer een nieuwe vingerprint is en dan begint het spelletje weer opnieuw.

Als je weet hoe en waarin de malware gecompiled is, dan kun je in ieder geval beter doorrekenen hoe voorspelbare varianten eruit zullen zien. Met name omdat je dan weet welke stukken van de code bij de basis horen en welke waarschijnlijk zullen veranderen. Wordt er bijvoorbeeld van de ene exploit geswitched naar een andere, dan zal een deel veranderen. Een ander deel zal echter hetzelfde kunnen blijven (het stuk voor de MBR infectie of een watchdog om maar eens wat te noemen). Die basisdelen kun je dan sneller ontdekken. Tot slot zou je eventueel zelfs reverse engineering / decompiling toe kunnen passen om te zien welke taktieken worden toegepast (voor zover niet bekend).

Kortom, hoe de malware tot stand is gekomen kan zeker leerzaam zijn.

[Verwijderd]

Nee, het gaat niet om "heuristic fingerprinting". Het draait om het oplossen van het mysterie: wie heeft het gemaakt.

edit: modereer vooral maar omlaag. Virusscanners werken nu eenmaal niet zo, maar goed.

[Reactie gewijzigd door Verwijderd op 26 juli 2024 21:44]

[moreasy]

verklaar je nader, geef altijd argumentatie voor je bewering (ook al deel ik je mening), en dan zal men je post ook eerder als on-topic bestempelen.

edit:
sorry, je direct message staat uit dus vandaar hier een reactie.

[Icekiller2k6]

Um C is gewoon kleiner als je niet teveel exotische functies gebruikt.. een tool die ik ooit geschreven had was @ C++ een kleine 100kb groter dan wanneer ik het in C had geschreven..

Uiteraard moet je voordelen & nadelen afwegen maar grote kan ook een reden zijn voor het gebruik van "OO C" ipv "terughoudend" zijn..


toelichting:
Ik zou, als ik een malware schrijver was, het zo klein mogelijk proberen te houden.. al was het maar zodat de code sneller binnen was voor "slachtoffers" die een dialup hebben

[Reactie gewijzigd door Icekiller2k6 op 26 juli 2024 21:44]

[Keypunchie]

Ik snap je overweging, maar als malware schrijver boeit het nauwelijks om dial-up-gebruikers te infecteren.

Zeker voor DDoS en andere bot-doeleinden wil je graag degenen die een lekkere dikke pijp hebben en die 24/7 met het internet verbonden zijn.

[jGS]

Is typisch voor malware, hoe kleiner hoe liever hebben ze het. Ik heb nog broncode gezien van meerdere malware pakketten. Altijd vond je wel zaken terug die zorgen voor kleinere executables.

Ook after compile packers zijn erg populair bij malware. Enerzijds in de hoop van AV te bypassen, anderszijds om het kleiner te maken. Av bypassen met (private) packers lukt(e) een tijd erg goed

[SKiLLa]

Die 'executable packers' waar je het over hebt worden nog steeds gebruikt. Niet alleen levert het compactere files op, het verbergt ook de working-details en maakt analyse/tegenmaatregelen dus stukken moeilijker.

AVs in standaard-config omzeilen is nog steeds erg makkelijk; het hangt er meestal vanaf of de 'heuristische detectie van onbekende malware' aanstaat of niet. Staat dat uit (= default bij b.v. McAfee Enterprise) dan is het kinderlijk simpel.

Sterker nog, er valt een boel geld te verdienen door 'malware' undetectable te maken

[Verwijderd]

Je kunt niet zoiets stellen als dat C groter of kleiner zou zijn dan C++. Het zijn gewoon talen die in een uitvoerbaar bestand om te zetten zijn. Dat kan op verschillende manieren. In jouw geval werd er waarschijnlijk een of andere statische library aan vast geplakt.

[MSalters]

Mwah, ik heb een C++ programma in 4 kb weten te krijgen. Je kunt dus zeker niet zeggen dat C++ programma's 100 kb groter zijn; ik had de C code niet in -96kb gekregen

[Reactie gewijzigd door MSalters op 26 juli 2024 21:44]

[Wolfos]

Een C dialect dat met OOP werkt? Weten ze zeker dat het niet gewoon obfuscated C++ is?

[evolution536]

Dat zou inderdaad goed kunnen, maar als het obfuscated C++ is dan is de kans groter dat er meer runtime gebruikt wordt. een mogelijk C dialect lijkt me het meest voor de hand liggend.

[J.J.J. Bokma]

Ja, dat weten ze zeker.

Overigens obfuscated C(++) en een normaal C(++) programma kunnen prima dezelfde executable opleveren. Obfuscated is lastig te lezen voor mensen, maar een compiler zal het verder een worst wezen.

[Verwijderd]

Dan zou de calling convention anders zijn.

In C kan je wat OO werken, door function pointers te gebruiken in structs.

[ioor]

"old-school"..... wil dat zeggen dat de huidige generatie programmeurs niets meer mee krijgen over het hoe en wat de moderne talen ontstaan zijn?

Dat zou wel kloppen met de nieuwe generatie ICT-ers. Vraag daar maar 's aan om een dos-box te openen, of een paar regels basic te tikken

[hylke94]

Wij moeten anders in ons eerste jaar met assembly werken/programmeren. Dat is de basic waar de meeste (C/Java/enz.)compilers de code eerst in veranderen. En dos lukt ons ook wel.

[J.J.J. Bokma]

Niet zo heel erg vreemd. Hoeveel "old schoolers" hebben in Algol of Fortran geprogrammeerd of ooit een ponskaart vastgehouden? Ik niet.

[Verwijderd]

Het is zelfs zo erg, ik doe elektrotechniek en wij krijgen in ons eerste jaar de programmeer talen: Java, assembly, C. En ik heb een boek over Fortran en Unix systems basics in de kast staan xd.

[Verwijderd]

Voor de echte diehards is er een pdf met uitleg over Object Oriented C

www.planetpdf.com/codecuts/pdfs/ooc.pdf

[wvd_vegt]

Leuke leesvoer (was niet bekend met deze preprocessor)!

Je wordt alleen zwart voor je ogen van de sterretjes (erm pointers). En maar bliven duimen dat er geen fouten in zitten.

Na jaren emebbed C gedaan te hebben ben ik blij met embedded C++ (en zo min mogelijk pointers en een compiler die waarschuwingen kan & mag geven). Was even wennen en zoeken naar de juiste syntax.

[Allubz]

Nu heb ik hier weinig verstand van, maar betekent dit dat er makkelijk een heuristieke update voor mogelijk is, of juist moeilijker tegen te beveiligen is? Of maakt het niet uit?

[Verwijderd]

Heuristische fingerprinting is wel makkelijker as je de compiler weet lijkt mij.