PrintNightmare, il nome dato a un gruppo di vulnerabilità che affliggono il servizio Print Spooler di Windows, continua a essere un argomento caldo. Il nostro precedente blog sul tema spiegava le misure urgenti da prendere per mitigare le prime due vulnerabilità segnalate, CVE-2021-1675 e CVE-2021-34527. Tuttavia, i ricercatori stanno ancora scoprendo nuove vulnerabilità collegate, che i cybercriminali potrebbero ancora sfruttare.
Le ragioni per cui il servizio Windows Print Spooler sta ricevendo così tanta attenzione sono:
- l’alto impatto delle vulnerabilità accoppiato all’uso diffuso del servizio interessato in ambienti aziendali;
- l’alta disponibilità di exploit verso il pubblico;
- l’apparente inadeguatezza delle patch rilasciate da Microsoft per rimediare completamente alla minaccia.
In questo blog, gli specialisti dei Nozomi Networks Labs mostrano i passi che i security engineer possono seguire per verificare se i sistemi di interesse rimangono vulnerabili ai noti PoC (Proof of Concepts) di exploit popolari, concentrandoci sui casi a maggiore impatto associati alla vulnerabilità RCE (Remote Code Execution), piuttosto che sugli exploit relativi a LPE (Local Privilege Escalation).
Mostrando come appare un attacco riuscito sul file system e a livello di rete, questo blog può aiutare a determinare se i sistemi rimangono vulnerabili o meno.
PrintNightmare RCE PoC
Quando la notizia di PrintNightmare ha raggiunto tutti i principali canali informativi, diversi exploit RCE erano già disponibili per tutti, compresi i cybercriminali. Erano scritti in diversi linguaggi di programmazione e avevano un aspetto leggermente diverso nel traffico di rete. Tuttavia, tutti gli exploit RCE richiedono credenziali valide dal sistema vulnerabile, così come un payload effettivamente eseguibile. Gli eseguibili devono essere sotto forma di DLL e disponibili in una share SMB, accessibile dall’host di destinazione.
Ecco i più popolari PoC RCE di PrintNightmare, insieme ad alcune peculiarità tecniche ad essi associate.
NB: Esercitate sempre estrema cautela quando compilate ed eseguite strumenti PoC di exploit. Considerate di effettuare una revisione del codice per maggiore sicurezza. E notate che se gli step seguenti non rivelano nulla, questo non garantisce che i sistemi testati siano completamente sicuri contro questa minaccia.
PrintNightmare Exploit PoC 1
https://github.com/afwu/PrintNightmare [inaccessibile – vedi link sotto]
Linguaggio di programmazione: C++
Impatto: RCE
Dipendenze esterne: No
Al momento della pubblicazione del blog, l’autore del nostro primo exploit aveva già reso inaccessibile il suo repository. Tuttavia, gli specialisti della sicurezza possono ancora ottenere accesso al codice sorgente sul WebArchive: https://web.archive.org/web/*/https://github.com/afwu/PrintNightmare
Il codice dell’exploit è distribuito come soluzione autonoma di Visual Studio, che richiede pochi secondi per essere creata e utilizzata. Il file risultante, di default, si chiama POC.exe. Come argomenti della riga di comando, accetta i dettagli del sistema target (indirizzo IP e credenziali valide), e il percorso verso la DLL del payload.
Una nota importante, il percorso di DriverStore incorporato nel codice sorgente C:\Windows\System32\DriverStore\FileRepository\ntprint.inf_amd64_19a3fe50fa9a21b6\Amd64\UNIDRV.DLL non è universale e non funziona su tutti i sistemi a 64 bit:
Gli autori degli altri PoC hanno affrontato questo problema risolvendo il percorso dinamicamente o lasciando che l’attaccante lo specificasse come argomento della linea di comando.
Host Machine
Ecco come appare la linea di comando corrispondente, dove 172.16.7.50 è la macchina host, 172.16.7.52 è la macchina vittima e test.dll è un qualsiasi file pulito:
Ecco l’output del tool se tutto è andato come previsto:
Target Machine
Se la macchina target è ancora vulnerabile, la seguente attività può essere vista nel monitor dei file (in questo caso, parte del Process Monitor di Sysinternals):
Come possiamo vedere qui, il sistema colpito ha letto con successo la DLL del payload dalla share SMB prima di caricarla. Suggeriamo di filtrare per nome il processo spoolsv.exe per navigare più rapidamente tra i risultati.
Ecco come apparirà il traffico di rete registrato (filtrato per indirizzi IP):
PrintNightmare Exploit PoC 2
Linguaggio di programmazione: Python
Impatto: RCE
Dipendenze esterne: Sì, un toolset Impacket personalizzato
Qui, il PoC risolve dinamicamente il suddetto percorso DriverStore per la macchina di destinazione, quindi questo exploit è più universale. Oltre all’effettivo script di exploit, è necessario un pacchetto impacket per farlo funzionare, che può trovarsi in un altro repository dello stesso autore.
Host machine
Ecco la linea di comando corrispondente per eseguirlo:
Così appare il normale output dello strumento una volta eseguito:
Target Machine
Se la macchina target rimane vulnerabile, la seguente attività sarà rivelata nel Process Monitor in esecuzione:
Similmente al precedente PoC, il sistema vulnerabile è stato costretto a ottenere la DLL del payload dalla SMB share prima di caricarla.
Ecco un frammento del traffico di rete corrispondente:
PrintNightmare Exploit PoC 3
Linguaggio di programmazione: C#
Impatto: RCE
Dipendenze esterne: No
L’autore è lo stesso dell’exploit precedente, ma questa volta il risultato PoC è un file eseguibile standalone scritto in C#, più facile da distribuire e utilizzare.
Host Machine
Ecco la linea di comando corrispondente. Come potete vedere, ci si aspetta che il valore di DriverStore sia fornito come argomento:
Se tutto è corretto, l’output sarà simile a questo:
Target Machine
Se la macchina di destinazione è vulnerabile, il Process Monitor rivelerà più o meno la stessa attività del file system come nei due casi precedenti:
Ecco un esempio di traffico di rete associato a questo tentativo di exploitation:
Le vulnerabilità richiedono una vigilanza costante e una rapida mitigazione
A causa della complessità dei sistemi moderni, è inevitabile che in futuro continueranno ad essere presenti exploit di vulnerabilità senza patch complete. Esortiamo i security team a prestare attenzione agli alert, alle notifiche dei fornitori e agli avvisi delle autorità per avere informazioni sempre aggiornate sulle vulnerabilità; ed anche a essere pronti con le persone, i processi e la tecnologia in modo da poter agire rapidamente per mitigare questi rischi.
Un blog dei Nozomi Networks Labs
