Pas op voor Bashware: een nieuwe methode waarmee willekeurige malware elk veiligheidsproduct kan omzeilen

Pas op voor Bashware: een nieuwe methode waarmee willekeurige malware elk veiligheidsproduct kan omzeilen

Blogvertaling van: Gal Elbaz en Dvir Atias, Check Point Security Research

Het aantal cyberaanvallen groeit en vrijwel dagelijks zijn er in het nieuws berichten over databaselekken, spyware en ransomware. Elk bedrijf en elke organisatie beschikt daarom tegenwoordig over veiligheidsproducten van uitstekende kwaliteit. Ook wordt er veel tijd en aandacht geschonken aan een goede informatiebeveiligingsstrategie, om deze aanvallen te bestrijden en zo goed mogelijk te voorkomen.

Onlangs ontdekten Gal Elbaz en Dvir Atias, Check Point Security Research, een nieuwe verontrustende methode, waarmee elke bekende malware de gebruikelijke veiligheidsproducten kan omzeilen, zoals next-generation anti-virusprogramma’s, onderzoekstools en anti-ransomware. Deze methode, die ook wel Bashware wordt genoemd, maakt gebruik van een nieuwe functie in Windows 10, Subsystem for Linux (Subsysteem voor Linux, WSL), Windows Subsystem Linux en nu een volwaardig onderdeel is van Windows.

Deze functie maakt de populaire Bashterminal beschikbaar voor gebruikers van Windows OS, waardoor zij uitvoerbare bestanden van het besturingssysteem van Linux kunnen uitvoeren op het OS van Windows.

De huidige veiligheidsproducten zijn nog niet in staat om de processen te monitoren van uitvoerbare bestanden van Linux op een Windows OS, een hybride concept dat ervoor zorgt dat Linux- en Windows-systemen gelijktijdig kunnen draaien. Cybercriminelen krijgen zo de kans om ongemerkt hun kwaadaardige code uit te voeren, en om functies te gebruiken die WSL biedt om zich te verschuilen voor de veiligheidsproducten waarin de juiste detectiemechanismen nog niet zijn geïntegreerd.

Bekijk hier de demo van de aanval: https://youtu.be/fwEQFMbHIV8

Wat Bashware zo gevaarlijk maakt is dat het laat zien hoe gemakkelijk het WSL-mechanisme kan worden gebruikt om welke malware dan ook langs de veiligheidsproducten te loodsen. Gal en Dvir hebben deze techniek getest op de belangrijkste anti-virus- en veiligheidsproducten die nu op de markt zijn, en ze konden allemaal worden omzeild. Dit betekent dat Bashware wereldwijd in principe alle 400 miljoen pc’s kan treffen die op Windows 10 draaien.

Naar aanleiding van deze ontdekking hebben wij onze SandBlast Threat Prevention solutions bijgewerkt, zodat onze klanten tegen Bashware zijn beschermd. Wij roepen de hele veiligheidsbranche op om hun veiligheidsproducten aan te passen, zodat ook hun producten bescherming bieden tegen deze nieuwe methode.

BASHWARE

De Bashwaretechniek maakt gebruik van het mechanisme achter het Windows Subsystem for Linux (WSL). Dit mechanisme, dat als onderdeel van Windows 10 is geïntroduceerd, laat Linux ELF-binaries onder Windows draaien. Voordat we de ins en outs van Bashware nader gaan bekijken, leggen we eerst uit hoe WSL precies werkt.

Overzicht van WSL

De functie WSL doet veel meer dan de oude vertrouwde Linux ‘Bash’-shell op het Windows OS.

Het bevat zowel delen van de gebruikersmodus als de kernelmodus die samen een volledige compatibiliteitslaag maken waarmee een omgeving kan worden gedraaid die er net als Linux uitziet en zich net als Linux gedraagt, zonder dat hiervoor een virtuele machine hoeft te worden opgestart.

Microsoft had als doel de doelapplicatie en het OS volledig te laten draaien binnen de adresruimte van een enkel proces, door een manier te vinden waarop een applicatie kon draaien in een geïsoleerde omgeving met beperkte overhead. Om dit nieuwe concept mogelijk te maken werden Picoprocessen geïntroduceerd. Picoprocessen zijn de containers die het mogelijk maken dat ELF-binaries op het Windows OS kunnen draaien. Deze nieuwe types processen zijn minimaal en missen de structurele blokken die in gangbare Windows-NT-processen gebruikelijk zijn (PEB, TEB, NTDLL, etc.).

Door ongewijzigde Linux-binaries in Picoprocessen te plaatsen, laat WSL aanroepen van Linux-systemen naar de Windows-kernel leiden. De drivers lxss.sys en lxcore.sys vertalen de aanroepen van het Linux-systeem in NT API’s en emuleren de Linux-kernel.

Het WSL-concept is ooit begonnen als het Astoriaproject en het Drawbridgeproject, met als doel androidapplicaties op Windows-systemen te laten draaien. Later werd de focus veranderd en werd de fundering gelegd voor de service die het vandaag de dag levert.

In de eerste versie van WSL bleken nog diverse problemen te zitten en daarom besloot Microsoft dit project in bètamodus uit te brengen en een service aan te bieden op hun GitHub-pagina, om problemen te verzamelen die binnen de gebruikersgemeenschap speelden. Toen de meeste problemen vanuit de gemeenschap eenmaal waren opgelost en er een enigszins stabiele versie was gemaakt, kondigde Microsoft op 28 juli 2017 officieel de release van WSL aan, met ingang van de Windows 10 Fall Creators Update (FCU), die staat gepland op 17 oktober 2017.

Hoewel WSL een stabiele functie is geworden en de meeste problemen inmiddels zijn opgelost, heeft de branche zich nog niet aangepast aan dit vreemde, hybride concept waarmee een combinatie van Linux- en Windows-systemen tegelijk kunnen draaien. Cybercriminelen kunnen zo de gelegenheid krijgen om hun kwaadaardige code ongemerkt uit te voeren en gebruik te maken van de functies die WSL biedt om veiligheidsproducten te omzeilen waarin de juiste opsporingsmechanismen nog niet zijn geïntegreerd.

Aanvullende informatie over de ins en outs van WSL vindt u in ‘Bijlage A’ van dit document (geheel onderaan).

Afbeelding 1 – https://blogs.msdn.microsoft.com/wsl/2016/04/22/windows-subsystem-for-linux-overview/

Bashware nader bekekenBashware nader bekeken

Bashware is een algemene, platformoverschrijdende techniek die WSL gebruikt om op een geniepige manier zowel kwaadaardige ELF- als EXE-inhoud uit te voeren, buiten het blikveld van de huidige veiligheidsoplossingen.

De sleutel voor deze techniek kan gevonden worden in het ontwerp van de structuur van het Picoproces. Het Picoproces heeft geen enkel kenmerk van de gebruikelijke Windows-processen, en heeft zelfs niets waardoor het als een regulier NT-proces zou kunnen worden beschouwd. Toch hebben Picoprocessen dezelfde mogelijkheden als een normaal NT-proces en zijn zeker niet minder bedreigend.


Afbeelding 2 – De vier stappen van Bashware

Bashware laadt de kwaadaardige inhoud in vier stappen:

Stap 1: WSL-onderdelen laden

Om te kunnen profiteren van WSL moet Bashware eerst verifiëren of de WSL-functie is ingeschakeld; dit doet Bashware door de status van de Picodrivers te controleren (zijn lxcore.sys en lxss.sys aanwezig in het pad van de Windows-driver). Is deze functie niet ingeschakeld, dan laadt Bashware de drivers met behulp van het DISM-programma. Deze methode blijkt het eenvoudigst te zijn en de minste argwaan te wekken. Door op deze manier op de achtergrond, zonder dat de gebruiker het kan zien, een enkele commandoregel uit te voeren, laadt Bashware de WSL-onderdelen en kan het verder gaan met de volgende stap.

Stap 2: De onwikkelaarsmodus inschakelen

Vaak denkt men dat de kans dat WSL wordt misbruikt minimaal is, omdat hiervoor de ontwikkelaarsmodus handmatig door de gebruiker moet worden ingeschakeld. Slechts weinig mensen beseffen echter dat dit een fluitje van een cent is; je hoeft alleen de volgende registersleutels in te voeren:

  • HKLM \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ AppModelUnlock \ AllowAllTrustedApps
  • HKLM \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ AppModelUnlock \ AllowDevelopmentWithoutDevLicense

Hoewel deze waarden zijn ingesteld door TrustedInstaller kan elke gebruiker (of applicatie) met lokale beheerdersrechten dit gemakkelijk doen.

De WSL-functie was aangemerkt als bètaversie en kon alleen functioneren als de ontwikkelaarsmodus was ingeschakeld.

Er bestaat geen validatie of geavanceerde veiligheidscontrole die deze waarden controleert en nagaat of ze zijn aangepast. Bashware misbruikt de registersleutels door ze heel even aan te zetten, niet langer dan nodig is om de kwaadaardige handelingen uit te voeren. Zodra Bashware klaar is, worden de sleutels weer uitgezet zodat de hele operatie vrijwel onzichtbaar verloopt.

Stap 3: Linux installeren

Hoewel Bashware WSL inmiddels heeft ingeschakeld en zich in de ontwikkelaarsmodus bevindt, bevat de Linux-instantie nog geen enkel bestandssysteem. Nu gaat Bashware het Linux-bestandssysteem vanaf de servers van Microsoft downloaden en uitpakken.

De installatie van het gebruikersbeheer gebeurt door ‘Lxrun’, met gebruik van de optie /install. De commandoregelinterface ‘Lxrun’ downloadt en installeert het bestandssysteem op een Windows-pc. Het Linux-facing bestandssysteem in WSL is Ubuntu 16.04, dat wordt geleverd met ondersteuning voor UNIX-rechten. Bashware gebruikt het programma Lxrun.exe, dat het Linux-bestandssysteem downloadt van de Microsoft-servers. Dit proces ziet er heel legitiem uit en verloopt geruisloos.

Het is opmerkelijk dat uit het onderzoek bleek dat dit installatieproces ook vatbaar is voor een ‘race condition’-kwetsbaarheid, die hieronder nader wordt uitgelegd in de paragraaf ‘Meer veiligheidsissues’.

Stap 4: Wine

Nu Bashware een volwaardige Linux-omgeving heeft opgezet in het Windows-systeem en in staat is om in beide omgevingen handelingen uit te voeren, rijst de vraag: wat kan Bashware nog meer doen?

Het moge duidelijk zijn dat het ons uiteindelijke doel was om te laten zien dat we malware kunnen uitvoeren die het Windows-systeem aanvalt vanaf een Linux-instantie, ondanks het feit dat malware niet is ontworpen om op die manier platformoverschrijdend te zijn. We ontdekten dat het Winehq-project hiervoor de perfecte oplossing is – een gratis open-source compatibiliteitslaag, die Microsoft Windows-programma’s laat draaien op Unix-achtige besturingssystemen. Voor mensen die dit nog niet kennen, Wine is geen emulator, maar het vertaalt Windows API-aanroepen naar POSIX (Portable Operating System Interface), hetgeen perfect aan onze behoeften voldoet.

Dit is precies wat we nodig hadden om Windows-malware te laten draaien vanuit de WSL-omgeving, waardoor het bovendien onzichtbaar werd. Bashware gebruikt de mogelijkheden van het Winehq-project en installeert een vooraf geoptimaliseerd Wine-project in een WSL Linux-omgeving.

Vervolgens moeten Wine EXE-formats worden omgezet, waardoor de NT-systeemaanroepen worden veranderd in POSIX-systeemaanroepen. Op een later moment zal de Pico Provider (lxcore.sys) deze POSIX-systeemaanroepen terug veranderen in NT-systeemaanroepen, waarbij lxcore naar de eigenlijke ‘aanroeper’ wordt geretourneerd. Op deze manier kan een bestand dat op een Windows-besturingssysteem draait, elke bekende kwaadaardige inhoud draaien vanaf een Linux-besturingssysteem, terwijl het buiten het blikveld blijft van de meeste veiligheidsproducten.

Conclusies

Wanneer ‘Bashware’ deze vier stappen uitvoert, laat het op perfecte wijze zien hoe malware onzichtbaar kan worden uitgevoerd en de meest gangbare veiligheidsproducten omzeilt – anti-virusprogramma’s, inspectietools, debugging tools, en nog veel meer.

Bashware maakt geen gebruik van de tekortkomingen in het WSL-ontwerp wat betreft logica of implementatie. Eigenlijk ziet het ontwerp van WSL er prima uit. Bashware kan zijn gang gaan door het gebrek aan bewustzijn bij leveranciers van veiligheidsproducten. Deze technologie is immers nog betrekkelijk nieuw en verlegt de bekende grenzen van het Windows OS.

Toch zijn wij van mening dat leveranciers van veiligheidsproducten op korte termijn deze nieuwe technologie zullen moeten gaan ondersteunen, om aanvallen zoals die door Bashware worden getoond te kunnen voorkomen.

Microsoft heeft al stappen ondernomen om de veiligheidsleveranciers te helpen met de nieuwe veiligheidsprincipes die door WSL worden gepresenteerd, waaronder Pico API’s die AV-bedrijven kunnen gebruiken om dit type processen te monitoren.

Meer veiligheidsissues – Opheffing dubbele privileges

Afbeelding 3: Race Condition Bug Flow. Tekst in de afbeelding: 1 Aanvaller verandert het systeem door een ‘race condition’-bug te exploiteren in het WSL-installatieproces.
2. De gebruiker start WSL en laadt zo het kwaadaardige bestandssysteem dat door de aanvaller is gewijzigd. 

Tijdens het installatieproces van WSL is ‘LxRun.exe’ verantwoordelijk voor het downloaden en uitpakken van het Linux-bestandssysteem vanaf de servers van Microsoft. Buiten het blikveld wordt het bestandsysteem opgeslagen in een verborgen map in de %APPDAT%- directory als bestand met de naam ‘lxss.tar.gz’.

Nadat het archief van het bestandssysteem is opgeslagen gaat ‘LxRun.exe’ verder met het uitpakken in dezelfde directory. Als deze taak is voltooid, bevat de verborgen map een volledig Linux-bestandssysteem dat later wordt gebruikt door WSL, en meer specifiek door BASH.exe.

Microsoft heeft veel moeite gedaan om het Linux-bestandssysteem zelf te beveiligen, onder meer door te beletten dat de Linux-init en gangbare injectietechnieken kunnen worden veranderd (zoals LD.SO.PRELOAD, dat eerder werd besproken en uitgelegd door Alex Ionescu). Maar hoe zit het met de beveiligingsmechanismen van het bestandssysteem zelf?

Tijdens ons onderzoek ontdekten we dat het installatieproces van Linux kwetsbaar is voor een heel eenvoudige ‘race condition’. Als een aanvaller erin slaagt om het bestandssysteemarchief te wijzigen nadat het was gedownload, maar voordat het werd uitgepakt, kan de autheniticiteit van het bestandssysteem niet worden geverifieerd. Zo kan een aanvaller het bestandssysteem dus volledig veranderen en elk willekeurig Linux-bestandssysteem laden.

Het is bij het implementeren van deze techniek cruciaal om het precieze moment te herkennen waarop het archief moet worden geschakeld. We hebben het geluk dat Microsoft een SHA256 berekent voor het gedownloade bestandssysteem, dat een hash-waarde opslaat in een bestand zodra het downloadproces is voltooid en voordat het uitpakken begint. Het enige doel van deze waarde is aangeven op welk moment de bestandssysteemarchieven moeten worden geschakeld.

Wanneer iemand WSL wil gebruiken, draait hij ‘Bash.exe’, dat wordt uitgevoerd met toestemming van de gebruiker. Telkens wanneer WSL draait, worden automatisch NTFS-partities gemount onder /mnt in de Linux-omgeving, waardoor NTFS binnen de WSL kan worden gelezen, geschreven en uitgevoerd.

Afbeelding 4: Er wordt geprobeerd een bestand weg te schrijven in een System32-directory vanuit een Linux-omgeving – ongepriviligieerde ‘Bash.exe’

Wanneer een aanvaller een admin token gebruikt om Bash.exe te starten, zal Bash.exe + children gaan draaien met volledige admin token, waaronder alle privileges die ervoor zorgen dat UAC aan de Windows-kant wordt omzeild en volledig privilege-escalatie aan de Linux-kant.

Referenties

  1. Officiële Microsoft’s Blog en GitHub over WSL:
    • https://blogs.msdn.microsoft.com/wsl
    • https://github.com/Microsoft/BashOnWindows
  2. Alex Ionescu’s artikel over GitHub:
    • https://github.com/ionescu007/lxss – gewijd aan onderzoek, code en diverse studies naar het Windows Subsystem for Linux. Dit was een belangrijke bron van informatie en inspiratie tijdens dit project.
  3. Wine-projectWineHQ: een gratis open-source compatibiliteitslaag die Microsoft Windows-programma’s in staat stelt te draaien op Unixachtige besturingssystemen.

Bijlage A

WSL – Windows Subsystem for Linux

Toen onderzoeken uitwezen dat er veiligheidsfouten in WSL aanwezig waren, opende Microsoft een GitHub-pagina voor WSL, waar gebruikers fouten konden melden. Microsoft nam ook een aantal veiligheidsmaatregelen, zoals het verzenden van Windows 10 met deze functie standaard uitgeschakeld. Dit houdt in dat de drivers van WSL en de beheerdersonderdelen van de gebruikersmodus niet in het geheugen worden geladen, tot het moment waarop de WSF-functie handmatig wordt ingeschakeld (hieronder leggen we uit hoe dit gaat). Bovendien was de functie betiteld als bètaversie en werkte hij alleen wanneer de ontwikkelaarsmodus was ingeschakeld.

De WSL-functie behelst veel meer dan de oude vertrouwde ‘Bash’-shell van Linux op het Windows OS. Het is een volledige compatibiliteitslaag voor het draaien van een omgeving die eruitziet en zich gedraagt als Linux, waardoor het elke willekeurige Linux-code kan draaien: Linux-bouwsysteem, GNU-tools en wat er verder nodig is een applicatie te bouwen en te testen, zonder dat er virtuele machines opgestart hoeven te worden.

WSL omvat zowel onderdelen van de gebruikersmodus als van de kernelmodus:

  • User mode session manager service, die de levenscyclus van de Linux-instantie beheert (LxssManager.exe)
  • Pico Provider drivers (lxss.sys, lxcore.sys) die een Linux-kernel emuleren door de systeemaanroepen van Linux te vertalen
  • Picoprocessen (‘minimale processen’) die het ongewijzigde Linux-uitvoerbare bestand host (bijv. /bin/bash)

Picoprocessen

In het hart van het WSL-ontwerp bevindt zich een nieuw type proces, genaamd Pico. Picoprocessen zijn minimaal en missen de structurele blokken die in de reguliere Windows NT-processen gebruikelijk zijn (PEB, TEB, NTDLL, etc.). Picoprocessen zijn de containers die het mogelijk maken dat ELF-binaries op het Windows OS draaien.

Het concept van een Picoproces werd geïntroduceerd in een project met de naam Drawbridge, en werd oorspronkelijk gebruikt om een applicatie te laten draaien in een geïsoleerde omgeving (een vorm van virtualisatie voor het sandboxen van applicaties).

Eén manier om een geïsoleerde omgeving op te zetten is met behulp van een virtuele machine, maar dit kan leiden tot resource overhead. Het Drawbridgeproject had als doel deze overhead te beperken door de doelapplicatie te draaien in een lichtgewicht en veilige container. De container heeft een geïsoleerde adresruimte en wordt bediend door een onderdeel met de naam ‘Security Monitor’.

Ondanks het feit dat ze virtueel leeg zijn wanneer ze worden onderzocht vanuit het Windows OS, hebben Picoprocessen de mogelijkheid om te communiceren met een Windows NT-kernel. Deze interactie wordt mogelijk gemaakt door de Pico Provider – een speciale driver die verantwoordelijk is voor de vertaling van de transitie van Linux ELF naar een draaiend Windows-uitvoeringsbestand.

WSL gebruikt Picoprocessen als containers voor eigen Linux-binaries. Picoprocessen worden beheerd en bediend door een onderdeel van de kernel met de naam ‘Pico Provider’ (geïmplemeteerd in lxcore.sys). De driver van de Pico Provider verzendt systeemaanroepen en uitzonderingen van de gebruikersmodus die door de verschillende Picoprocessen worden gemaakt. De architectuur van deze processen/provider levert de basis voor het Windows Subsystem for Linux. Het eindresultaat van deze architectuur is dat eigen ongewijzigde Linux-binaries uitgevoerd kunnen worden door het laden van uitvoerbare ELF-binaries in een adresruimte van een Picoproces en door ze uit te voeren boven de Linux-compatibele laag van systeemaanroepen.

(Drawbridge project) (WSL)

Systeemaanroepen en Pico Providers

WSL voert ongewijzigde Linux ELF64-binaries uit door een Linux-kernelinterface te virtualiseren boven op de Windows NT-kernel. Een van de kernelinterfaces die het laat zien zijn systeemaanroepen (syscalls), een dienst die wordt aangeboden door de kernel die kan worden aangeroepen vanuit de gebruikersmodus.

Het Windows Subsystem for Linux bevat ook drivers voor de kernelmodus (lxss.sys en lxcore.sys). Pico Providers zijn verantwoordelijk voor het afhandelen van systeemaanroepen van Linux in coördinatie met de Windows NT-kernel. De drivers bevatten geen code uit de Linux-kernel, maar zijn een schone implementatie van Linux-compatibele kernelinterfaces.

Pico Providers zijn in feite op maat gemaakte kerneldrivers die de noodzakelijke callbacks uitvoeren om te reageren op de lijst van mogelijke gebeurtenissen die Picoprocessen kunnen losmaken. Wanneer er een systeemaanroepinstructie gedaan wordt, herkent de NT-kernel dat het verzoek afkomstig was van een Picoproces. Aangezien de NT-kernel niet weet hoe systeemaanroepen vanuit Picoprocessen moeten worden behandeld, slaat hij de registerstatus op en stuurt het verzoek door naar de Picodriver (lxcore.sys). De Picodriver bepaalt vervolgens welke Linux-systeemaanroep wordt gedaan, door het rax-register te controleren en vervolgens de parameters door te sturen met behulp van de registers die zijn bepaald door de aanroepconventie van Linux-systeemaanroepen. Zodra de Picodriver de systeemaanroep heeft behandeld, gaat hij terug naar de NT-kernel, die de registerstatus herstelt, de retourwaarde in rax plaatst en de instructie sysret\iretq geeft om terug te keren naar de gebruikersmodus.

Sessiebeheer van de gebruikersmodus
Wanneer de Bashterminal draait, draaien er talloze procedures onder Windows OS:

  • exe – een Windows-laadprogramma dat communiceert met LxssManager.exe en een nieuwe instantie van WSL oproept, die het gewenste proces uitvoert.
  • exe – een managementservice van de gebruikersmodus (de LxssManager.dll-service in SVCHOST.exe), die zorgt voor een naar buiten gerichte COM-interface, en informatie doorgeeft aan de Pico Provider via het Device Object.
  • Pico Provider driver (LXSS.SYS / LXCORE.SYS) die ervoor zorgt dat de kernelmodus een Linux-compatibele Kernel ABI en API implementeert, en een Device Object (\Device\lxss) voor ‘command & control’.

De gedetailleerde procedure die hierboven wordt uitgelegd start het Picoproces waarin de Linux-omgeving zich bevindt. Deze Linux-instantie zorgt ervoor dat de ELF-binaries kunnen worden gedraaid door middel van een interface die lxcore.sys exporteert. Lxcore.sys vangt alle ELF-systeemaanroepen op en verandert ze in NT-systeemaanroepen.

Uiteindelijk blijkt WSL een zeer handige en innovatieve functie te zijn die ontwikkelaars voorziet van de vertrouwde Bash-shell en Linux-omgeving waarin zij de meeste tools voor Linux-commandoregels kunnen uitvoeren, zonder dat er een virtuele Linux-machine hoeft te worden gecreëerd. Er is echter onvoldoende besef van de veiligheidsrisico’s die nog in het WSL-ontwerp aanwezig zijn, waardoor wij in staat waren om misbruik te maken van deze functie en ongemerkt kwaadaardige code konden draaien binnen een Linux-instantie.

Bijlage B

“Door de SECWATCHED™-certificering kan men nu aan de klanten laten zien dat het bedrijf vertrouwelijk en integer met de klantgegevens omgaat.”

- Directeur aanbieder Cloud-dienst met meer dan 250 klanten

SecWatch