Onderzoekers tonen nieuwe methode voor code-injectie in Windows

Onderzoekers van het beveiligingsbedrijf enSilo hebben een nieuwe manier ontdekt om code in Windows-processen te injecteren. Daarbij maken zij gebruik van atom tables. Zij stellen dat er geen directe oplossing voor het probleem is.

Een oplossing ontbreekt volgens enSilo, omdat het probleem niet te maken heeft met kwetsbaarheden in code. De 'AtomBombing'-techniek, zoals het bedrijf deze noemt, maakt gebruik van legitieme functies van het besturingssysteem, aldus het bedrijf. Het voerde een succesvolle test uit op Windows 10, maar alle versies van Windows zouden vatbaar zijn voor de aanval. Een aanvaller zou de methode kunnen gebruiken om gegevens te benaderen die alleen voor bepaalde processen toegankelijk zijn en op die manier toegang krijgen tot versleutelde wachtwoorden of een man-in-the-middle-aanval op de browser kunnen uitvoeren.

Bovendien kan de aanvaller beveiligingsproducten omzeilen door code te injecteren in door de software vertrouwde processen. De aanval werkt door gebruik te maken van atom tables. Dit zijn tabellen waarin programma's gegevens kunnen opslaan en delen, aldus enSilo. Een aanvaller kan kwaadaardige code naar een dergelijke tabel schrijven en ervoor zorgen dat een legitiem programma deze code ophaalt en uitvoert. Dit is mogelijk aan de hand van twee api calls, zo leggen de onderzoekers in een technische analyse uit.

Er is volgens enSilo geen directe oplossing voor het probleem, anders dan de api calls zelf in de gaten te houden en te letten op kwaadaardige activiteit. Een van de onderzoekers laat aan ZDNet weten dat de grootste zorg is dat een gemotiveerde aanvaller altijd soortgelijke technieken zal ontdekken. Bovendien zou deze aanval eenvoudig beveiligingssoftware kunnen omzeilen, omdat de methode nog niet als kwaadaardig is aangemerkt. Microsoft laat in een reactie aan dezelfde site weten dat gebruikers waakzaam moeten zijn bij onbekende bestanden en dat 'het systeem van de gebruiker al in handen van de aanvaller moet zijn voordat malware deze vorm van code-injectie kan toepassen'.

AtomBombing leidt tot crash in Paint

Reacties (28)

[Armin]

Merk op dat dit niet zoeer een aanval is, maar meer een (nieuwe) methode om nadat een andere aanval reeds gelukt is, verder door te kunnen dringen in het OS. In die zin dus interessant, maar geen kwetsbaarheid van het OS.

De aanval werkt door shell-code data op te slaan in een gebied wat normaal enkel voor data (strings etc) bedoeld is, en dan via een truc een slachtoffer process deze te laten kopieren in zijn eigen process. De truc om code te injecteren is beperkt tot bepaalde omstandigheden (alertable threads) maar wordt niet herkend door bestaande migitation software (aldus de auteurs).

Dat laatste is dus de echte vondst: een vermeend nieuwe methode om processen aan te vallen als je al binnengedrongen bent, die nog niet opgemerkt wordt door bestaande AV en aanverwante producten.

Die vondst echter wordt overigens al weersproken door sommigen in het veld, en sommige AV-producten schijnen wel al (delen van) deze truc te herkennen en voorkomen. Vandaar dat ik sprak van 'vermeend nieuwe methode'.

[WhatsappHack]

Dat was ook mijn eerste ingeving "Als ze al code-execution kunnen uitvoeren, dan heb je al een probleem - wat is hier nog zoveel gevaarlijker aan dan?". Dat en ATOM heeft geloof ik een 255-limit, wat injecteer je daar. Die codeless execution die echter in de gelinkte blogpost is gepost is wel interessant en veranderde het verhaal toch aanzienlijk. Maar idd: zat tools die het oppikken. Het "gat" zelf is volgens mij al een tijdje bekend.

[Reactie gewijzigd door WhatsappHack op 22 juli 2024 22:14]

[Verwijderd]

Met name de thread context trickery die gebruikt word om daadwerkelijk uit te voeren is algemeen bekend.

[kdekker]

Het verbaast me wel een beetje dat je met de atom table (wat op zich al een oud relic is uit het 16-bit tijdperk) executeerbare code kunt aanroepen. De table is bedoeld voor strings (in de kernel), waar mee je dingen kunt delen tussen processen. De atom table heeft allerlei beperkingen, waardoor er volgens mij al 10 jaar geleden de interface als 'niet gebruiken in nieuwe code' bestempeld werd. Misschien dat MS de hele API er maar uit moet slopen?

[Armin]

Het verbaast me wel een beetje dat je met de atom table (wat op zich al een oud relic is uit het 16-bit tijdperk) executeerbare code kunt aanroepen. De table is bedoeld voor strings (in de kernel), waar mee je dingen kunt delen tussen processen.

Dat kan dan ook niet. men gebruikt een tweede truc om de niet-executeerbare code, te laten copieren naar een wél executeerbare locatie in het slachtogger process.

De Atom table is enkel omdat jij als aanvaller daar makkelijk data in kunt zetten die globaal (en dus ook door het slahctoffer) bereikbaar is.

Misschien dat MS de hele API er maar uit moet slopen?

Nadeel is dat talloze applicaties dan stoppen met werken. Met name antieke, maar bedrijfskritieke meuk uit het grote bedrijfsleven

Meer algemeen, de kracht van Windows is altijd geweest dat je binaries van 10+ jaar oud as-is kunt draaien. Dus je moet oppassen API's zomaar te verwijderen.

Plus dat je ook niet verbaasd moet opkijken als allerlei moderne applicaties deze API's ook opeens nog blijken te gebruiken ...

[Henk Poley]

Kan me zo voorstellen dat ze deze Atom table achter een 'shim' zetten. Ze kunnen vast redelijke snel een lijst verzamelen met oude software die dit nodig heeft. Voor nieuwe of onbekende software moet je dan met de Application Compatibility Toolkit (ACT) aan de gang om de juiste shim te activeren.

[kdekker]

Dat is heel makkelijk te controleren of een binary of DLL GlobalAddAtom (en aanverwant) gebruiken (voor niet-dynamisch laden; voor dynamisch laden (LoadLibrary/GetProcAddress) is dat wat lastiger). De pijn zit dan w.s. meer in het feit dat een applicatie de code zelf niet direct gebruikt, maar indirect wel via Windows libraries die er wel op vertrouwen...

Voor moderne applicaties zijn er genoeg alternatieven: shared memory, IPC, (memory mapped) files.

APIs kun je inderdaad bijna niet verwijderen. Dat is de kracht en de zwakte van Windows (en de kracht van elke nieuwkomer die dit soort lastige dingen de eerste tijd niet heeft, maar ook vanzelf krijgt).

[Verwijderd]

De table kan uit zichzelf net zo min iets uitvoeren als dat notepad dat kan.
De data die je er in zet kan elders binnen een andere context wel als uitvoerbare code gebruikt worden.

[kdekker]

Daar is juist DEP voor om dat te voorkomen. Executeerbare code en data zijn als het goed is zeer strict gescheiden... En data omtoveren in executeerbare code zou juist niet moeten kunnen. DEP is al weer heel wat jaartjes oud...

[erikloman]

De aanval maakt gebruik van een ROP – Return Oriented Programming. Een exploit techniek.

ROP wordt door Microsoft EMET, HitmanPro.Alert of Sophos Intercept X voorkomen waardoor de injectie uit het voorbeeld van enSilo niet meer werkt.

[SuperDre]

Blijkbaar dus niet, want anders is het hele nieuwsitem dus waardeloos en niets meer dan een windowsbash..

[DigitalExorcist]

Niet iedereen gebruikt EMET, Intercept X of HitmanPro. Dus wel degelijk nieuwswaardig..

Sterker nog, ik denk dat een flink aantal bedrijven (en dan vooral de MKB's van deze wereld) hier überhaupt nooit van gehoord heeft. Helaas. Die denken met een AVG scannertje en misschien een firewall die iets dichter staat dan default wel vooruit te kunnen ..

[Reactie gewijzigd door DigitalExorcist op 22 juli 2024 22:14]

[ikt]

Is het dan nog steeds niet de taak aan het uitvoerende programma om de kwaadaardige code te laden en uit te voeren? Ik neem aan dat je niet per ongeluk je programma atom-tables laat doorzoeken. De verantwoordelijkheid lijkt dus meer richting de applicatie-developer te liggen, en niet aan Microsoft, behalve dat Microsoft dan op syteemniveau alle applicaties toegang geeft tot deze tabel.

[Verwijderd]

Bijv door een thread the suspenden en de context eip/regs te wijzigen kun je er voor zorgen dat een proces wanneer je hem resumed een functie aanroept of naar een ander nuttig stuk uitvoerbaar code springt en data beschikbaar heeft.

[Genius-General]

Oké, dus met andere woorden heeft mijn eset geen zin meer en al mijn wachtwoorden in dashlane ook niet? Of begrijp ik het verkeerd?

[Nokian95dude]

Geen oplossing? Als het in software is, is zoiets ALTIJD tegen te houden/te blokcken...

[mvhorssen]

Dat is veel te kort door de bocht. Als met de 'oplossing' ineens 30% van de Windows applicatie's niet meer werkt, lijkt me dat geen oplossing.

[Hanterp]

Als ik hier die -toch wel die gedetailleerde- uitleg over die code-injectie lees, dan vraag ik me af of je dan niet de kat op het spek bindt. Kunnen kwaadwillenden hier dan niet leren hoe je dit gebruikt?

[_Thanatos_]

Iets zegt me dat deze truuk op Linux-achtigen en OSX ook wel moet kunnen. Het klinkt als iets dat algemeen toepasbaar is.

[himlims_]

Welkome op t.net DSTech, zie boven artikel; een feedback knopje!

Microsoft laat in een reactie aan dezelfde site weten dat gebruikers waakzaam moeten zijn bij onbekende bestanden

Leg dat Truus Facebook maar eens uit ...geweldig advies uit redmond

[Reactie gewijzigd door himlims_ op 22 juli 2024 22:14]

[jpsch]

Truus Fakebook?

Er staan duizenden bestanden op een computer. Weet zelf echt niet wat elke doet, voor mij dus onbekend..

[DigitalExorcist]

Nee maar er is een verschil tussen alle md5 hashes van elk bestand uit je hoofd te kennen, of lukraak klikken op elk linkje van een Nigeriaanse prins die belooft dat je 100 miljoen euro krijgt als je zijn testament even vooruit wil betalen.