Introduzione
Le stampanti rappresentano un caso interessante nel mondo dell'Internet delle cose (IoT), poiché sono dispositivi hardware molto potenti rispetto alla maggior parte dei dispositivi IoT, ma non sono generalmente considerate come dei "veri" computer dalla maggior parte degli amministratori. Nel corso degli anni, molti ricercatori nel campo della sicurezza hanno studiato e segnalato le vulnerabilità delle stampanti. Tuttavia, la stragrande maggioranza di queste ricerche si è concentrata su come hackerare la stampante stessa per eseguire operazioni quali modificare il display della stampante o rubare i documenti stampati. In questo caso, analizziamo 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.
Contesto
Per comprendere questo problema, è necessario conoscere alcuni aspetti del protocollo Microsoft Web Point-and-Print (MS-WPRN) e il motivo per cui funziona in questo modo.
La maggior parte delle organizzazioni cerca di applicare il principio del privilegio minimo ai dispositivi presenti nelle proprie reti. Questo funziona piuttosto bene per dispositivi come laptop o desktop, poiché l'hardware che utilizzano non cambia molto spesso. Tuttavia, le stampanti sono leggermente diverse. Sebbene necessitino comunque di driver, le stampanti devono supportare praticamente qualsiasi utente che desideri connettersi ad esse. Man mano che gli utenti finali si spostano all'interno di un edificio, è naturale che desiderino utilizzare la stampante più vicina a loro. Gli utenti mobili si aspettano di potersi connettere facilmente e utilizzare una stampante quando arrivano in ufficio. Inoltre, la maggior parte delle organizzazioni non standardizza su una singola stampante e spesso dispone di più modelli e produttori all'interno di una singola rete.
Quindi, invece di chiedere agli amministratori di sistema di inviare tutti i driver di stampa possibili a tutte le workstation della rete, la soluzione è stata quella di sviluppare un modo per fornire il driver al dispositivo dell'utente proprio prima dell'utilizzo della stampante. Ed è qui che è entrato in gioco Point-and-Print. Questo approccio prevede la memorizzazione di 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, questa è una soluzione pratica e semplice per la distribuzione dei driver. L'utente ha accesso al driver della stampante di cui ha bisogno senza bisogno di un amministratore: una soluzione vantaggiosa per tutti.
Il problema
Il problema è che, affinché questo schema funzionasse correttamente dal punto di vista dell'utente finale, era necessaria un'eccezione. Normalmente, i controlli dell'account utente servono ad avvisare o impedire a un utente di installare un nuovo driver. Per facilitare la stampa, è stata creata un'eccezione per evitare questo controllo. Quindi, alla fine, abbiamo un meccanismo che consente di scaricare eseguibili da un'unità condivisa ed eseguirli come sistema su una workstation senza generare alcun avviso sul lato utente. Dal punto di vista di un aggressore, questo è quasi troppo bello per essere vero e, naturalmente, abbiamo dovuto provarlo.
Lo sfruttamento
Nel nostro caso stiamo usando una stampante reale. Poiché la maggior parte delle stampanti è dotata di numerose funzionalità, non è stato troppo difficile trovare un bug che consentisse l'accesso al sistema sottostante. In questo caso, siamo riusciti a decomprimere un aggiornamento del firmware per raccogliere alcune credenziali e comprendere la struttura del file system. Un file binwalk magic è disponibile nella sezione Strumenti alla fine di questa pagina e, dopo alcune ricerche, abbiamo trovato il file relativo a quei driver. Devono trovarsi su un driver condiviso "print$" in smb e in genere includono diverse varianti per vari tipi di architettura (ad esempio x86, x64, ppc, alpha). Cercate le directory denominate: W32X86, x64, IA64, color, ecc.
Abbiamo semplicemente estratto il file dll x86 dalla stampante, operazione che può essere eseguita direttamente o tramite rpcclient[5], e l'abbiamo modificato 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 effettuato in diversi modi. In genere è possibile riscriverla nella condivisione print$ se si dispone delle credenziali di amministratore di dominio. In alternativa, con l'accesso root locale alla stampante è possibile sovrascrivere il file esistente con quello backdoor appena creato. È ancora sorprendente che i fornitori lascino le credenziali nascoste predefinite sulla macchina. Se non è presente nel dizionario di cracking, è sempre bene aggiungere root:myroot per ogni evenienza.
Nel nostro esempio abbiamo utilizzato una combinazione di Windows XP 32 bit, Windows 7 32 bit, Windows 7 64 bit, Windows 2008 R2 AD 64, Ubuntu CUPS, server di stampa Windows 2008 R2 64 e una stampante senza nome. Affinché Windows 7 funzionasse correttamente con Point-and-Print, era necessario configurarlo sul lato Active Directory e applicarlo come politica. Maggiori informazioni al riguardo sono disponibili nella sezione Protocollo di stampa Internet riportata di seguito.
Dopo aver eseguito la normale procedura di aggiunta della stampante con rilevamento automatico e aver selezionato la nostra stampante (con la dll backdoor), il sistema Windows esegue il normale processo di acquisizione e installazione del driver.
Questa fase consente l'installazione di un driver di stampa senza alcun avviso all'utente, UAC o verifica della firma binaria, il tutto con i diritti di sistema.
Questo ci ha fornito quanto segue sul lato msfconsole:
Altri possibili vettori
Data la natura del problema, esistono molti modi in cui è possibile utilizzare l'esecuzione di codice remoto. Nell'esempio sopra riportato, 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 watering hole
- Backdoor su una stampante o un server di stampa esistente.
- Server di stampa Microsoft: percorso driver: c:\windows\system32\spool\drivers\*\3\...
- Server Linux cups: verificare la presenza del driver di condivisione print$ nella configurazione.
- Diversi fornitori supportano Point-and-Print sulla stampante stessa.
- Riappaltare la stampante con driver backdoor.
- Creare un server di stampa falso e trasmettere con rilevamento automatico.
- Elevazione dei privilegi
- Utilizza l'aggiunta di una stampante come meccanismo di escalation privilegiato per ottenere l'accesso al sistema.
- Attacco Mitm alla stampante e inserimento del driver backdoor al posto di quello reale.
- Verso una maggiore globalizzazione con IPP e Webpnp.
Infezione remota tramite protocollo di stampa Internet e web PointNPrint
Finora ci siamo limitati a una rete interna in cui un dispositivo veniva inserito o infettato e utilizzato per infettare ulteriormente i dispositivi che si collegavano ad esso. Il protocollo di stampa Internet (IPP) di Microsoft e web pointNprint ci consentono di estendere questo problema al di fuori della intranet, fino a Internet. Microsoft IPP consente lo stesso meccanismo per caricare il driver dalla stampante. Ciò può essere fatto con il seguente codice dal server di stampa MS.
Questo URL contiene un file ".webpnp" o webpointNprint.
Vediamo il contenuto di quel bel file binario da 10 MB.
Qui è dove risiedono i file che verranno caricati. I file che abbiamo modificato dall'attacco precedente funzionavano altrettanto bene sia se inviati tramite smb, Point-and-Print o sotto webpnp.
Causa principale del problema
Tracciando il problema si arriva alla libreria ntprint.dll, in particolare alla funzione "PSetupDownloadAndInstallLegacyDriver". Nello specifico, questa è la funzione responsabile della verifica della politica e dell'esecuzione dell'installazione con privilegi elevati.
Sebbene esistano validi motivi di implementazione per consentire l'installazione dei driver senza diritti di amministratore, è consigliabile abilitare sempre un avviso e verificare sempre la firma binaria, al fine di ridurre la superficie di attacco.
Rimedi
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 sulla sicurezza MS16-087, disponibile qui.
Il comportamento di Point-and-Print può essere definito con GPO a un livello di granularità tale da consentire all'amministratore di controllare il rischio. Sebbene sia possibile disabilitare Point-and-Print o aggiungere un avviso e richiedere UAC, questo ci riporta al primo problema di come gestire i driver in modo che l'utente possa installarli senza dover contattare ogni volta il reparto IT.
Microsoft fornisce la documentazione necessaria ai punti [3] e [4], mentre lo sviluppo di enhancedPoint-and-Print (v4) cerca di risolvere alcuni di questi problemi. La migrazione a una stampante che supporti la versione più recente del protocollo e una 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 le loro specifiche, tuttavia la retrocompatibilità potrebbe rendere vani tali sforzi.
Controllo delle reti
Registro host per abilitare Point-and-Print
Ricerca del driver Point n Print nella rete