Come sai, il codice eseguito nell'enclave ha funzionalità seriamente limitate. Non può effettuare chiamate di sistema. Non può eseguire operazioni di I/O. Non conosce l'indirizzo di base del segmento di codice dell'applicazione host. Non può eseguire jmp o chiamare il codice dell'applicazione host. Non ha idea della struttura dello spazio degli indirizzi che governa l'applicazione host (ad esempio, quali pagine sono mappate o che tipo di dati si trovano su quelle pagine). Non può chiedere al sistema operativo di mappare ad esso una parte della memoria dell'applicazione host (ad esempio, tramite /proc/pid/maps). I tentativi ingenui di leggere ciecamente una regione di memoria arbitraria di un'applicazione host, per non parlare dei tentativi di scrittura, prima o poi (molto probabilmente il primo) porteranno alla chiusura forzata del programma enclave. Ciò accade ogni volta che la regione dello spazio degli indirizzi virtuali richiesta dall'enclave è inaccessibile all'applicazione host.
Considerando una realtà così dura, un autore di virus sarà in grado di utilizzare le enclavi SGX per raggiungere i suoi obiettivi dannosi?
Sulla base di quanto sopra, è generalmente accettato che un’enclave sia in grado di servire solo l’applicazione host e che non possa esercitare la propria iniziativa, comprese quelle dannose. Ciò significa che le enclavi non hanno alcun valore pratico per gli autori di virus. Questo presupposto affrettato è uno dei motivi per cui la protezione SGX è asimmetrica: il codice dell'applicazione host non può accedere alla memoria dell'enclave, mentre il codice dell'enclave può leggere e scrivere su qualsiasi indirizzo di memoria dell'applicazione host.
Pertanto, se il codice dell'enclave dannoso fosse in grado di effettuare chiamate di sistema arbitrarie per conto dell'applicazione host, eseguire codice arbitrario per suo conto, scansionare la memoria dell'applicazione host e trovare catene ROP abusive al suo interno, potrebbe prendere il controllo completo dell'applicazione host, in Modalità Nascosta. Non solo può rubare e crittografare i file dell'utente, ma anche agire per conto dell'utente. Ad esempio, invia e-mail di phishing per suo conto o esegui attacchi DoS. Senza timore nemmeno dei più moderni meccanismi di protezione, come l’impilamento dei canarini e la sanificazione degli indirizzi.
Ti mostreremo alcuni hack che gli aggressori utilizzano per superare le limitazioni sopra descritte e sfruttare SGX per i propri scopi dannosi: attacchi ROP. O per eseguire codice arbitrario mascherato da processo dell'applicazione host (simile al processo di svuotamento, spesso utilizzato dai malware), oppure per mascherare un malware già pronto (per salvare il malware dalla persecuzione da parte di antivirus e altri meccanismi di difesa).
Hack per sondare gli indirizzi per vedere se possono essere letti
Poiché l'enclave non sa quali intervalli dello spazio degli indirizzi virtuali sono accessibili all'applicazione host e poiché l'enclave è costretta a terminare quando tenta di leggere un indirizzo inaccessibile, l'aggressore deve affrontare il compito di trovare un modo per violare scansiona con tolleranza lo spazio degli indirizzi. Trova un modo per mappare gli indirizzi virtuali disponibili. Il cattivo risolve questo problema utilizzando in modo improprio la tecnologia TSX di Intel. Utilizza uno degli effetti collaterali di TSX: se la funzione di accesso alla memoria viene inserita in una transazione TSX, le eccezioni derivanti dall'accesso a indirizzi non validi vengono soppresse da TSX senza raggiungere il sistema operativo. Se si tenta di accedere a un indirizzo di memoria non valido, viene interrotta solo la transazione corrente, non l'intero programma dell'enclave. Quello. TSX consente a un'enclave di accedere in modo sicuro a qualsiasi indirizzo dall'interno di una transazione, senza il rischio di collasso.
se l'indirizzo specificato è disponibile applicazione host, la transazione TSX nella maggior parte dei casi ha esito positivo. In rari casi, potrebbe non riuscire a causa di influenze esterne come interruzioni (come quelle dello scheduler), rimozione della cache o modifica simultanea di una posizione di memoria da parte di più processi. In questi rari casi, il TSX restituisce un codice di errore che indica che l'errore è temporaneo. In questi casi è sufficiente riavviare la transazione.
se l'indirizzo specificato non è disponibile applicazione host, TSX elimina l'eccezione verificatasi (il sistema operativo non viene informato) e interrompe la transazione. Un codice di errore viene restituito al codice dell'enclave in modo che possa reagire al fatto che la transazione è stata annullata. Questi codici di errore indicano che l'indirizzo in questione non è disponibile per l'applicazione host.
Questa manipolazione di TSX dall'interno dell'enclave ha una caratteristica interessante per il cattivo: poiché la maggior parte dei contatori delle prestazioni hardware non vengono aggiornati nel momento in cui viene eseguito il codice dell'enclave, è impossibile tenere traccia delle transazioni TSX eseguite all'interno dell'enclave. Pertanto, la manipolazione dannosa del TSX rimane completamente invisibile al sistema operativo.
Inoltre, poiché l'hack di cui sopra non si basa su alcuna chiamata di sistema, non può essere rilevato né prevenuto semplicemente bloccando le chiamate di sistema; che di solito dà un risultato positivo nella lotta contro la caccia alle uova.
Il cattivo utilizza l'hack sopra descritto per cercare nel codice dell'applicazione host i gadget adatti a formare una catena ROP. Allo stesso tempo, non ha bisogno di sondare ogni indirizzo. È sufficiente sondare un indirizzo da ciascuna pagina dello spazio degli indirizzi virtuale. Il sondaggio di tutti i 16 gigabyte di memoria richiede circa 45 minuti (su un Intel i7-6700K). Di conseguenza, il cattivo riceve un elenco di pagine eseguibili adatte per costruire una catena ROP.
Hack per verificare la scrivibilità degli indirizzi
Per eseguire una versione enclave di un attacco ROP, un utente malintenzionato deve essere in grado di cercare aree di memoria scrivibili e inutilizzate dell'applicazione host. L'aggressore utilizza queste posizioni di memoria per iniettare un falso stack frame e per iniettare un payload (shellcode). Il punto è che un'enclave dannosa non è in grado di richiedere all'applicazione host di allocare memoria per se stessa, ma può invece utilizzare in modo improprio la memoria già allocata dall'applicazione host. Se, ovviamente, riesce a trovare tali aree senza far crollare l'enclave.
Il cattivo effettua questa ricerca sfruttando un altro effetto collaterale del TSX. Innanzitutto, come nel caso precedente, verifica l'esistenza dell'indirizzo, quindi controlla se la pagina corrispondente a questo indirizzo è scrivibile. Per fare ciò, il cattivo utilizza il seguente hack: inserisce una funzione di scrittura in una transazione TSX e, dopo averla completata, ma prima che sia completata, interrompe forzatamente la transazione (interruzione esplicita).
Osservando il codice restituito da una transazione TSX, l'aggressore capisce se è scrivibile. Se si tratta di un "aborto esplicito", il cattivo capisce che la registrazione avrebbe avuto successo se l'avesse portata avanti. Se la pagina è di sola lettura, la transazione termina con un errore diverso da "interruzione esplicita".
Questa manipolazione di TSX ha un'altra caratteristica che è utile per il cattivo (oltre all'impossibilità di tracciare attraverso i contatori delle prestazioni hardware): poiché tutti i comandi di scrittura della memoria vengono eseguiti solo se la transazione ha esito positivo, forzare il completamento della transazione garantisce che la cella di memoria sondata Rimane invariato.
Hack per reindirizzare il flusso di controllo
Quando si esegue un attacco ROP da un'enclave, a differenza degli attacchi ROP tradizionali, l'attaccante può ottenere il controllo del registro RIP senza sfruttare eventuali bug del programma attaccato (buffer overflow o qualcosa del genere). Un utente malintenzionato può sovrascrivere direttamente il valore del registro RIP memorizzato nello stack. In particolare può sostituire il valore di questo registro con la propria catena ROP.
Tuttavia, se la catena ROP è lunga, la sovrascrittura di una grossa porzione dello stack dell'applicazione host può causare il danneggiamento dei dati e un comportamento imprevisto del programma. Il cattivo, che cerca di portare avanti il suo attacco di nascosto, non è soddisfatto di questo stato di cose. Pertanto, crea un falso stack frame temporaneo per se stesso e memorizza la sua catena ROP al suo interno. Il falso stack frame viene posizionato in una posizione di memoria scrivibile casuale, lasciando intatto lo stack reale.
Cosa danno al cattivo i tre hack sopra elencati?
(1) Innanzitutto, l'enclave dannosa hack per sondare gli indirizzi per vedere se possono essere letti, – cerca nell'applicazione host gadget ROP abusivi.
(2) Poi da hack per verificare la scrivibilità degli indirizzi, – un’enclave dannosa identifica le aree nella memoria dell’applicazione host adatte per iniettare un payload.
(3) Successivamente, l'enclave crea una catena ROP dai gadget scoperti nel passaggio (1) e inserisce questa catena nello stack dell'applicazione host.
(4) Infine, quando l'applicazione host incontra la catena ROP creata nel passaggio precedente, il payload dannoso inizia l'esecuzione, con i privilegi dell'applicazione host e la possibilità di effettuare chiamate di sistema.
Come un cattivo usa questi hack per creare ranzowari
Dopo che l'applicazione host ha trasferito il controllo all'enclave attraverso uno degli ECALL (senza sospettare che questa enclave sia dannosa), l'enclave dannosa cerca spazio libero nella memoria dell'applicazione host per iniettare codice (prendendo come spazi liberi quelle sequenze di celle quello pieno di zeri). Poi attraverso hack per sondare gli indirizzi per vedere se possono essere letti, – l'enclave cerca pagine eseguibili nell'applicazione host e genera una catena ROP che crea un nuovo file denominato "RANSOM" nella directory corrente (in un attacco reale, l'enclave crittografa i file utente esistenti) e visualizza un messaggio di riscatto. Allo stesso tempo, l'applicazione host crede ingenuamente che l'enclave stia semplicemente sommando due numeri. Che aspetto ha questo nel codice?
Per facilità di percezione, introduciamo alcuni mnemonici attraverso le definizioni:
Salviamo i valori originali dei registri RSP e RBP per ripristinare il normale funzionamento dell'applicazione host dopo aver eseguito il payload:
Stiamo cercando uno stack frame adatto (vedi il codice dalla sezione "hack per reindirizzare il flusso di controllo").
Trovare i gadget ROP adatti:
Trovare un posto dove iniettare il carico utile:
Costruiamo una catena ROP:
È così che la tecnologia SGX di Intel, progettata per contrastare i programmi dannosi, viene sfruttata dai criminali per raggiungere obiettivi opposti.
Fonte: habr.com