Introduzione
Le stampanti rappresentano un caso interessante nel mondo dell'Internet of Things (IoT), in quanto sono hardware molto potenti rispetto alla maggior parte dei dispositivi IoT, ma non sono tipicamente considerate come un "vero" computer dalla maggior parte degli amministratori. Nel corso degli anni, molti ricercatori di sicurezza hanno studiato e segnalato le vulnerabilità delle stampanti. Tuttavia, la maggior parte di queste ricerche si è concentrata su come violare la stampante stessa per fare cose come cambiare il display della stampante o rubare i documenti stampati. In questo caso, studiamo come utilizzare il ruolo speciale che le stampanti hanno all'interno della maggior parte delle reti per infettare effettivamente i dispositivi degli utenti finali ed estendere l'impronta del loro attacco all'interno della rete.
Sfondo
Per capire questo problema, è necessario conoscere un po' il Microsoft Web Point-and-Print Protocol (MS-WPRN) e perché funziona in questo modo.
La maggior parte delle organizzazioni cerca di applicare il principio del minimo privilegio ai dispositivi delle proprie reti. Questo principio funziona abbastanza bene per cose come i computer portatili o i desktop, dato che l'hardware utilizzato non cambia spesso. Tuttavia, le stampanti sono un po' diverse. Anche se hanno bisogno di driver, le stampanti devono supportare praticamente qualsiasi utente che voglia connettersi ad esse. Quando gli utenti finali si spostano all'interno di una struttura, vogliono naturalmente utilizzare la stampante più vicina a loro. Gli utenti mobili si aspettano di potersi collegare e utilizzare facilmente una stampante quando arrivano in ufficio. Inoltre, la maggior parte delle organizzazioni non si standardizza su un'unica stampante, e spesso ha più modelli e produttori all'interno di un'unica rete.
Quindi, invece di far sì che gli amministratori di sistema inviassero tutti i driver di stampa possibili a tutte le workstation della rete, la soluzione era quella di sviluppare un modo per fornire il driver a un dispositivo dell'utente proprio prima che la stampante venisse utilizzata. È qui che è nato Point-and-Print. Questo approccio memorizza un driver condiviso sulla stampante o sul server di stampa e solo gli utenti di quella stampante ricevono il driver di cui hanno bisogno. A prima vista, si tratta di una soluzione pratica e semplice per la distribuzione dei driver. L'utente ottiene l'accesso al driver di stampa di cui ha bisogno senza dover ricorrere all'amministratore: un vantaggio per tutti.
Il problema
Il problema è che per far sì che questo schema funzioni correttamente dal punto di vista dell'utente finale, era necessaria un'eccezione. Normalmente, i controlli dell'account utente sono presenti per avvertire o impedire all'utente di installare un nuovo driver. Per facilitare la stampa, è stata creata un'eccezione per evitare questo controllo. In definitiva, abbiamo un meccanismo che consente di scaricare gli eseguibili da un'unità condivisa e di eseguirli come sistema su una workstation senza generare alcun avviso da parte dell'utente. Dal punto di vista di un attaccante, questo è quasi troppo bello per essere vero, e naturalmente abbiamo dovuto provarlo.
Lo sfruttamento
Nel nostro caso stiamo utilizzando una stampante reale. Poiché la maggior parte delle stampanti è ricca di funzioni, non è stato troppo difficile trovare un bug che fornisse l'accesso al sistema sottostante. In questo caso, siamo riusciti a decomprimere un aggiornamento del firmware per raccogliere alcune credenziali e capire il layout del file system. Un file magico di binwalk è fornito nella sezione Strumenti alla fine di questa pagina e, dopo aver scavato un po', abbiamo trovato il file relativo ai driver. Devono trovarsi su un driver condiviso "print$" in smb, e in genere includono più versioni per vari tipi di architettura (ad esempio x86, x64, ppc, alpha). Cercare le directory denominate: W32X86, x64, IA64, color, ecc.
Abbiamo semplicemente tolto il file dll x86 dalla stampante, cosa che può essere fatta direttamente o tramite rpcclient[5], e lo abbiamo patchato con "the-backdoor-factory"[1].
Questo ci ha restituito un file dll con un payload iniettato al suo interno.
Il ripristino della dll nella directory originale può essere fatto in diversi modi. In genere è possibile riscrivere sulla condivisione print$ se si dispone di credenziali di amministratore del dominio. In alternativa, con l'accesso di root locale alla stampante, è possibile sovrascrivere il file esistente con quello retrodatato appena creato. È ancora sorprendente che i venditori lascino le credenziali nascoste di default sulla macchina. Se non è presente nel dizionario di cracking, è sempre bene aggiungere root:myroot per sicurezza.
Nel nostro esempio abbiamo utilizzato un mix di Windows XP 32 bit, Windows 7 32 bit, Windows 7 64 bit, Windows 2008 R2 AD 64, Ubuntu CUPS, Windows 2008 R2 64 print server e una stampante senza nome. Affinché Windows 7 funzioni correttamente con Point-and-Print, è stato necessario configurarlo sul lato Active Directory e inviarlo come criterio. Per saperne di più, consultare la sezione Protocollo di stampa Internet.
Dopo aver eseguito la normale procedura di aggiunta di una stampante con rilevamento automatico e aver selezionato la nostra stampante (con la dll retrodatata), il sistema Windows esegue il normale processo di acquisizione e installazione dei driver.
Questa fase consente l'installazione di un driver di stampa senza alcun avviso all'utente, uac o persino verifica della firma binaria, e tutto sotto i diritti del sistema.
In questo modo si ottiene quanto segue sul lato msfconsole:
Altri possibili vettori
Data la natura di questo problema, ci sono molti modi in cui l'esecuzione di codice remoto può essere utilizzata. Nell'esempio precedente, abbiamo effettuato il reverse engineering di una stampante desktop, ma la stessa funzione di caricamento del driver potrebbe essere ottenuta con uno stack software diverso e utilizzata in scenari diversi. Alcuni di questi includono, ma non sono limitati a:
- Attacchi di acquedotto
- Backdooring di una stampante o di un server di stampa esistente.
- Microsoft print server: percorso driver: c:\windows\system32\spool\drivers\*3\...
- Server Linux cups: verificare la presenza del driver di condivisione print$ nella configurazione.
- Diversi fornitori supportano il sistema Point-and-Printon della stampante stessa.
- Riflashare la stampante con i driver retrodatati.
- Creare un falso server di stampa e trasmettere con il rilevamento automatico.
- Escalation dei privilegi
- Utilizzare la stampante aggiuntiva come meccanismo di escalation dei privilegi per ottenere l'accesso al sistema.
- L'attacco di Mitm alla stampante e l'iniezione del driver retrodatato al posto di quello reale.
- Diventare più globali con IPP e Webpnp.
Infissione da remoto tramite protocollo di stampa Internet e PointNPrint web
Finora ci siamo limitati a una rete interna in cui un dispositivo veniva inserito o infettato e utilizzato per infettare ulteriormente i dispositivi che vi si collegavano. Il protocollo di stampa Internet (IPP) di Microsoft e il web pointNprint ci permettono di estendere questo problema al di fuori della rete intranet e a Internet. Microsoft IPP consente lo stesso meccanismo per caricare il driver dalla stampante. Questo può essere fatto con il seguente pezzo di codice del server di stampa MS.
Questo url contiene un file ".webpnp" o webpointNprint.
Vediamo il contenuto di quel bel file binario da 10 MB.
È qui che risiedono i file che verranno caricati. I file che abbiamo patchato dall'attacco precedente funzionavano altrettanto bene sia se consegnati tramite smb, Point-and-Print o webpnp.
La causa principale del problema
La ricerca del problema ci porta alla libreria ntprint.dll, in particolare alla funzione "PSetupDownloadAndInstallLegacyDriver". Si tratta in particolare della funzione responsabile della verifica dei criteri e dell'esecuzione dell'installazione con privilegi elevati.
Sebbene vi siano validi motivi di distribuzione per consentire l'installazione del driver senza diritti di amministratore, probabilmente si dovrebbe sempre attivare un avviso e controllare la firma binaria nel tentativo di ridurre la superficie di attacco.
Bonifiche
Vectra e Microsoft hanno collaborato durante l'indagine su questo problema e Microsoft ha fornito una correzione per CVE-2016-3238 (MS16-087) e CVE-2016-3239 come parte del bollettino di sicurezza MS16-087, disponibile qui.
Il comportamento di Point-and-Print può essere definito con GPO a un livello di granularità che dovrebbe consentire all'amministratore di controllare il rischio. Sebbene sia possibile disabilitare Point-and-Print o aggiungere un avviso e richiedere l'UAC, questo non fa altro che riportarci al primo problema: come gestire i driver in modo che l'utente possa installarli senza dover contattare ogni volta l'IT.
Microsoft fornisce la documentazione necessaria all'indirizzo [3],[4] e lo sviluppo di enhancedPoint-and-Print(v4) cerca di porre rimedio ad alcuni di questi problemi. La migrazione a una stampante che supporti la versione più recente del protocollo e la versione più recente di Windows potrebbe ridurre al minimo una parte della superficie di attacco. Al momento non abbiamo esaminato le caratteristiche di sicurezza di v4 / enhanced Point-and-Print oltre alle loro specifiche, tuttavia la compatibilità all'indietro potrebbe rendere vani questi sforzi.
Controllo delle reti
Registro host per l'abilitazione diPoint-and-Print
Scansione della rete per il driver Point n Print