CVE-2021-40444 completamente armato

Generatore di docx dannosi per sfruttare CVE-2021-40444 (Esecuzione remota di codice in Microsoft Office Word), funziona con file DLL arbitrari.

Contesto

Sebbene molti PoC siano già presenti in rete, ho pensato di cimentarmi nell'armamento di questa vulnerabilità, poiché ciò che ho trovato disponibile mancava di informazioni preziose da condividere, considerando anche che Microsoft ha già rilasciato una patch per questa vulnerabilità.

Finora, le uniche risorse preziose che ho visto per creare un generatore completamente funzionante sono:

• Blog di Ret2Pwn
• Tweet di j00sean

Le risorse sopra indicate descrivono molti dei requisiti necessari per creare una catena completa. Per evitare di ripetere troppe informazioni non necessarie, mi limiterò a riassumere i dettagli rilevanti.

Catena dell'exploit

1. Docx aperto
2. La relazione memorizzata in document.xml.rels punta a un HTML dannoso
3. Viene avviata l'anteprima di IE per aprire il collegamento HTML
4. JScript all'interno dell'HTML contiene un oggetto che punta a un file CAB e un iframe che punta a un file INF, preceduto dalla direttiva ".cpl:"
5. Il file cab viene aperto, il file INF viene memorizzato nella directory %TEMP%\Low
6. A causa di una vulnerabilità di Path traversal (ZipSlip) nel CAB, è possibile memorizzare l'INF in %TEMP%
7. Quindi, il file INF viene aperto con la direttiva ".cpl:", causando il side-loading del file INF tramite rundll32 (se questo è una DLL)

Requisiti trascurati

Ci sono parecchi requisiti trascurati affinché questo exploit funzioni, che hanno causato il fallimento anche di buoni PoC, come quello di lockedbyte.

Forse nessuno li ha esplicitamente "rilasciati" per evitare che la vulnerabilità venisse sfruttata ulteriormente. Ma ora è stata patchata, quindi non dovrebbe causare molti problemi rilasciare i dettagli.

File HTML

Secondo questo tweet di Will Dormann, l'HTML deve essere di almeno 4096 byte per attivare l'"Anteprima" in MS Word.

File CAB

Il file CAB deve essere modificato a livello di byte per evitare errori di estrazione e per ottenere lo ZipSlip:

• filename.inf deve diventare ../filename.inf
• filename.inf dovrebbe essere esattamente <12-char>.inf Non è vero, la parte importante è modificare coffCabStart
• CFFOLDER.typeCompress dovrebbe essere 0 (non compresso)
• CFFOLDER.coffCabStart deve essere aumentato di 3 (a causa dell'aggiunta di '../')
• CFFOLDER.cCfData dovrebbe essere 2
• CFFILE.cbFile deve essere maggiore dell'intero CFHEADER.cbCabinet
• CFDATA.csum dovrebbe essere ricalcolato (o azzerato) [OPZIONALE]

Le ragioni di questi vincoli sono molteplici e non ho dedicato abbastanza tempo per comprenderli tutti a fondo, ma vediamo i più importanti:

• TypeCompress: Se il CAB è compresso, il trucco di aprirlo all'interno di un file oggetto per attivare la scrittura dell'INF fallirà Falso, sono riuscito a ottenere lo stesso risultato con un campione compresso con MSZIP
• CoffCabStart: CoffCabStart fornisce la posizione assoluta della prima struttura CFDATA, poiché abbiamo aggiunto '../', dovremmo aumentare questo valore di 3 per puntare al file (è più un'ipotesi)
• cCfData: Poiché c'è un solo file, dovremmo avere solo 1 CFDATA, non sono sicuro del perché debba essere impostato a 2 In effetti, possiamo lasciarlo a 1
• cbFile: È interessante notare che, se l'estrazione del CAB si conclude senza errori, il file INF verrà contrassegnato per l'eliminazione da WORD, rovinando l'exploit. L'unico modo per evitarlo è far credere a WORD che l'estrazione sia fallita. Se il valore di cbFile è definito come maggiore del file cabinet stesso, l'estrattore raggiungerà un EOF prima di leggere tutti i byte definiti in cbFile, generando un errore di estrazione.
• [OPZIONALE] Questo valore sembra non essere verificato da MS Word. Comunque, per avere un CAB corretto, il valore csum dovrebbe essere ricalcolato. Fortunatamente, come notato da j00sean e secondo la documentazione MS, questo valore può essere 0

NOTA1: Defender ora rileva se il file CAB contiene un PE utilizzando il valore _IMAGE_DOS_HEADER.e_magic come firma, potenzialmente evitando che i file PE vengano incorporati nel CAB. È possibile aggirare questa firma? Non ne sono sicuro, ma come osservato in precedenza, questa è una vulnerabilità patchata, quindi non ho intenzione di investire molto più tempo su questo. Spetta al lettore curioso sviluppare ulteriormente.

NOTA2: La patch di Microsoft blocca schemi URI arbitrari, apparentemente usando un approccio di blacklist (questa è solo una supposizione)

Attacco DLL

La catena di attacco principale associata a CVE-2021-40444 è l'attacco DLL caricato tramite lo schema URI .cpl. Per sfruttarlo, un attaccante deve generare una DLL appositamente predisposta. Se vuoi provarlo, usa il mio script evildll-gen.

JScript, VBScript, Javaw, MSIexec, ...

Come notato da Max Maluin, è possibile interagire con diversi tipi di file abusando di IE e dell'URI basato sull'estensione del file associato. Sebbene possa essere un buon modo per sfruttare IE, ha dei limiti.

In effetti, va notato che il metodo utilizzato nell'exploit per scaricare file si basa sugli aggiornamenti dei controlli ActiveX e non può essere utilizzato per scaricare file arbitrari. Secondo la documentazione di Microsoft, il tag codebase può puntare solo a pochi tipi di file: OCX, INF e CAB.

Anche se possiamo scaricare direttamente un file OCX o INF, non possiamo ancora essere sicuri di scaricare il file nella posizione corretta all'interno del sistema. Con l'exploit del cab, è possibile spostare il file .inf in un percorso noto utilizzando il path traversal, ma in qualsiasi altro caso il file verrà memorizzato in una directory casuale, rendendo praticamente impossibile fare riferimento ad esso.

Ad oggi, non ho trovato un modo per concatenare download ed esecuzione SENZA un file CAB.

Nota: Parlando solo di IE, lo smuggling HTML potrebbe essere uno scenario possibile per sfruttare la vulnerabilità.

Attacco senza file CAB utilizzando file RAR ibrido

Questa tecnica è stata divulgata per la prima volta da Eduardo Braun su Twitter e ulteriormente spiegata in questo documento.

Si noti che utilizzando questa tecnica, la catena di attacco è leggermente diversa. Questo attacco richiede che l'utente scarichi un file RAR appositamente predisposto, ottenuto concatenando uno script WSF valido e un file RAR valido. Una volta aperto, il RAR conterrà un DOCX con un riferimento a un HTML, che a sua volta tenterà di caricare il file RAR come script WSF.

Per riassumere:

1. Viene scaricato un file RAR appositamente predisposto (probabilmente nella cartella Download)
2. DOCX estratto e aperto
3. La relazione memorizzata in document.xml.rels punta a un HTML dannoso
4. Viene avviata l'anteprima di IE per aprire il collegamento HTML
5. JScript all'interno dell'HTML contiene uno script/iframe che punta al file RAR, preceduto dallo schema URI ".wsf:"
6. Poiché il RAR è stato progettato per essere contemporaneamente un RAR valido e uno script WSF valido, lo script viene eseguito