'Duqu-trojan deels geschreven in onbekende programmeertaal'

Kaspersky Lab heeft na een analyse van de Duqu-trojan een onderdeel gevonden dat in een tot nu toe onbekende programmeertaal zou zijn geschreven. De Russische beveiligingsfirma vraagt daarom programmeurs om hulp.

De Duqu-trojan, dat is gespecialiseerd in het aanbrengen van een achterdeurtje op besmette systemen, is grotendeels identiek aan de code van Stuxnet, de malware die poogde scada-systemen van het Iraanse kernprogramma te saboteren. Na een grondige analyse van de code concludeert Kaspersky Lab dat een onderdeel dat contact maakt met een command and control-server, oftewel de payload-dll, in een onbekende programmeertaal is geschreven, terwijl de overige onderdelen bestaan uit C++-code en er gebruik is gemaakt van de Microsoft Visual C++ 2008-compiler. Kasperky sluit uit dat het 'mysterieuze' Duqu-onderdeel is geschreven in Python, Java, Objective C, Ada of Lua.

Volgens de Russische malware-onderzoekers is het mogelijk dat de Duqu-programmeurs een eigen framework hebben gebouwd om zelfgeschreven C-code met een eigen compiler te compileren of dat er een tot nu toe onbekende taal is ontwikkeld. Het 'Duqu-framework' blijkt bovendien zeer veelzijdig in zijn mogelijkheden. Zo kan de betreffende module op diverse manieren contact maken met de c&c-servers, onder andere via http, proxy servers en netwerk-sockets. Ook kan de module http-requests van de server afhandelen en is het in staat om buitgemaakte informatie door te sturen of nieuwe malware-code te injecteren op andere met Duqu besmette systemen binnen een netwerk.

Met de aanwijzingen dat de bouwers van de Duqu-malware een eigen programmeertaal hebben ontwikkeld, lijkt het niet ondenkbaar dat de betreffende programmeurs niet alleen zeer vakkundig waren, maar vermoedelijk ook over ruime financiële middelen beschikten. Verder sluit Kaspersky niet uit dat de c&c-module door een ander team is geschreven en pas later aan de overige Duqu-onderdelen is toegevoegd. Om het 'mysterie' rondom de c&c-module op te lossen, vraagt Kaspersky Lab om hulp van de ontwikkelgemeenschap.

Reacties (118)

[vanaalten]

Mijn programmeerkennis stamt nog uit de Commodore Amiga tijd - ietsje verouderd dus,
Wat ik mij afvraag: hoe kan je aan een binary zien in welke programmeertaal die geschreven is?

(er van uitgaande dat 'ie gestript is van onnodige debug-info natuurlijk)

[ktf]

Omdat een compiler bepaalde code op een bepaalde manier omzet. Een soort vingerafdruk van de compiler zeg maar. Als je weet welke compiler weet je natuurlijk ook welke taal. Daarom vind ik het ook sterk dat men het over een 'onbekende programmeertaal' heeft en de conclusie dat het directe assembler is blijkbaar al heeft uitgesloten? Die is ook niet zo te identificeren. Misschien heeft men wel de compiler alles om laten zetten naar assembler en gepoogd direct in assembler sporen te wissen in het C&C deel ofzo.

@elmuerte: dan herkent men dus ook niet nee, want daar kennen ze geen vingerafdruk van, maar dat kost erg veel tijd en is onwaarschijnlijk. Ongeveer zoiets (maar dan in afgeslankte vorm) bedoelt men met 'eigen framework'.

[Reactie gewijzigd door ktf op 27 juli 2024 10:15]

[Cergorach]

Ik zat ook te denken dat het direct in assembly is geschreven, dus was zeer benieuwd waarom ze dit hebben uitgesloten, dit zijn hun conclusies:

Conclusions

- The Duqu Framework appears to have been written in an unknown programming language.
- Unlike the rest of the Duqu body, it's not C++ and it's not compiled with Microsoft's Visual C++ 2008.
- The highly event driven architecture points to code which was designed to be used in pretty much any kind of conditions, including asynchronous commutations.
- Given the size of the Duqu project, it is possible that another team was responsible for the framework than the team which created the drivers and wrote the system infection and exploits.
- The mysterious programming language is definitively NOT C++, Objective C, Java, Python, Ada, Lua and many other languages we have checked.
- Compared to Stuxnet (entirely written in MSVC++), this is one of the defining particularities of the Duqu framework.

[Bigs]

Ze hebben over 'highly event driven architecture' en 'asynchronous communications'. Dat krijg je in pure assembly simpelweg niet voor elkaar.

[Anoniem: 178824]

Klassieke talen zoals Cobol, Fortran, Haskell of Pascal zijn ook nog mogelijk. Vooral voor industriele frames wordt dit nog steeds toegepast. Zeker gezien de oorsprong van het virus lijkt me dat geen vreemd uitgangspunt.

(overigens wordt niet uitgesloten dat het wél in C geschreven is, maar dan zonder een bekend framework)

[Reactie gewijzigd door Anoniem: 178824 op 27 juli 2024 10:15]

[J.J.J. Bokma]

"Haskell .... nog steeds" Sinds wanneer is Haskell antiek ? ;-). Verder, voor Haskell zal er de nodige code meegelinkt moeten worden, die duidelijk herkenbaar is.

[Reactie gewijzigd door J.J.J. Bokma op 27 juli 2024 10:15]

[Anoniem: 178824]

antiek? Dat maak jij ervan. Ik zeg klassiek: zoals een taal die al een tijdje mee gaat. Deze talen worden zeer zeker nog gebruikt.

Ik heb de code zelf niet gezien dus geen idee wat het precies is maar juist vanwege het doelsysteem lijken mij deze 4 het handigste. Maar in hoeverre ze te herkennen zijn zou ik niet weten, het is zeker 15 jaar terug sinds ik iets gedaan heb met cobol en pascal.

[Reactie gewijzigd door Anoniem: 178824 op 27 juli 2024 10:15]

[J.J.J. Bokma]

Je hebt gelijk, ik las "antiek", maar het is klassiek. Maar goed, waarom is Haskell klassiek? Lijkt mij een beetje onzin om een taal die net iets meer dan 20 jaar oud is "klassiek" te noemen, zeker als een enorm groot deel van de programmeurs er nog nooit in geprogrammeerd heeft [1]. Zijn Perl en Python ook klassiek?

Qua zeer zeker gebruikt, ik denk dat je kan zeggen dat Haskell pas recent (de laatste 5 jaar of zo) aan een langzame opmars bezig is. Kortom, het lijkt mij extreem onwaarschijnlijk dat Haskell gebruikt is, ook omdat de runtime duidelijk herkenbaar zou moeten zijn (RTS). Dit sluit ook eigenlijk talen als Perl, Python, etc. uit. Elk heeft een redelijk grote runtime nodig (garbage collection, ondersteuning voor dynamische datastructuren, etc.).


[1] Ik toevallig wel, Miranda/Gofer, begin jaren 90. Ben ik nu een klassieke programmeur?

[Fireshade]

@ j.J.J. Bokma:
Ik denk niet dat Retrox 'klassiek' bedoelt met 'oud', maar meer in de trant van gevestigd/basis, zoals het adagium "Ken uw klassieken".
Uiteindelijk heeft het dus weinig met leeftijd te maken. Iets relatief nieuws kan al snel een klassieker worden, zeker in de IT wereld.

[Reactie gewijzigd door Fireshade op 27 juli 2024 10:15]

[J.J.J. Bokma]

Maar dan is het nog vreemder om met Haskell aan te komen zetten, ik denk niet dat je Haskell gevestigd noch basis kan noemen ;-).

[Anoniem: 174991]

Haskell, de taal waar 100x meer OVER dan IN geschreven is...

[Cergorach]

Uiteindelijk gaat een programmeertaal door een assembler en wordt het assembly, dus aan assembly ligt het niet. Wat jij bedoelt is dat het niet te doen is voor een programmeur, ik zou willen zeggen dat het niet te doen is voor de meeste programmeurs. De hoeveelheid programmeurs die een moderne assembler kunnen bouwen is ook niet al te groot...

[latka]

Onzin, de compiler zet high-level code in low-level assembly om. Alles wat jij in een hogere taal in elkaar knutselt kan een assembly guru in de helff van de ruimte en 2x zo snel qua runtime maken (afhankelijk van de kwaliteit van de compiler, maar MSVCC is nou niet direkt top-of-the-line qua compiler). Dat het ongebruikelijk is klopt wel, de meeste mensen zouden niet weten waar te beginnen als ze teruggeworpen worden qua platform en alles zelf moeten doen, neemt niet weg dat er genoeg hele slimme mensen rondlopen die dit nog leuk vinden ook (ik niet meer zo, heeft toch een hoog gehalte werkverschaffing).

[J.J.J. Bokma]

En dat laatste maakt een domein-specifieke taal waarschijnlijker ;-). Er zijn niet veel mensen die handmatig betere code op kunnen leveren dan een goede compiler en het vreet tijd.

[elmuerte]

En wat nou als ze hun eigen C compiler gemaakt hebben, bekende programmeertaal, maar onbekende compiler.

[J.J.J. Bokma]

Niet alleen heeft een compiler een vingerafdruk, maar ook een programmeertaal. Voor diverse programmeertalen zijn er afspraken hoe er met de stack omgegaan wordt, e.d. Dit om linken van object bestanden mogelijk te maken tussen programmeertalen. Zie: http://en.wikipedia.org/wiki/Calling_convention En zo zijn er meer voorbeelden. Bijvoorbeeld voor Perl zou men de Perl compiler/interpreter moeten bijsluiten in C code (kan), en zou men of Perl source terug moeten vinden, of zal men C code vinden die duidelijk diverse Perl afspraken volgt.

Verder is een eigen programmeertaal maken niet zo heel ingewikkeld, zeker niet als die specifiek voor een bepaald domein is (bijvoorbeeld alleen integer bewerkingen, eenvoudige datastructuren, enz.). De gereedschappen om dat soort dingen te doen zijn gratis en volop aanwezig.

Wellicht geen "direct assembly" omdat a) dat nogal wat veel werk is en b) ik aanneem dat de onderzoekers slim genoeg zijn om dat op het lijstje te plaatsen als dat een optie was. M.b.t. dat laatste: ik gok dat men een duidelijke calling convention gevonden heeft, maar dat deze afwijkt van de opgesomde talen.

[Reactie gewijzigd door J.J.J. Bokma op 27 juli 2024 10:15]

[blorf]

Het is relatief. Ik denk dat er daarom ook "other language / c framework" staat. Als je een constuctie maakt in c met pointers en directe hardwaretoegang, eventueel met blokken assembly erbij en vervolgens alle handelingen opdeelt in functies die met een zelfbedachte syntaxis worden aangeroepen heb je iets wat op een programmeertaal lijkt.
Daarna kan je die function-calls weer samenvatten dmv een andere zelfbedachte syntaxis en je hebt een programmeertaal die een level hoger is.

[J.J.J. Bokma]

C heeft pointers, en directe hardware toegang. En er zijn C compilers die inline assembly toestaan (zie bv. http://ibiblio.org/gferg/...ne-Assembly-HOWTO.html#s4 ).

Maar het maken van een domeinspecifieke taal is echt niet zo moeilijk. Het is een mooie opdracht voor een compiler vak aan een HTS/universiteit.

[freaq]

wat als men direct in assembly gewerkt heeft?
of kan dat niet in dit geval, hoedanook wel erg apart en toch interessant,
dit is dus echt geen standaard huis tuin en keuken virus, men wist dat het speciaal was maar zo geraffineerd had niemand verwacht denk ik.

[Anoniem: 174991]

Dat lijkt me onwaarschijnlijk. Het artikel claimt dat er sprake is van een event-driven en object oriented gedrag. Typisch kenmerken van hogere talen, hoger dan C zelfs.

Volgens mij wordt gebruik van Objective C (van Apple) niet uitgesloten. Er worden echter geen verwijzingen naar de standaard bibliotheek gemaakt en de compiler komt ook niet bekend voor. Dat maakt het onwaarschijnlijk of hoogst opmerkelijk.

Een van de suggesties is dat er een taal of framework is gebruikt dat zo is geimplementeerd dat deze naar C compileert. Dat is overigens niet ongebruikelijk: de meest gebruikte Python implementatie werkt ook zo. (onzin)
@onder: ik zit ernaast: CPython compileert naar Bytecode, niet naar C.

Wat ik zelf bijzonder vindt is dat er voor object-orientatie is gekozen. Dat was in jaren 90 het toverwoord, maar de ontwikkelaars van nieuwe talen lijken zich nu massaal of functionele en/of concurrent talen te werpen.

Tot slot wordt nergens de vraag gesteld WAAROM de schrijvers voor deze aanpak hadden gekozen. Verbetert dit de kans dat het virus onopgemerkt blijft? Is deze sowieso moeilijke te bestrijden omdat decompileren niet mogelijk is? Was het gewoon een hobby-ding van de virus-schrijvers? Ik ben benieuwd om iemand hierop durft te speculeren.

[Reactie gewijzigd door Anoniem: 174991 op 27 juli 2024 10:15]

[dtech]

Wat ik zelf bijzonder vindt is dat er voor object-orientatie is gekozen. Dat was in jaren 90 het toverwoord, maar de ontwikkelaars van nieuwe talen lijken zich nu massaal of functionele en/of concurrent talen te werpen.

OOP is de standaard van tegenwoordig, helemaal niet raar dus. Veelgebruikte/bekende talen van tegenwoordig: C#, Java, VB.NET, C++, Python, PHP en Javascript hebben allemaal volledige ondersteuning voor OOP en in de eerste twee kun je zelfs nauwelijks anders.

Nu OOP volwassen is en er weinig ontwikkeling meer op is kijkt men natuurlijk verder voor nieuwe mogelijkheden, maar voor algemene programmeertaken is OOP op dit moment juist keuze bij uitstek

[Anoniem: 174991]

Het verbaast me ook niet zozeer dat software geschreven is een object-georienteerde taal. Het verbaast me een beetje dat daarvoor gekozen is bij een schijnbaar nieuwe taal. Daar lijkt het hier namelijk om te gaan.

[zvbhvb]

Een van de suggesties is dat er een taal of framework is gebruikt dat zo is geimplementeerd dat deze naar C compileert. Dat is overigens niet ongebruikelijk: de meest gebruikte Python implementatie werkt ook zo.

ctypes?

Tot slot wordt nergens de vraag gesteld WAAROM de schrijvers voor deze aanpak hadden gekozen. Verbetert dit de kans dat het virus onopgemerkt blijft? Is deze sowieso moeilijke te bestrijden omdat decompileren niet mogelijk is?

Om de c&c servers zoveel mogelijk buiten schot te houden?

[johnkeates]

Ik ben zelf geen 'oude rot' met assembler/machine code, maar volgens mij kan je een binary die machine code of bytecode bevat 'decompilen', dus omzetten naar een hogere taal. Stel dat je gewoon een bende CPU instructies hebt, die in een bepaalde volgorde staan, dan zou je kunnen kijken naar de manier waarop ze geordend en gebruikt worden kunnen kijken welke compiler dat op die manier zou kunnen doen. Stel dat je bijv. C en C++ hebt, dan zou het kunnen dat een bepaalde volgorde of combinatie alleen in C++ voor kan komen, en dan weet je dus dat het C++ is. Nu is het natuurlijk niet zo simpel, maar daar komt het in de eerste instantie wel op neer.

Bij decompilen moet je al weten welke taal het is lijkt me, je moet een compiler van die taal hebben die 'andersom' werkt.

Dan heb je nog beschrijvingen en magic numbers, soms staat in een bestand gewoon beschreven wat/hoe/waarom het is. Je hebt in de meeste Win32 applicaties bijv. een 'This program cannot be run in DOS mode' lijn zitten, dat zit vaak in de kop van het bestand in een uiterst compacte stub die door DOS uitgevoerd kan worden en niks anders doet dan die regel uitprinten naar het scherm en afsluiten. Een magic number is dan weer een aantal bytes, dat een bepaald bestand zou kunnen identificeren. Stel dat je een JPEG bestand hebt (bevat uit een aantal onderdelen - hoewel het gewoon een bende binaire data is), dan begint dat bestand altijd met een bepaalde reeks bytes. Dat is met ingepakte binaries die uitgevoerd kunnen worden ook zo. Daar zit dan wat minder variatie in, maar je kan bijv met het unix/linux hulpprogramma 'file' meestal door die magic numbers te gebruiken wel weten wat het bestand is. Ook als er geen bestandsextensie is.

Nu zal het bij de DLL die hier gepresenteerd is een specifiek verhaal zijn, want een DLL is een binair bestand dat specifiek voor een bepaald doel gecompileerd is. Een bibliotheek bestand, voor de win32 omgeving. Dat is bijv. al informatie. Dan kan je verder kijken naar aanwijzingen wat er in het DLL bestand gebeurd, bijv. met een debugger, en hexeditor. En zo kan je dan door gaan, tot je iets tegen komt dat niet door een bekende decompiler of interceptor begrepen kan worden, en dan heb je dus een stuk code wat je niet kan 'lezen'. Dan kan je stellen dat je dan 'gewoon lekker machinecode gaat lezen', maar daar zal je je vies op verkijken Want in 1 KB zitten zo veel machine code instructies, daar ben je wel een dag zoet mee.

[Anoniem: 448545]

Ik heb ooit eens in basic een macro-assembler geschreven voor een atari 800xl. Echt simpel met een eigen bibliotheek van functies. Die 1k proggies werkte als een trein, supersnel maar als je dan de machinecode bekeek en met name naar patronen dan viel het me op dat de standaard assembler andere patronen opleverde dan die van mij. Het is maar net hoe een programmeur bepaalde problemen zoals b.v. memory en code management oplost. Elke compiler of assembler geeft daardoor een eigen fingerprint af en kennelijk heeft er eentje 6 maanden op een zolder achter een scherm gezeten en een eigen vertaalmachientje bedacht. Vind die assembler of compiler en je hebt een spoor...

[El_ByteMaster]

"Die 1k proggies" - klinkt een beetje als 'page 6' :-)

[Anoniem: 448545]

Wanneer ze kleiner moesten zijn dan 256 bytes, yup, dan was het page 6 (een geheugen segmentje op de Atari 600 xl en 800 xl dat niet werd gebruikt door het systeem). Dat hield je tenminste scherp op een 8 bitter!

[Anoniem: 428562]

IDA Pro is een bekende professionele disassembler op

http://www.hex-rays.com/p...t/download_freeware.shtml

kun je een oudere versie downloaden is niet commercieel gebruik !! maar wel nuttig

[Anoniem: 428562]

ftp://ftp.cs.wisc.edu/paradyn/papers/Rosenblum10prov.pdf

Hier wordt uitgelegd hoe je de code die een compiler produceert kunt herkennen

Verder meen ik me te herinneren dat pascal en C++ de parameters in een andere volgorde naar de stack pushen

[Reactie gewijzigd door Anoniem: 428562 op 25 juli 2024 08:05]

[Anoniem: 69322]

Ik heb zelf in het DOS tijdperk ooit eens een macro library gemaakt voor assemblers. Daarmee kon ik routines met macro's voorzien van correcte C of pascal call interfaces zonder zelf de details iedere keer opnieuw uit te hoeven werken. Van conventie veranderen was niets anders dan een taal definitie in de top van je source omzetten.

Zelfs voor de High en Low words/bytes waren door het genereren van nieuwe labels meteen benaderbaar op de stack. Verder heb ik destijds nog een eigen in theorie snellere conventie bedacht, maar zonder support daarvoor vanuit een hogere taal was dat niet zo bruikbaar.

Het moet dus niet al te lastig zijn om iets unieks te maken dat daardoor niet makkelijk herkend wordt.

Ik heb een heel oude routine die er gebruik van maakt gevonden, dat verduidelijkt het een en ander. Sommige delen worden helaas met emoticons vervangen, maar het idee is duidelijk.

Code vervangen door een download: http://members.chello.nl/p.heer3/asm.zip

common.mac
f_crect.asm

De eerste is de macro library, de 2e een VGA copieer routine.


Een nieuwere (1993) versie van de library: http://members.chello.nl/p.heer3/asm2.zip

[Reactie gewijzigd door Anoniem: 69322 op 27 juli 2024 10:15]

[trogdor]

Lachen, uit het doom tijdperk.
Heb niet zo heel veel later nog een printerdriver met dithering moeten bouwen in C, echt pixeln**ken dus
Memories.....

[seba]

Ik geloof dat er nog c++ compilers zijn gemaakt (wel lang geleden) die de parameters ook omgekeerd de stack opzetten in een (naïeve) poging buffer overflows tegen te gaan.

[Anoniem: 448545]

Correctos, Nuttig document.

[avdongen]

Verschillende programmeertalen (compilers) varieren bijvoorbeeld in de afhandeling van lokale variabelen op de stack. De aanroeper kan verplicht zijn om zijn interne variabelen op de stack zetten voor de call naar de aangeroepen functie, omdat de registers door de aangeroepen functie overschreven kunnen worden. In het andere geval is de aangeroepen functie verplicht om de registers die intern nodig zijn bij terugkeer de oude waarde tegeven.
Ook de volgorde van de waarden op de stack kunnen varieren, bijvoorbeeld de positie van parameters ten opzichte van het returnadres.

Ik weet dat je in C een Pascal-style aanroep kon doen, die de bovenstaande regeltjes aanpaste. Maar wie nou welke toepaste....

[Prototype666]

hele goede vraag, hier wil ik het antwoord ook wel op weten... <nieuwsgierige 2dejaars TI student>

[Duerf]

Mijn observaties

Het is zeker computer gegenereerde code, geen zelf geschreven assembly. Mensen zijn creatief en willekeurig. De hoeveelheid code & classes doet Kaspersky al vermoeden dat er meerdere teams aan gewerkt hebben. Menselijk geschreven assembly is makkelijk te herkennen. Een hogere programmeertaal lost alle if, while, switch, of vergelijkbare statements altijd op dezelfde manier op. Met 4e generatie talen wordt dit nog beter te herkennen, bv in C++ moeten tijdelijk objecten aangemaakt binnen een expressie altijd aan het eind van een statement worden opgeruimd, veel Objective-C gebruikt reference counting, allemaal zeer herkenbare assembly. Ook is een compiler te herkennen aan de code omdat een compiler maar een (zeer) beperkte hoeveelheid van de beschikbare assembly instructies/addressing modes gebruikt.

Het gebruikt geen higher level framework, dus ook geen C library, geen stdio, geen strings functies, etc. Het gebruik alleen de standaard Windows API.

Het gebruikt geen standaard calling conventies, sterker nog het lijk er op dat de calling conventie met opzet obscuur is ontworpen. Dit sluit direct de meeste bekende standaard compilers uit. Elke aangeroepen functie/method moet parameters via een standaard manier (register of stack) doorgeven/verwijderen. Somige compilers hebben wel calling confention modifers. Ik gebruik zelf een C++ compiler die Pascal, C maar ook een compiler specifieke calling confention via registers aan kan. Toch zou dit makkelijk herkenbaar moeten zijn.

Ze hebben dus of zelf een (eenvoudige) compiler gemaakt, of ze hebben de assembly output van de compiler door een obfuscater gehaald die de calling confention scrambled, of ze hebben een bestaande compiler aangepast om dit te doen.

Het gebruikt naast dynamic (virtual) calls, ook static calls. Dat sluit direct alle mij bekende Objective-C compilers uit.

Het event driven/callback mechanisme is niet heel speciaal maar vrij gangbaar in moderne server/client modellen. Wat wel weer opvallend is, is dat alle events een callback constructie gebruiken, maar dat zou gewoon een coding standard kunnen zijn.

Edit.

Ik lees nu dat de (virtual) method tabel per object instance wordt bijgehouden en runtime kan worden aangepast. Dit is apart, C++ en Objective-C houden dit per class bij niet per instance. C++ laat totaal geen runtime aanpassingen toe aan deze tabel, Objective-C wel.

[Reactie gewijzigd door Duerf op 27 juli 2024 10:15]

[Anoniem: 69322]

Dat laatste lijkt op virtual methods die ik ooit eens heb geïmplementeerd in C (nooit afgemaakt), Eigen functiepointer tabellen bijhouden per object. Het grappige was de flexibiliteit in de initialisatie omdat je niet gebonden was aan een strikte volgorde van initialisatie wanneer je de objecten ging extenden.

Je kon de de members in de afgeleide klasse initialiseren VOOR die van de baseclasse en ook op elk gewenst moment virtual methods vervangen door andere implementaties. Daarmee neemt natuurlijk wel de kans op programmeerfouten toe en is er geen sprake meer van stricte implementatie hiding uit OO. Maar het had ook zo zijn voordelen meen ik mij te herinneren en dus is het niet ondenkbaar dat er een C variant is gemaakt die dit native kan met objecten.

Toevallig was deze aanzet ook bedoeld voor event driven zaken als UI afhandeling .

[Reactie gewijzigd door Anoniem: 69322 op 27 juli 2024 10:15]

[Flappenn]

Volgens mij moet dat wel een kostbare investering zijn, die niet zomaar 1,2,3 door 'hackers' groep opgezet kan worden. Denk, gezien het Stuxnet verhaal, dat er Israëlische dan wel Amerikaanse gelden ingezet zijn om zoiets te ontwikkelen.

Benieuwd of er meer onthuld gaat worden op korte termijn.

[Cergorach]

Waarom zou hier veel geld in zitten? Als je niet wilt dat de rest van de wereld er niet van op de hoogte wordt gebracht ga je niet experts inhuren, de kans is veel te groot dat iets lekt. Je gaat aan de slag met een kleine groep die je vertrouwd. En aangezien dit wordt gebruikt voor illegale praktijken, lijkt het me ook niet vergezocht dat het gefinancierd wordt door illegaal verkregen geld. En als je geen belasting betaald en geen rare dingen doet heb je eigenlijk helemaal niet zoveel geld nodig om te kunnen leven en dat kan dan prima gefinancierd worden door een CC 'kraak' of iets dergelijks.

[J.J.J. Bokma]

Ik denk niet dat er veel mensen zijn die het criminele circuit in gaan om dan net genoeg te kunnen verdienen om van te leven ;-).

[J.J.J. Bokma]

Werp eens een blik op diverse open source projecten. Het is verbazingwekkend wat een groep mensen in korte tijd en in hun vrije tijd voor elkaar kunnen krijgen.

[Du7ch Maniac]

Inderdaad, deze taal is vrij wel zeker ontwikkeld door hackers. Het is niet moeilijk een virus te schrijven dat niet te detecteren is, zelfs in een bekende taal gaat dat.(als je kan programmeren)

[johnkeates]

Ik denk dat het juist een 'hackers' groep kan zijn die custom code verzint. Natuurlijk is dat bij een aanval als deze nogal twijfelachtig en zal het eerder een grotere organisatie zijn, zoals bijv. een onderdeel van een overheid.

[MSalters]

De talen die nu bekeken zijn, zijn talen die in de VS ontwikkeld zijn. Maar in andere landen zijn andere talen ontwikkeld. Глагол bijvoorbeeld is Russisch. Ik denk dat Kaspersky Lab niet naar dat soort exoten heeft gekeken. En die talen bestonden al, dus daar hoeft geen geld aan uitgegeven te zijn.

[Free rider]

Zo kostbaar is het niet.
In mijn studie moest ik een compiler voor de PDP-11 ontwikkelen. Dat was een practicum voor een vak.

[Ventieldopje]

Is de code niet gewoon door een obfuscator gehaald toevallig? Kan me voorstellen dat het dan iets moeilijker is te achterhalen.

Ben benieuwd wat ze gaan onthullen inderdaad, wie weet zit er een overheid achter

[J.J.J. Bokma]

Een obfuscator kan de calling convention niet aanpassen, natuurlijk. Zie ook mijn 1e reaktie helemaal bovenaan. Een obfuscator heeft verder alleen echt nut bij de zogenaamde script talen waarbij de bron het programma zelf is. Uiteraard is er een obfuscated C contest, maar dat is opnieuw het onleesbaar maken van de broncode. De uiteindelijke gecompileerde code zal na decompileren net zo (on)leesbaar zijn als dezelfde code netjes geprogrammeerd.

[VNA9216]

Dan nog wordt het op een bepaalde manier omgezet in machinecode waarbij je bepaalde patronen kan herkennen. Compilers doen vaak heel veel om de code zo efficient mogelijk te compileren. Echter zal je met verschillende compilers zien dat ze soms hele andere manieren hebben om het op te lossen. Uiteindelijk komen ze tot het zelfde "resultaat" maar de manier waarop kan met sommige stukken code heel erg uiteen liggen.

Ik neem aan dat ze door te zoeken naar die specifieke verschillen kunnen zien dat deze code niet door een bekende compiler gecompileerd is.

Wat natuurlijk makkelijk kan is dat een al bekende compiler intern door een groepje mensen gemod is voor hun doeleinden (of omdat ze het zelf uit een vorm van perfectionisme doen, ik ken een programmeur die zelf vaak de binaries van zn programma's na gaat lopen kijken omdat ze van hem PERFECT moeten zijn. Ik neem aan dat hij niet de enige is ) Ook hij gebruikt een standaard compiler waar wat wijzigingen in gemaakt zijn zodat dat ding (in zijn ogen) betere binaries maakt.

[Mavamaarten]

Een obfuscated executable kan je redelijk simpel deobfuscaten, zelfs als het om een onbekende obfuscatietechniek gaat. De ontsleutelde code moet namelijk érgens in het geheugen geladen worden.

[wica]

Het vermoede is dat het een variant van Lisp is

This is most probably Lisp. The distinctive features that you mention are very characteristic of a Lisp-based language. Prototype object systems are virtually indistinguishable from functional languages which implement object systems. Reading your description makes me suspect that they were inspired by a talk that I gave about research into injectable virtual machines using Lisp by Scott Dunlop and I.

Here's a link to the video presentation that I gave in Malaysia -- this was back in 2006.
http://video.google.com/videoplay?docid=-468113072359282746

You can find the slides for my talk here:
http://packetstormsecurit...s_Brown_-_MOSREF.pdf.html

Our methodology used byte code, but there's no reason why such techniques could not apply to compiled objects.

[defixje]

Of de variant op Lips. Wat niet heel erg bekend is. Genaamd: Clojure

http://en.wikipedia.org/wiki/Clojure

Zoiets moet het wel zijn, want denk niet dat virus schrijvers echt een geheel eigen taal die zo uitgebreid is gaan maken met het risico dat het binnen een maand ofzo helemaal is uitgepluist.

Edit: Typo

[Reactie gewijzigd door defixje op 27 juli 2024 10:15]

[J.J.J. Bokma]

Clojure draait op de JVM, dus nee, want dan had men zeker wel ergens een Java runtime moeten terugvinden.

Verder is het maken van een "geheel eigen taal" niet zo heel ingewikkeld, er zijn prachtige tools hiervoor te vinden, vrij. Lisp heeft verder een erg makkelijk te parsen syntax. En parsers voor (subsets) van Lisp zijn gewoon te vinden (o.a. op ANTLR site). Hoef je "alleen" maar code generatie er in te hangen. ;-)

[justice strike]

"Clojure runs on the Java Virtual Machine, Common Language Runtime and can compile to JavaScript. "

success om een java runtime in javascript te compilen

[Reactie gewijzigd door justice strike op 27 juli 2024 10:15]

[Anoniem: 154887]

Misschien is het een student?

Heb 10 jaar geleden in het eerste jaar van mijn opleiding moeten programmeren in Scheme, het voornaamste dialect van LISP. Toen al werd het in de praktijk niet meer gebruikt.
Ik kan me voorstellen dat dit nog steeds aangeleerd wordt aan de universiteiten.

[J.J.J. Bokma]

Emacs gebruikt heftig Lisp, dus hoe je er bij komt dat het in de praktijk niet meer gebruikt wordt ontgaat mij even. Zie ook http://en.wikipedia.org/w...ng_language%29#Since_2000

Lisp wordt verder ook nog druk in de CAD wereld gebruikt, vzviw.

[Cor453]

Bron? Ziet er interessant uit. Lisp is naar mijn idee ook de beste mogelijkheid. Alleen tja, is daar niet gewoon een compiler van, met bijbehorende fingerprints?

[wica]

de bron is het zelfde als tweakers als bron gebruikt, echter soms zijn de reacties interessanter dan het artikel.

[Pep7777]

Puur speculatief, ik heb niks van duqu gezien.

Maar wie weet kent er toch nog iemand assembly. En hebben ze in plaats van een nieuwe programmeertaal "gewoon" op low level een eigen library met basis functionaliteit geschreven.

Want ik denk dat ze er wel baat bij hebben dat hoe kleiner (en willekeuriger) de code hoe lastiger het te vinden is. En met assembly zijn grappige truukjes als "self-modifying" code mogelijk wat detectie nog eens kan vermoeilijken. (Zie ook: http://en.wikipedia.org/wiki/Self-modifying_code).

Wat mij betreft is het wel duidelijk dat hier iemand (mag ook meervoud zijn) flink tijd en moeite in heeft gestoken. Er zit flink wat ontwerp achter!

[J.J.J. Bokma]

Er is een vrij duidelijk verschil tussen assembly programmeren en een gecompileerde programmeertaal. Bij de laatste zijn er vaste afspraken hoe bijvoorbeeld parameters over gedragen worden e.d. Bij assembly ben je veel vrijer. Kijk maar eens naar handgemaakte assembly en wat, bijvoorbeeld, een C compiler er uit gooit. Een analogie kan zijn: het verschil tussen een handgeschreven brief, en een die uit de printer komt rollen.

[creator1988]

- The highly event driven architecture points to code which was designed to be used in pretty much any kind of conditions, including asynchronous commutations.

en

Zo kan de betreffende module op diverse manieren contact maken met de c&c-servers, onder andere via http, proxy servers en netwerk-sockets.

Doen me ergens denken aan een node.js like application, wellicht gecompileerd via een eigen compiler naar native code. Iets soortgelijks als node.native. De node binaries hebben bindings in C naar async network, async http, etc. Wellicht zelfs gewoon gebruik gemaakt van libuv.

[Reactie gewijzigd door creator1988 op 27 juli 2024 10:15]

[johnbetonschaar]

Zoiets zat ik zelf ook aan te denken ja, op zich is het met alle open-source tools die er beschikbaar zijn best goed mogelijk om op een niet-standaard manier JavaScript om te zetten naar machinecode. Bijvoorbeeld door zoiets als V8 aan te passen zodat je het kunt gebruiken om een simpele bytecode taal of iets dergelijks uit te spugen, die je dan met een custom assembler kunt compilen. Wellicht zit er zelfs een mini assembler en en runtime in de Duqu server zelf, zodat je er bytecode naartoe kunt uploaden die dan wordt omgezet naar iets uitvoerbaars. Zoiets als Node.js pas ook nog eens erg goed in het toepassingsdomein van deze Trojan.

[Reactie gewijzigd door johnbetonschaar op 27 juli 2024 10:15]

[mbiesheuvel]

Toch wel mooi om te zien hoe die Russen het doen. Ik was eerst sceptisch (was altijd McAfee aanhanger) maar ben nu toch wel blij dat we met ons bedrijf over zijn gestapt op Kaspersky :-)

[roooii]

Jij bent wel heel snel over te halen. 1 nieuwsbericht dat ze ergens mee bezig zijn met een technisch staartje en hopsateee jij bent hun nieuwe consument?

[mbiesheuvel]

Nee we draaien het nu meer dan een jaar maar je merkt gewoon dat ze niet stil zitten. Ze blijven steeds vernieuwen en dat is met McAfee wel anders. Dat pakket is ontiegelijk zwaar en herkend haast ook niets meer (overdreven maar komt er wel op neer).

[EAM666]

Redelijk offtopic, maar voor diegenen die geïnteresseerd zijn in de prestaties van verschillende anti-virus softwarepakketten staan hieronder wat links.

Het artikel:
http://www.pcmag.com/article2/0,2817,2372364,00.asp

Direct de vergelijking (tabel):
http://www.pcmag.com/image_popup/0,1871,iid=323802,00.asp

@mbiesheuvel
Het lijkt erop dat McAfee niet eens zó slecht presteert.

[3dfx]

Jammer dat ze in het vrij recente verleden niet zo vernieuwend waren met hun eigen website
nieuws: Kaspersky-site verspreidt nep-virusscanner na hack
nieuws: Hacker kraakt Kaspersky-website met sql-injectie

[Vipertje]

Al keer op keer is bewezen dat bij Kaspersky de pro's onder de pro's werken. Om de zero days te ontdekken waarvan het virus gebruik maakte heeft MS zelfs samengewerkt met hen. Zonder de hulp uit Rusland waren andere nooit zo ver gekomen of in ieder geval lang niet zo snel.

[RobinHarmsen1]

het is wel slim om als iemand wie met een virus verspreiden zijn geld verdiend taal te gebruiken wat niemand anders kent. dan hebben ze er veel langer de tijd voor nodig om te weten hoe ze dit virus kunnen bestreiden.

[Tp21]

Ik vraag me af waarom er voor zou zijn gekozen het in een speciale taal te doen en niet een van de honderden bestaande programmeertalen.

[J.J.J. Bokma]

Het antwoord zit eigenlijk al in je vraag: waarom zijn er honderden programmeertalen.

Een domein-specifieke taal kan dingen een stuk makkelijker maken. Daarom hebben we bijvoorbeeld HTML, en niet LaTeX op het web (eigenlijk wel jammer).

[Anoniem: 178824]

Ja, en op HTML, XHTML, HTML5 gebruiken we vervolgens CSS, CSS2, CSS3, een bult javascript en flash om alles lekker bij elkaar te houden? Als er iets niet standaard is dan is het wel webdesign.

[J.J.J. Bokma]

Pak een taal als Python, en dan zie je dat daar ook diverse varianten op zijn (Jython, b.v). Ook voor een taal als C c.q. C++ zijn er diverse versies. Met C++ heb je dan ook nog dat niet alle compilers alle (nieuwe) dingen aan kan, enz. Dit soort dingen blijf je houden tot iets helemaal af is. En zeker in de IT zal je dat niet snel tegenkomen, want dan is de lol er vanaf.

Kortom, (X)HTML, HTML5, CSS(2/3) is zeker niet vreemder dan andere (programmeer)talen.

Tenslotte, je moet er niet aan denken dat het web bij dit http://www.w3.org/History...text/WWW/MarkUp/Tags.html was blijven steken, toch?

[Anoniem: 241040]

De betreffende module doet iets zeer specifiek dat van groot belang is voor het virus, zonder de programmeertaal te kennen kunnen ze die dan ook niet decompileren en weten wat die module exact doet. En ik denk dat het juist daarom is dat ze dit hebben gedaan: om het lastiger te maken voor onderzoekers om uit te pluizen wat er nu werkelijk gebeurt in die module.

[wica]

Dit is onzin, ook al ken je een taal niet, kan je nog wel achter halen hoe een programma werkt. Ze moeten namelijk allemaal met de CPU communiceren en deze taal is wel bekent

[Snoitkever]

En heb je enig idee hoeveel lastiger het is om ASM te lezen dan bv C++? Zeker als het om een taal gaat met een "highly event driven architecture". Uiteraard is het te doen, maar het kost je minstens 10 keer zoveel tijd, zo niet meer.

[wica]

Misschien is dat ook wel het doel, dat het lastiger te ontcijferen is.

[Anoniem: 429159]

Het is logisch dat de 'terug-naar-huis-bel'-functie geschreven wordt in een taal die voor ons nog onbekend is. Als jij bij een inbraak 'perse' je adres moet achterlaten ga je dat niet in een taal doen die iedereen zou kunnen achterhalen.

[latka]

De standaard signature databases van virusscanners kunnen er niets mee bijvoorbeeld?

[MSalters]

Dat heeft weinig met de taal te maken. Signature scanning is als techniek ontwikkeld in de tijd dat virussen kleine stukjes hand-coded assembly waren.

Heuristic scanners zijn een ander verhaal; die proberen de intentie van onbekende code te achterhalen. Daarbij wordt nogal eens gebruik gemaakt van bekende fragmenten code (van bestaande compilers) om de onbekende code op te breken in bekende delen, en zo een analyse op hoger nivo te kunnen doen.