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.
