tiagob0b/cve-2021-40444Mal generatore di DOCX che sfrutta CVE-2021-40444 (RCE di Microsoft Office Word) con side-loading di DLL basato su CAB e catene di attacco RAR/WSF senza CAB per test di penetrazione.
Generatore di docx malevoli per sfruttare CVE-2021-40444 (Remote Code Execution in Microsoft Office Word), funziona con file DLL arbitrari.
Sebbene molti PoC siano già presenti su Internet, ho deciso di cimentarmi nell'armare questa vulnerabilità, poiché ciò che ho trovato disponibile mancava di informazioni preziose che vale la pena 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:
Le risorse sopra citate delineano molti dei requisiti necessari per creare una catena completa. Per evitare di ripetere troppe informazioni inutili, mi limiterò a riassumere i dettagli rilevanti.
Ci sono parecchi requisiti trascurati perché questo exploit funzioni, che hanno fatto sì che anche buoni PoC, come quello di lockedbyte, fallissero nel funzionare correttamente.
Forse nessuno li ha "rilasciati" esplicitamente per evitare che la vulnerabilità fosse sfruttata ulteriormente. Ma ora è stata patchata, quindi non dovrebbe causare troppi problemi rilasciare i dettagli.
Come da questo tweet di Will Dormann, l'HTML dovrebbe avere una dimensione di almeno 4096 byte per attivare la "Preview" in MS Word.
Il file CAB deve essere patchato a livello di byte per evitare errori di estrazione e per ottenere lo ZipSlip:
filename.inf dovrebbe diventare ../filename.inffilename.inf coffCabStartCFFOLDER.typeCompress CFFOLDER.coffCabStart dovrebbe essere aumentato di 3 (a causa dell'aggiunta di '../'')CFFOLDER.cCfData CFFILE.cbFile dovrebbe essere maggiore dell'intero CFHEADER.cbCabinetCFDATA.csum Le ragioni di questi vincoli sono molte, e non ho passato abbastanza tempo per comprenderli a fondo tutti, ma vediamo i più importanti:
NOTA1: Defender ora rileva se il file CAB contiene un PE utilizzando il valore _IMAGE_DOS_HEADER.e_magic come
firma, impedendo potenzialmente che i file PE vengano incorporati nel CAB. Può questa firma essere aggirata?
Non ne sono sicuro ma, come osservato in precedenza, questa è una vulnerabilità patchata, quindi non ho intenzione di investire molto altro tempo
su questo. Sta al lettore curioso sviluppare ulteriormente la cosa.
NOTA2: La patch Microsoft blocca schemi URI arbitrari, apparentemente usando un approccio blacklist (questa è solo una supposizione)
La principale catena di attacco associata a CVE-2021-40444 è l'attacco DLL caricato tramite lo schema URI .cpl. Per
sfruttarlo, un attaccante deve generare una DLL appositamente creata. Se vuoi provarlo, prova il mio script evildll-gen.
Come notato da Max Maluin, è possibile interagire con diversi tipi di file abusando di IE e dell'URI associato basato sull'estensione del file. Sebbene questo possa essere un buon modo per sfruttare IE, ha dei limiti.
In effetti, va notato che il metodo usato nell'exploit per scaricare file si basa sugli aggiornamenti dei controlli ActiveX
e non può essere usato per scaricare file arbitrari.
Secondo la documentazione Microsoft, il tag codebase
può puntare solo ad alcuni tipi di file: OCX, INF e CAB.
Anche se possiamo scaricare direttamente un file OCX o INF, non possiamo comunque essere sicuri di scaricare il file nella posizione giusta
all'interno del sistema. Con l'exploit CAB, è possibile spostare il file .inf in un percorso noto usando il path traversal,
ma in qualsiasi altro caso il file verrà archiviato in una directory casuale, rendendo praticamente impossibile referenziarlo.
Ad oggi, non ho trovato un modo per concatenare download ed esecuzione SENZA un file CAB.
Nota: Parlando solo di IE, l'HTML smuggling potrebbe essere uno scenario possibile per sfruttare la vulnerabilità.
Questa tecnica è stata divulgata per la prima volta da Eduardo Braun su Twitter e ulteriormente spiegata in questo documento.
Si noti che usando questa tecnica, la catena di attacco è leggermente diversa. Questo attacco richiede che l'utente scarichi un file RAR appositamente creato, 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: