playboisk8/poc-cve-2017-8464-opencalculatorSfruttare la vulnerabilità .lnk e i meccanismi di gestione del sistema operativo riguardanti explorer.exe e le unità USB.
Crea 1 Shortcut + 1 .DLL contenente payload dannoso => Mettilo in una USB e invialo alla vittima => la vittima apre la USB => il Payload si attiva automaticamente !
Prima di tutto dobbiamo sapere esattamente da dove nasce questo bug! È dovuto alla funzionalità chiamata Plug-and-Play (Collega e gioca) in cui il sistema operativo rileva automaticamente il dispositivo, alloca le risorse e carica il driver appropriato per farlo funzionare subito senza riavviare il computer. Quando inserisci una USB e apri la cartella con Esplora file di Windows explorer.exe, il sistema operativo scansiona i file per mostrare all'utente l'icona corrispondente!
Nelle vecchie versioni di Windows, Microsoft voleva che i collegamenti (shortcut .lnk) che puntano alle funzionalità del Pannello di controllo (in sostanza file .cpl o .dll) potessero mostrare le icone in modo dinamico e flessibile. Per questo, la libreria principale di gestione dell'interfaccia di Windows, shell32.dll, è stata progettata con una funzione chiamata
Usare LoadLibrary alla cieca: Per ottenere l'icona dal file applet del Pannello di controllo, il sistema operativo non legge un semplice file immagine statico, ma usa la funzione LoadLibraryW per caricare direttamente l'intera libreria a collegamento dinamico nello spazio di memoria del processo explorer.exe. Dopo averla caricata, chiama una funzione di esportazione standard, CPlApplet, per ottenere l'icona da visualizzare sullo schermo
Per dimostrare che LoadLibraryW è realmente coinvolta nella catena di exploit di cui sopra:
1/ Avvia
x64dbg với quyền admin2/ Collegati a
explorer.exe3/ Digita il comando
bp LoadLibraryW4/ Premi F9 per far continuare
explorer.exe5/ Inserisci la USB e si attiverà subito
hit breakpoint!
Ho avuto un problema: la catena di exploit era completamente silenziosa; anche cercando di controllare e fare debug di tutto, non riuscivo a trovare un modo per sistemarla! Poi ho provato a cercare il PoC di altri e a eseguirlo, ma falliva anch'esso!
Tuttavia, quando sono andato a pranzo e sono tornato, ho riacquistato concentrazione e calma. Ho iniziato a chiedermi: perché il PoC di quel tipo funzionava e sul mio computer no? Ok, ho iniziato a fare un po' di reverse engineering del suo .lnk e .dll e ho scoperto due cose!
1 / Il mio .dll era più lungo del suo! Ma non importa, non è quello il problema!
2 / Quando ho messo il .lnk in HxD per leggere le stringhe, ho scoperto che quel tipo non usa un percorso relativo, ma assoluto!
Relativo : ../example.dll
Assoluto : O:/example.dll
Ok, ora il modo per sistemare è: dobbiamo sapere quale lettera di unità verrà assegnata automaticamente alla USB quando viene inserita nel computer della vittima. A quel punto possiamo impostare il percorso assoluto e avremo successo. Sul mio Win7, quando inserisco una USB esce sempre la lettera F, quindi il mio comando di build era:
python Make_PoC.py FakeGoogleChrome F:\Pwned.dll
Poiché è un difetto di progettazione dell'architettura di sistema (Logic/Architecture Flaw) e non un errore di buffer overflow, Microsoft ha dovuto cambiare completamente il modo di gestire il Pannello di controllo:
.cpl o .dll caricati da un processo di sistema abbiano una firma digitale valida di Microsoft oppure si trovino in directory di sistema rigorosamente protette (come System32) per evitare il problema del "Binary Planting" dalla USB.explorer.exe [cite: 1058], le nuove versioni di Windows eseguono gli applet del Pannello di controllo tramite un processo intermedio isolato (come dllhost.exe o rundll32.exe). Se la DLL va in crash o contiene malware, farà crollare solo quel processo intermedio e non potrà controllare l'intero sistema dell'interfaccia utente.Ricerca VN
PoC
Tool per creare il .lnk vulnerabile