Aanval via ongedocumenteerde Windows-functie laat aanvallers antivirus overnemen

Beveiligingsbedrijf Cybellum heeft een ongedocumenteerde Windows-functie ontdekt die onder meer gebruikt kan worden om antivirusproducten van verschillende fabrikanten over te nemen. Het bedrijf heeft de methode de naam 'DoubleAgent' gegeven.

Volgens de Cybellum-onderzoekers maakt DoubleAgent het mogelijk om elke dll in elk willekeurig Windows-proces te injecteren. Deze code injection-methode zou momenteel nog niet door antivirusproducten herkend worden. De dll-injectie is zeer vasthoudend, zodat ook na een herstart of een herinstallatie van software de dll met het proces blijft verbonden. Een van de mogelijke toepassingen van de methode is het overnemen van antivirusproducten, maar DoubleAgent zou bijvoorbeeld ook gebruikt kunnen worden om blijvend malware te installeren, procespermissies aan te passen en code in andere gebruikerssessies te injecteren.

Omdat het gaat om een legitieme maar ongedocumenteerde Windows-functie, is er volgens Cybellum geen patch mogelijk en moeten beveiligingsbedrijven zelf voor patches van hun producten zorgen. Doordat het om een 15 jaar oude functie gaat, zijn alle versies van Windows kwetsbaar. De functie in kwestie is aanwezig in de 'Microsoft Application Verifier', die ontwikkelaars fouten in code moet helpen opsporen. Dit werkt door een dll in de te controleren applicatie te laden.

De Cybellum-onderzoekers ontdekten dat het mogelijk is om de legitieme dll te vervangen door een kwaadaardige variant. Doordat een dergelijke Application Verifier Provider-dll met de naam van een uitvoerbaar bestand verbonden is, wordt deze elke keer geïnjecteerd als een proces met die naam wordt opgestart. De koppeling wordt vastgelegd in het Windows-register. Doordat de dll op een zeer vroeg moment wordt ingeladen, is volledige controle over het doelproces mogelijk, aldus de onderzoekers. Voorbeelden van toepassing van DoubleAgent zijn het inzetten van antivirussoftware om kwaadaardige acties uit te voeren, of de werking van het programma aan te passen om bijvoorbeeld geblokkeerde bestanden alsnog uit te voeren.

Verschillende fabrikanten zouden volgens Cybellum kwetsbaar zijn, namelijk Comodo, ESET, F-Secure, Kaspersky, McAfee, Panda, Quick Heal, Norton, Avast, Avira, Bitdefender, Malwarebytes, Trend Micro en AVG. De laatste drie hebben inmiddels patches uitgebracht. Volgens Cybellum is het mogelijk antivirusproducten tegen DoubleAgent te beschermen door ze gebruik te laten maken van de Windows-functie Protected Processes, die werd geïntroduceerd in Windows 8.1. Volgens de onderzoekers laat deze maatregel alleen het uitvoeren van ondertekende code toe, maar wordt hij tot nu toe alleen gebruikt in Windows Defender.

Cybellum heeft een proof of concept op GitHub gepubliceerd en toont in een video een demonstratie van DoubleAgent in combinatie met Norton Antivirus.

Reacties (49)

[bommel]

De bewuste key zit in HKLM dus je hebt in ieder geval admin rechten nodig om de bewuste key aan te maken. Als je admin bent dan heb je al toegang tot alle processes op het systeem dus er is geen privilege escalation. Net zoals AppInit dus een mechanisme om een DLL in een process te injecteren, genoemd artikel gaat er vanuit dat de dll zodanig vroeg geinjecteerd wordt dat deze controle heeft voordat antivirus processes injectie van een vreemde dll in hun software kunnen voorkomen.

Essentie blijft: je moet niet als admin inloggen en er is nog steeds een andere exploit of manier nodig om de registry keys aan te maken (en daar zou antivirus best op kunnen controleren).

[cdwave]

Je kunt sowieso DLLs injecteren in andere processen via de "training" API van Windows, dan hoef je niet in de registry te wroeten.

SoundLeech maakt hiervan gebruik om audio uit applicaties te capturen. Werkt prima, ik moet nog wel een keer de disassembly tabel bijwerken die de code injectie doet. Je steekt hierbij geen security border over, dus je verkrijgt geen admin rechten, maar je kunt zo wel bijvoorbeeld een firewall omzeilen door je sockets uit naam van een andere applicatie (bijvoorbeeld je browser) te doen.

Bij soundleech kun je prima zien met de sysinternals process explorer in welke processen hij zijn extra dll naar binnen weet te werken.

[nextware]

Aangezien meerdere klanten van mij gebruik maken van Trend Micro software ben ik direct gaan zoeken. Het blijkt dat de volgende Trend Micro producten vatbaar zijn voor deze exploit (Trend Micro (CVE-2017-5565)):

- Trend Micro Maximum Security 11.0 (en eerdere versies)
- Internet Security 11.0 (en eerdere versies)
- Antivirus+ Security 11.0 (en eerdere versies

De patches hiervoor zijn nog niet beschikbaar (in tegenstelling wat er in het bericht staat) maar worden op zeer korte termijn verwacht.

Voor zover ik heb kunnen achterhalen lijken de Trend Micro Worry-Free Business Security versies niet vatbaar te zijn voor deze exploit.

[henk717]

Had het al gezien op een security website die ik volg, de truuk doet mij veel denken aan de debugger optie die ik al sinds 2012 voorbij heb zien komen. Beide manieren maken gebruik van de Image File Execution Options en register waardes. Als hier een debugger in staat in een sleutel met de naam van de executable zal deze altijd met de debugger worden gestart. Als je verwijst naar een niet bestaand bestand zal de antivirus niet starten en toont windows indien het bestand wordt geopend een (onterechte) melding dat het .exe bestand niet kan worden gevonden.

Het verschil met deze methode ten opzichte van de debugger is natuurlijk dat het programma niet altijd via een ander programma wordt gestart maar dat de .dll in het programma wordt geïnjecteerd en zo het programma kan overnemen.

Waar ik het met Cybellum oneens ben is dat er geen patch mogelijk is. Dit is wel degelijk door third party's met namen antivirus vendors te patchen als onderdeel van de exploit beveiliging. Sterker nog, deze techniek wordt reeds toegepast om de debuggers tegen te gaan gezien dit de enige vorm van bescherming is tegen dergelijke aanvals technieken. Wat zij in de praktijk doen is een blokkade op deze register waardes gebruikmakend van hun driver. De toegang wordt geweigerd voor het programma dat de waarde probeert aan te maken en op die manier blijft het systeem beschermd.

Kortom, een mooie vernieuwing van een oude truuk die wel degelijk te patchen valt. Het enige dat benodigd is is een tool met low level toegang die voor alle processen deze register waardes blokkeert.

Update : Zojuist in het bron artiekel gelezen dat de door mij genoemde methode kan worden omzijlt dit is mij inderdaad gelukt als ik de door hun gekozen methode naboots. Toch ben ik niet overtuigd dat ook deze methode niet te blokkeren valt. Zij hernoemen namelijk de Image File Execution options map en maken daarna de benodigde keys aan. Als een antivirus deze map monitored op het moment dat deze wordt terug genoemd is dit in theory ook tegen te gaan, de praktijk zal echter moeten leren of dit ook een praktische methode is om te patchen tegen deze kwetsbaarheid.

[Reactie gewijzigd door henk717 op 27 juli 2024 05:51]

[the_stickie]

Voor deze 'exploit' heb je administrator rechten nodig...
Met admin rechten kan je een systeem op duizenden manieren om zeep helpen. De security boundery is het verkrijgen van admin rechten. Microsoft beschouwt dit dus waarschijnlijk niet als zwakheid.

[MSalters]

"waarschijnlijk" hoef je niet te gebruiken, Microsoft heeft expliciet aangegeven dat code injection bugs geen security hole zijn als je geen security boundaries overschrijdt.

"It rather involved being on the other side of this airtight hatchway".

[henk717]

Ik heb het in mijn post dan ook over een kwetsbaarheid en geen exploit. Het woord exploit was genoemd als module. Toch gaat jouw punt niet helemaal op, er zijn duizenden manieren om een PC om zeep te helpen, echter zijn er zelfs met administrator permissies vaak niet genoeg rechten om een goede antivirus om zeep te helpen gezien deze zich op zo veel mogelijk manieren verweren. Hoewel microsoft dit als bewuste functie zal zien ben ik het daar vanuit een security oogpunt niet direct mee eens. De methode aan zich is geen exploit zoals je hebt benoemt maar deze kan wel gebruikt worden door malware om zich te nestelen in andere programmatuur waaronder virus scanners wat je als kwetsbaarheid kan zien tenslotte wil je geen .dll in bijvoorbeeld je browser geinjecteerd krijgen.
Een anti exploit beveiliging kan daarom deze methode als onderdeel van hun check opnemen om te kijken of het gaat om een debugger (Whitelist) of malware die van deze methode gebruik maakt en indien nodig de gebruiker vragen of deze actie mag worden doorgelaten.

[the_stickie]

Sorry hoor, maar software heeft geen enkel verweer tegen iemand met admin rechten die de software onderuit wil halen. Rechten zijn niet van toepassing omdat een admin altijd rechten kan nemen en/of zich voor kan doen als SYTEM (of een andere gebruiker). Het staat de admin ook vrij allerhande security maatregelen gewoon uit te schakelen.
Software gewoon onderuit halen is eenvoudig, dat doen zonder dat het opvalt voor gebruikers (zoals gedemonstreerd in het filmpje) vereist wellicht meer werk, maar is per definitie wel mogelijk (desnoods vervang je de executables).
De enige maatregelen die admins in het gareel kunnen houden zijn auditing en controle, en dan nog after the facts en wellicht alleen nog omdat lege logs ook opvallen.

[Reactie gewijzigd door the_stickie op 27 juli 2024 05:51]

[henk717]

Software onderuit halen lukt mij ook altijd, maar het is niet altijd zo simpel als het lijkt. Probeer maar is een goede antivirus te killen met systeem rechten, dit gaat niet lukken omdat ze hier simpel weg tegen beveiligd zijn. Zojuist heb ik geprobeerd de debugger register entry aan te maken, dit lukt niet ook niet met system. In de bron werdt genoemd dat je Image File Execution Options kon hernoemen maar zelfs dit wordt door Avast geblokkeerd. Ondanks dat je rechten hebt op de bestanden blijf je toch toegang geweigerd krijgen simpelweg omdat dit niet op systeem maar op driver niveau wordt afgevangen welke nog een stap dieper licht dan jouw process. De enige manier dat het mij is gelukt om Avast te killen was door ook gebruik te maken van drivers om dat niveau te evenaren.

[Scripted]

Als deze ongedocumenteerde functie in windows zit... en niemand wist hier van.. dan gebruikt windows dit zelf waarschijnlijk ook niet. (en andere software dus ook niet) Het verwijderen zal dan dus waarschijnlijk ook geen negatief effect hebben op gebruikte functionaliteit. Dan kan Microsoft deze functionaliteit d.m.v. een patch er toch ''gewoon'' uit slopen?

Of zie ik dat te simpel?

[jozuf]

Volgens mij gebruikt Windows, of eigenlijk visual Studio (of de debugger hiervan) deze functie voor het debuggen van processen.

[Reactie gewijzigd door jozuf op 27 juli 2024 05:51]

[SunnieNL]

En dat maakt het weer een gedocumenteerde functie.
Alleen heeft nooit iemand bedacht dat je ook een kwaadaardige dll zou kunnen injecteren voor debugging.

Ik mis in het artikel de register locatie waar dit wordt opgeslagen. Dan is het eenvoudig gewoon daar op te zoeken (of die sleutel gewoon te blokkeren door de rechten te ontnemen)

[batjes]

Er zitten een heleboel ongedocumenteerde features in Windows. Het is vandaag niet zo heel erg meer en het meeste is ondertussen wel gedocumenteerd. En ze worden wel gebruikt, anders zaten ze er niet in.

Veel van de ongedocumenteerde features worden ook met nieuwe Windows releases gewijzigd (of zijn nog gewoon in ontwikkeling), MS houdt ze dan express niet gedocumenteerd zodat ze daar geen rekening hoeven te houden met backwards compatibility bij de eerst volgende Windows release/patch/jaarlijkse update/service pack.

[SunnieNL]

Verschil is dat het niet gaat om een ongedocumenteerde functie. Als je zoekt op de key die ze gebruiken vind je deze gewoon terug in de MSDN documentatie voor debugging.

Het is alleen nog nooit gebruikt om een hijack dll te injecteren in een applicatie.

[mae-t.net]

Een functie hoeft niet gedocumenteerd te zijn om gebruikt te kunnen worden. MS heeft daar nogal een geschiedenis mee, en heeft zijn leven in het verleden al grotendeels gebeterd.

[.oisyn]

Of zie ik dat te simpel?

Ja . Heel veel ongedocumenteerde functionaliteit wordt weldegelijk gebruikt door bijvoorbeeld standaard Windows API calls die op userniveau vertaald worden naar de ongedocumenteerde tegenhangers, of door specifieke software (van MS zelf) die bepaalde OS functionaliteit nodig heeft die niet via de standaard API te verkrijgen is.

Zo ook waarschijnlijk hier. De Application Verifier is weldegelijk een gedocumenteerde tool. Waarschijnlijk gebruikt die intern zelf gebruikt van ongedocumenteerde functionaliteit van Windows om zijn eigen werking mogelijk te maken, maar kan diezelfde functionaliteit worden uitgebuit door andere programma's.

[Reactie gewijzigd door .oisyn op 27 juli 2024 05:51]

[MazeWing]

Dat ie ongedocumeneert is wil nog niet zeggen dat ie ongebruikt is. Mogelijk maakt Microsoft hier zelf wel gebruik van. Ook is het niet ondenkbaar dat bepaalde veiligheidsdiensten deze ongedocumenteerde functie reeds uitvoerig "gedocumenteerd" hebben.

[Flitskikker]

Ik vermoed dat de functies wel intern door Windows worden gebruikt, maar dat ze niet zijn gedocumenteerd voor externe ontwikkelaars.
Een beetje zoals private API's in iOS: functies die ongedocumenteerd zijn en die ontwikkelaars niet mogen gebruiken, maar wel intern door Apple worden gebruikt om bepaalde trucjes uit te halen.

[SuperDre]

Ongedocumenteerd betekend niet dat de functie niet gebruikt wordt, betekend alleen dat het niet vermeldt staat in de publieke documentatie. Blijkbaar is deze functie wel bekend bij de antivirus-makers want die maakten er al gebruik van.

[isene]

Zo te zien hanteert Microsoft hun eigen MS-SDL framework niet , als je dit secure by design framework gebruikt zou er geen "ongedocumenteerde functie" mogen zijn. Daarnaast wordt het ook afgeraden om oude en deprecated functies te hergebruiken.

Het niet refactoren van de code lijkt mij een beetje richting gemakzucht te gaan, ja het kost tijd, ja het kost geld en ja het levert nieuwe inzage problemen die 15 jaar geleden nog door de beugel konden. Natuurlijk is het koffiedik kijken of dit er voor gezorgd zou hebben dat zulke problemen niet ontstaan, maar het creëert wel awareness binnen je developers.

[Reactie gewijzigd door isene op 27 juli 2024 05:51]

[the_stickie]

Zo ver ik het uit kan maken, moet je administrator zijn om deze functionaliteit te gebruiken/misbruiken.
In dat geval zal Microsoft er ook niks aan doen, juist omdat een admin álles kan 'by design' en dus het niet gaat om een zwakheid. Dezelfde redenering is al vaak gebruikt.

[isene]

Je code documenteren / commentariëren is altijd belangrijk, was het wel gedocumenteerd dan was de kwetsbaarheid mischien al lang gevonden en door de loop van de jaren heen al gepatched.
Maar zoals ik ook al eerder zei, het blijft een kwestie van "mischien". Het is altijd makkelijker om achteraf te praten, en zeggen wat er beter kon

[Reactie gewijzigd door isene op 27 juli 2024 05:51]

[SunnieNL]

De feature is ook gewoon gedocumenteerd.
Zie o.a. https://msdn.microsoft.co...ry/bb432502(v=vs.85).aspx

Het enige verschil is dat ze nu een 'bad' dll gebruiken ipv een nette debugger.

[isene]

Als dit daadwerkelijk deze functie betreft, dan staat het in het bericht fout weergegeven dat het om een ongedocumenteerde functie gaat.

Ik zie bij de functie die jij benoemd dat deze vanaf Vista er in zit, en de kwetsbaarheid zit er al in vanaf XP

Minimum supported client - Windows Vista [desktop apps only]

[Reactie gewijzigd door isene op 27 juli 2024 05:51]

[SunnieNL]

De functie is vanaf Vista ook per gebruiker (HKCU) beschikbaar, al moet je dan eerst als admin een key in HKLM plaatsen.

Via HKLM werkt het al sinds Windows XP.

[the_stickie]

Hklm = admin only

[SunnieNL]

Nee... hklm is admin, system of trusted installer

[the_stickie]

Klopt. M'n reactie was kort door de bocht, ik doelde op 'niet voor users'.

[the_stickie]

Zover ik het kan uitmaken is de application verifier een dev/debug tool en is die wel degelijk 'bekend'.

Mijn punt is dat dit geen security flaw ís. Je moet immers admin zijn om dat te kunnen, en dàt is de security boundery. Dat een admin kan knoeien met elk bestand en elk proces van elke gebruiker is by design.

[Verwijderd]

Ik vermoed dat het om publiek geopenbaarde documentatie gaat. Intern zal dit bij MS echt wel gedocumenteerd zijn.
Ik ben steeds meer overtuigd dat opensource de enige optie is om dit soort rotzooi te voorkomen. Natuurlijk zitten daar ook zwakke plekken in opensource software, maar doordat de code gewoon volledig inzichtelijk is, kan er in ieder geval bij een probleem door iedereen een patch voor ontwikkeld worden.

[Reactie gewijzigd door Verwijderd op 27 juli 2024 05:51]

[batjes]

juist omdat een admin álles kan 'by design' en dus het niet gaat om een zwakheid. Dezelfde redenering is al vaak gebruikt.

Nee dat is een root, een Windows admin kan niet alles bij design. Een Windows admin kan wel een root worden, maar bij design kan je als Admin lang niet alles.

[Finraziel]

Ok, klinkt ernstig, maar wat is nou specifiek het risico? Ik heb het bronbericht gelezen en als ik het goed begrijp dien je nog altijd iets zelf te installeren en is het niet zo dat je ineens van buitenaf zoiets op je systeem kan krijgen, toch?

[Belgar]

Klopt, maar omdat het anti-virus software over kan nemen kan de infectie op het allerhoogste niveau van je systeem schade aanbrengen, niet alleen op het niveau van een gebruiker. Bovendien kan het zichzelf beschermen tegen een standaard herinstallatie en alleen met een volledige clean install verwijderd worden.

[TunefulDJ_Mike]

Als ik het goed begrepen heb kan je hem via het register er weer uitwerken. Als je het tenminste kan vinden.

[henk717]

Dit is onjuist, ze gebruiken de term installeren correct maar houdt er rekening mee dat malware zichzelf altijd installeert. Het hoeft dus helemaal geen handmatige actie te zijn maar kan ook gebeuren via een bestand dat met een exploit wordt ingeladen. Ook al zouden de antivirussen gepatched worden kan deze methode alsnog worden toegepast op de overige software zodat de malware langer ongezien blijft als het .dll bestand en de register wijziging niet wordt opgemerkt.

Nu deze techniek bekend is is deze af te vangen zoals ik in mijn andere post al heb aangegeven. Je kunt namelijk register entry's monitoren en blokkeren om dergelijke pogingen af te slaan mits je low level toegang hebt tot het register.

[ApexAlpha]

Volgens Cybellum is het mogelijk antivirusproducten tegen DoubleAgent te beschermen door ze gebruik te laten maken van de Windows-functie Protected Processes, die werd geïntroduceerd in Windows 8.1.

En Windows 7? De meest gebruikte Windows variant? Hebben de laatste 3 AV's ook voor deze versie gepatchd? Dat is mij niet duidelijk.

[Simyager]

Windows 7 is EOL: Mainstream support ended on January 13, 2015

[ApexAlpha]

Vanuit MS ja, niet vanuit de AV bedrijven? Er staat "De laatste drie hebben inmiddels patches uitgebracht. " in het artikel.

Verder staat er die oplossing. Maar er staat niet of die AV bedrijven ook die oplossing hebben toegepast en wat de gevolgen voor het meest gebruikte OS ter wereld zijn!

[SirBlade]

Dit zagen tijdens de laatste jaren van XP. Niet alles valt meer te fixen. Dus tijd om over te gaan naar een nieuwer OS.

[rfbeiboer]

Als ik het goed begrijp heb je Administrator-rechten nodig om de dll-injection tot stand te brengen (te installeren). Is dit dan echt een security vulnerability? Zou dit weer een post opleveren in Raymond Chen's blog?

[Yarach]

Ik ben er gister "slachtoffer" van geworden vermoed ik. Ineens viel Windows Defender uit en kon hem met moeite weer aan krijgen. Heb direct het internet uitgezet en een scan gedaan.

[tweakradje]

OK. Bekende key want daar kan je ook andere leuke process options instellen.
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows NT/CurrentVersion/Image File Execution Options/PROCESS_NAME
Bijv. PerfOptions\ CpuPriorityClass

In de gaten houden of daar VerifierDlls values worden aangemaakt. Kan in je login script. Dan gelijk laten melden.
bijv:
For /f %%a in ('Reg.exe Query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options" /f "VerifierDlls" /v /s^|Findstr HKEY_') Do Powershell Send-MailMessage ... %%a

Ik ga het in elk geval er in zetten. Better safe than sorry

Als je de exe naam van je Antivirus weet kan je de key ook zelf aanmaken en de rechten helemaal dichtzetten. Maak administrator de eigenaar en geef die ook readonly.

[Reactie gewijzigd door tweakradje op 27 juli 2024 05:51]