Utilità da riga di comando di Windows per leggere, scrivere ed eseguire codice in modalità kernel dal contesto di Amministratore utilizzando una tecnica di reindirizzamento dell'esecuzione tramite validazione dei font, consentendo debug avanzato del kernel e risoluzione dei problemi di sistema.
r0ak è un'utilità da riga di comando per Windows che consente di leggere, scrivere ed eseguire codice in modalità kernel (con alcune limitazioni) dal prompt dei comandi, senza richiedere altro che privilegi di Amministratore.
r0ak v1.0.0 -- Ring 0 Army Knife
http://www.github.com/ionescu007/r0ak
Copyright (c) 2018 Alex Ionescu [@aionescu]
http://www.windows-internals.com
USAGE: r0ak.exe
[--execute <Address | module.ext!function> <Argument>]
[--write <Address | module.ext!function> <Value>]
[--read <Address | module.ext!function> <Size>]
Il kernel di Windows è un ambiente ricco in cui centinaia di driver vengono eseguiti su un sistema tipico, e dove sono presenti migliaia di variabili contenenti stato globale. Per la risoluzione avanzata dei problemi, gli esperti IT utilizzano solitamente strumenti come il Windows Debugger (WinDbg), gli strumenti SysInternals o scrivono i propri. Sfortunatamente, l'uso di questi strumenti sta diventando sempre più difficile e sono essi stessi limitati dal proprio accesso alle API di Windows e alle funzionalità esposte.
Alcune delle sfide odierne includono:
In un tale ambiente, era chiaro che uno strumento semplice, utilizzabile come cerotto/hotfix di emergenza e per risolvere rapidamente problemi a livello di kernel/sistema che potrebbero essere evidenti analizzando lo stato del kernel, potrebbe essere prezioso per la comunità.
r0ak funziona reindirizzando il flusso di esecuzione dei controlli di validazione dei font attendibili del gestore delle finestre quando si tenta di caricare un nuovo font, sostituendo la routine di confronto della tabella dei font attendibili con una funzione alternativa che pianifica un elemento di lavoro esecutivo (WORK_QUEUE_ITEM) memorizzato nel nodo di input. Quindi, il figlio destro della tabella dei font attendibili (che funge da nodo radice) viene sovrascritto con un buffer di scrittura di una named pipe (NP_DATA_ENTRY) in cui è memorizzato un elemento di lavoro personalizzato. La funzione di lavoro sottostante di questo elemento e il suo parametro verranno eventualmente eseguiti da un ExpWorkerThread dedicato a PASSIVE_LEVEL una volta che si tenta di caricare un font e la routine di confronto viene eseguita, ricevendo come input il nodo padre basato sulla named pipe. Un evento di traccia ETW (Event Tracing for Windows) in tempo reale viene utilizzato per ricevere una notifica asincrona che l'elemento di lavoro ha terminato l'esecuzione, rendendo sicuro smantellare le strutture, liberare i buffer in modalità kernel e ripristinare il funzionamento normale.
Quando si utilizza l'opzione --execute, questa funzione e parametro vengono forniti dall'utente.
Quando si utilizza --write, viene utilizzato un gadget personalizzato per modificare valori arbitrari a 32 bit in qualsiasi punto della memoria del kernel.
Quando si utilizza --read, il gadget di scrittura viene utilizzato per modificare il puntatore e la dimensione del buffer HSTI del sistema (N.B.: Questo è un comportamento distruttivo in termini di qualsiasi altra applicazione che richiederà i dati HSTI. Poiché questo è un comportamento opzionale di Windows e questo strumento è destinato al debug/sperimentazione di emergenza, questa perdita di dati è stata considerata accettabile). Quindi, l'API di interrogazione HSTI viene utilizzata per copiare i dati nello spazio degli indirizzi in modalità utente dello strumento e viene mostrato un dump esadecimale.
Poiché vengono utilizzate solo funzionalità Windows integrate, firmate da Microsoft, e tutte le funzioni chiamate fanno parte della bitmap KCFG, non vi è alcuna violazione di alcun controllo di sicurezza e non sono richiesti flag di debug o l'uso di driver di terze parti mal scritti.
No. Poiché questo strumento — e la tecnica sottostante — richiedono un token privilegiato a livello SYSTEM, ottenibile solo da un utente che esegue un account Amministratore, non vengono bypassati confini di sicurezza per ottenere l'effetto. Il comportamento e l'utilità dello strumento sono possibili solo grazie al contesto di sicurezza elevato/privilegiato dell'account Amministratore su Windows, ed è inteso come un comportamento di progettazione.
Certo! È importante segnalare sempre i problemi di sicurezza a Microsoft anche quando non sembra esserci violazione dei confini privilegiati — i loro team di ricercatori e sviluppatori potrebbero trovare nuovi vettori e modi per raggiungere determinati percorsi di codice a cui un ricercatore esterno potrebbe non aver pensato.
Pertanto, nel novembre 2014, è stato presentato un caso di sicurezza al Microsoft Security Research Centre (MSRC) che ha risposto: "[…] non rientra nell'ambito di un problema di sicurezza che affronteremmo tramite il nostro veicolo tradizionale di bollettini di sicurezza. […] presuppone privilegi di amministratore — un luogo in cui, a livello architetturale, non definiamo attualmente un confine di sicurezza difendibile. Pertanto, non perseguiremo la correzione di questo problema."
Inoltre, nell'aprile 2015 alla conferenza Infiltrate, è stata presentata una presentazione intitolata Insection : AWEsomely Exploiting Shared Memory Objects che dettagliava questo problema, anche a sviluppatori Microsoft presenti, i quali hanno concordato che questo era attualmente fuori dall'ambito dei confini di sicurezza architetturale di Windows. Questo perché esistono letteralmente dozzine — se non di più — di altri modi in cui un Amministratore può leggere/scrivere/eseguire memoria in Ring 0. Questo strumento consente semplicemente una facile commodificazione di uno di questi vettori, a scopo di debug e risoluzione dei problemi di sistema.
Impacchettare questo codice come libreria richiederebbe di rimuovere attentamente tutta l'interazione di parsing della riga di comando e l'output standard, a quel punto, senza riscritture importanti, il 'kit':