fortra/cve-2022-30136Exploit remoto per Windows Network File System per CVE-2022-30136
autore: Ricardo Narvaja
Solo a scopo dimostrativo. L'exploit completo funziona su sistemi Windows Server vulnerabili.
Consulta l'analisi Analysis of CVE-2022-30136 “Windows Network File System Vulnerability“.
Ho voluto scrivere questo articolo per dimostrare l'analisi che ho svolto durante lo sviluppo dell'exploit di Core Impact “Windows Network File System Remote” che abusa della vulnerabilità CVE-2022-30136.
La vulnerabilità di esecuzione remota di codice in Windows Network File System è un errore di calcolo della dimensione che si verifica quando si crea la risposta del server in una COMPOUND REQUEST utilizzando la versione 4.1 di NFS.
Il server calcola una dimensione inferiore al necessario per allocare il pool, e poi, quando copia i dati per generare la risposta, causa un overflow del buffer.
La funzione Nfs4SvrXdrpGetEncodeOperationResultByteCount in nfssvr.sys viene chiamata per ogni operazione e restituisce una dimensione inferiore al necessario (4 byte in meno per ogni operazione).
È stata applicata una patch per Nfs4SvrXdrpGetEncodeOperationResultByteCount.
Questa funzione viene chiamata durante ogni OPERAZIONE di una COMPOSE REQUEST per restituire i byte necessari per ciascuna in base all'OPCODE. Viene poi aggiunta all'intestazione e ad altre parti della risposta. Successivamente, calcola la dimensione finale dell'intera risposta da allocare e poi vi copia sopra per rispondere.
In ogni caso, possiamo vedere che il valore della dimensione restituita per ogni operazione è di quattro byte inferiore nella versione vulnerabile rispetto a quella patchata.
Ho creato il POC per Windows Server 2019.
Di seguito è mostrata la versione vulnerabile di nfssvr.sys utilizzata per questo POC, seguita dalla versione patchata per Windows Server 2019:
L'immagine seguente mostra il CASE 26 nel diff:
Nell'esempio del CASE 26, possiamo vedere che la costante aggiunta al valore calcolato è 0x2c nella versione vulnerabile e 0x30 in quella patchata.
Lo stesso si può vedere in ogni caso corrispondente a ciascun OPCODE. Quello vulnerabile restituisce sempre una dimensione di quattro byte inferiore rispetto a quello patchato.
Non mostreremo tutti i casi perché la patch è simile per tutti gli OPCODE.
Il genitore di Nfs4SvrXdrpGetEncodeOperationResultByteCount è Nfs4SvrXdrEncodeCompoundResults. Legge il numero di operazioni inviate nella COMPOUND REQUEST.
In questo POC il valore è 0x34 (52d). Quando il mio POC si connette al server sulla porta 2049 (la porta predefinita per NFS), devo posizionare un breakpoint condizionale per un arresto.
In questo caso, si ferma quando number_of_operations=0x34.
Il pool con tag ARGS viene allocato qui.
Creerò quindi una struttura chiamata TAG_ARGS_0x10e0 per fare reverse engineering dei campi.
Copia number_of_operations in r13 e itera nella funzione vulnerabile una volta per operazione, fino a quando il contatore raggiunge il valore di r13.
Mostra che il primo package_OPCODE = 0x35, che corrisponde a SEQUENCE nella prima operazione obbligatoria in una COMPOUND REQUEST. Nell'immagine sottostante, la freccia punta a questo OPCODE nel mio pacchetto.
Qui possiamo vedere gli argomenti della funzione vulnerabile.
All'interno della funzione vulnerabile legge l'OPCODE e va al CASE corrispondente.
Tre viene sottratto dal valore OPCODE originale (53).
E salta al CASE 50, restituendo 0x28 come dimensione necessaria per questa operazione.
Possiamo vedere nel diff come la versione patchata restituisca 0x2c.
Questo valore restituito viene aggiunto al valore precedente di altri campi nella risposta per calcolare la dimensione delle operazioni. In questo caso, questo valore è 0X40c.
Di seguito possiamo vedere i valori che vengono aggiunti:
Quando esce dal ciclo, viene calcolata la dimensione totale. In questo caso, la dimensione totale è 0x1310.
Possiamo intuire la differenza tra la versione vulnerabile e quella patchata calcolando la dimensione, utilizzando la formula: number_of_operations * 4.
In questo caso l'allocazione nella versione patchata sarà 0x34 * 4 = 0x68 maggiore rispetto alla versione vulnerabile.
Successivamente aggiunge 0x24. Questo valore viene calcolato in modo simile sia nella versione vulnerabile che in quella patchata.
Poi aggiunge la costante 0xf in entrambi i casi.
Fino a questo punto, la dimensione in questo esempio è stata 0x1340.
Successivamente raggiunge rpcxdr_OncRpcBufMgrpAllocate.
Poi si sposta in r15.
Sottrae uno e aggiunge quattro. Poi confronta con 0x800.
Questa dimensione calcolata erroneamente viene utilizzata solo se è maggiore di 0x800. Per questo motivo, solo una COMPOUND REQUEST attiverà il bug.
Prima alloca un pool con dimensione = 0x80 e tag XdBD.
Infine, alloca qui il pool per la risposta con dimensione 0x1398, che aggiunge alcuni valori costanti.
Alloca quindi 0x13a0 (inclusi tag XdBP e intestazione).
Da lì, memorizza l'indirizzo del nuovo pool allocato nel campo: tag_XdBD_0x80.p_TAG_XDBP_0x13a0.
Questo punta all'indirizzo della risposta in cui viene sempre copiato.
Poi inizierà a costruire l'intestazione della risposta.
Quello che segue è un esempio di come salva i dati nel contenuto di un puntatore temporaneo e aggiunge quattro.
Di seguito possiamo vedere come copia nel contenuto dell'indirizzo di risposta.
Questo scrive il primo dword e incrementa il puntatore di quattro.
Poi scrive il secondo dword e aggiunge quattro.
Dopo essere uscito dalla funzione, l'intera intestazione è scritta.
Successivamente ritorna a nfssvr.sys per continuare a scrivere la risposta.
Continuerà a decodificare e scrivere nella risposta, aggiungendo quattro al puntatore temporaneo.
Quando completa l'intestazione, raggiunge questo ciclo per scrivere tutte le operazioni. Inizia con il primo OPCODE 0x35.
Possiamo vedere che scrive 0x428 dall'inizio del pool.
Ora punta dopo il tag.
Impostando un breakpoint qui, possiamo vedere come sono state scritte tutte le operazioni.
Dopo essere usciti dal ciclo, tutte le operazioni sono state copiate.
Controlliamo la fine del pool.
Lì possiamo vedere la scrittura dopo il limite.
L'allocazione è più piccola dei dati copiati, producendo un overflow del pool.
Questo produce un BSOD nella macchina target. Tuttavia, la domanda è: possiamo ottenere un'esecuzione remota di codice, o un Write what where?
Ho provato diverse combinazioni di opcode per ottenere una risposta con dati controllati nei byte overflowati. Sfortunatamente, non ho avuto fortuna.
Il tag massimo (controllato da me) può essere posizionato solo all'inizio e ha una dimensione massima di 0x400.
Tutti gli altri opcode che ho provato non rispondono con dati controllati. Di conseguenza, non credo sia possibile o, almeno, è incredibilmente difficile ottenere un RCE o elevare i privilegi con questo bug. Detto questo, potrebbe comunque essere possibile, poiché non ho provato tutte le combinazioni tra il grande numero di possibilità esistenti.
Per la costruzione del POC ho provato con un client chiamato “NFS CLIENT”. Supporta NFS 4.1 e sono stato in grado di provare diversi opcode copiando file, modificando, creando cartelle, ecc.
In questa build, ho potuto creare un pacchetto COMPOUND di esempio e regolare la dimensione, il client id, il session id, ecc.
Successivamente, ho inviato un EXCHANGE_ID per ottenere il client id, usandolo per inviare un CREATE_SESSION e infine la grande COMPOUND REQUEST.
A questo punto abbiamo sfruttato il bug, che porta a un'esecuzione remota di codice consentendo un attacco DoS.
Speriamo che lo troviate utile, se avete domande potete contattarci all'indirizzo [email protected].
Buon divertimento!
