Da un pc rubato all’interno di una rete aziendale

Cosa si riesce a fare con un laptop rubato? Si riesce ad accedere ad una rete aziendale interna?

Spoiler: sì, si può.

In questo articolo, gli esperti di Dolos Group ci raccontano come sia possibile con un laptop aziendale “rubato” e sfruttato diversi exploit concatenati per entrare nella rete aziendale del cliente, grazie ai ricercatori di F-Secure e Pulse Security.

“Abbiamo ricevuto un laptop Lenovo preconfigurato con lo stack di sicurezza standard per questa organizzazione. Non abbiamo ricevuto alcuna informazione su questo laptop, nessuna credenziale di prova, nessun dettaglio di configurazione, niente di niente, era un test blackbox al 100%. Una volta che il laptop è arrivato, abbiamo aperto la scatola di spedizione e ci siamo messi al lavoro. Dopo aver effettuato la nostra ricognizione del laptop (impostazioni del BIOS, normale operazione di avvio, dettagli hardware, ecc.) Abbiamo notato che venivano seguite molte best practice, annullando molti attacchi comuni. Per esempio:

· Gli attacchi pcileech /DMA sono stati bloccati perché l’impostazione del BIOS VT-d di Intel era abilitata

· Tutte le impostazioni del BIOS sono state bloccate con una password

· L’ordine di avvio del BIOS è stato bloccato per impedire l’avvio da USB o CD

· Secureboot è stato completamente abilitato e ha impedito qualsiasi sistema operativo non firmato

·  Il bypass di autenticazione Kon-boot non ha funzionato a causa della crittografia completa del disco

· La LAN turtle e altri attacchi Responder tramite adattatori ethernet USB non hanno restituito nulla di utilizzabile

· L’SSD è stato crittografato a disco completo (FDE) utilizzando BitLocker di Microsoft, protetto tramite Trusted Platform Module (TPM)

Senza che nient’altro funzionasse, quell’ultimo punto, BitLocker protetto da TPM, sarebbe stato il nostro modo di entrare. Una delle cose che abbiamo visto durante la ricognizione era che il laptop si avviava direttamente alla schermata di accesso di Windows 10. Questo, insieme alla crittografia BitLocker, significa che la chiave di decrittografia dell’unità viene estratta solo dal TPM, non era necessario alcun PIN o password forniti dall’utente, che è l’impostazione predefinita per BitLocker.

Un utente malintenzionato pre-attrezzato può eseguire l’intera catena di attacchi in meno di 30 minuti senza saldature, hardware semplice e relativamente economico e strumenti disponibili pubblicamente. Un processo che lo colloca esattamente nel territorio di Evil-Maid.

Per coloro che non lo sanno, il TPM è un componente hardware altamente sicuro e sofisticato che dispone di numerosi rilevamenti di manomissioni e protezioni. È molto improbabile che attaccare direttamente il TPM dia i suoi frutti entro il periodo di tempo del test. Di conseguenza, dobbiamo esaminare le relazioni di fiducia intorno al TPM e su cosa si basa. È un chip distinto e separato dagli altri componenti della scheda madre e può essere suscettibile a una varietà di attacchi. Il nostro particolare TPM in questione è mostrato qui:

La ricerca di quel chip TPM specifico ha rivelato che comunica con la CPU utilizzando il protocollo Serial Peripheral Interface (SPI):

Il che è stato ulteriormente supportato quando abbiamo trovato il TPM menzionato negli schemi del laptop:

SPI è un protocollo di comunicazione per sistemi embedded ed è estremamente comune praticamente tra tutti gli hardware. A causa della sua semplicità, non esiste un’opzione di crittografia per SPI. Qualsiasi crittografia deve essere gestita dai dispositivi stessi. Nel momento in cui scriviamo, BitLocker non utilizza alcuna funzionalità di comunicazione crittografata dello standard TPM 2.0, il che significa che tutti i dati in uscita dal TPM vengono emessi in chiaro, inclusa la chiave di decrittografia per Windows. Se riusciamo a prendere quella chiave, dovremmo essere in grado di decrittografare l’unità, ottenere l’accesso alla configurazione del client VPN e forse ottenere l’accesso alla rete interna.

Girare intorno al TPM in questo modo è come ignorare Fort Knox e concentrarsi sull’auto non blindata che ne esce.

Per sniffare i dati che si spostano sul bus SPI, dobbiamo collegare i cavi o le sonde ai pin (etichettati sopra come MOSI, MISO, CS e CLK) sul TPM. Normalmente è semplice, ma in questo caso c’è un problema pratico. Questo TPM è su un footprint VQFN32 , che è molto piccolo. I “perni” sono in realtà larghi solo 0,25 mm e distanziati di 0,5 mm l’uno dall’altro. E quei “pin” non sono in realtà pin, sono piatti contro la parete del chip, quindi è fisicamente impossibile attaccare qualsiasi tipo di clip. Potresti saldare “cavi volanti” ai pad di saldatura, ma è una seccatura e tende a essere una connessione molto instabile dal punto di vista fisico. In alternativa, una tattica comune è quella di individuare resistori in serie a cui saldare, ma erano altrettanto piccoli e persino più fragili. Non sarebbe stato facile.

Ma prima di iniziare, pensavamo che potesse esserci un altro modo. Molte volte i chip SPI condividono lo stesso “bus” con altri chip SPI. È una tecnica utilizzata dai progettisti di hardware per semplificare le connessioni, risparmiare sui costi e semplificare la risoluzione dei problemi/programmazione. Abbiamo iniziato a cercare su tutta la scheda qualsiasi altro chip che potesse trovarsi sullo stesso bus del TPM. Forse i loro spilli sarebbero più grandi e più facili da usare. Dopo alcuni sondaggi e consultazioni sugli schemi, si è scoperto che il TPM condivideva un bus SPI con un altro singolo chip, il chip CMOS, che aveva sicuramente pin più grandi. In effetti, il chip CMOS aveva quasi le dimensioni dei pin più grandi che puoi trovare sulle schede madri standard, era un SOP-8 (noto anche come SOIC-8).

Questo era l’ideale. Abbiamo proceduto ad collegare il nostro analizzatore logico Saleae ai pin secondo il datasheet del CMOS :

Un attaccante pre-equipaggiato, come abbiamo detto all’inizio, utilizzerebbe invece una clip SOIC-8 invece di singole sonde. La clip renderebbe il cervello morto semplice da collegare al chip e ridurrebbe un paio di minuti da un attacco nel mondo reale.

Una volta collegate le sonde, abbiamo avviato il laptop e registrato ogni byte SPI che si spostava sulle tracce. Da qualche parte nei milioni di dati era stata inviata una chiave di decrittazione BitLocker, il problema ora era trovarla. Abbiamo usato il bitlocker-spi-toolkit di Henri Nurmi per provare a estrarre la chiave automaticamente, ma non funzionava sulla nostra acquisizione. Di seguito è riportato uno screenshot del suo High Level Analyzer (HLA) in azione, puoi vedere che alcune transazioni vengono analizzate correttamente e altre no. C’era qualcosa di diverso nella nostra cattura che l’HLA non poteva spiegare.

Dopo giorni di risoluzione dei problemi, confronto di acquisizioni e tirando i capelli, abbiamo finalmente capito che si trattava di una combinazione di diverse maschere di bit per i pacchetti di comandi TPM e di un’espressione regolare diversa per trovare la chiave. Abbiamo effettuato una pull request per la correzione così il bitlocker-spi-toolkit ha potuto analizzare anche questi tipi di richieste. Una volta che l’abbiamo avuto, ecco, la chiave è saltata fuori.

Perfetto, ora che abbiamo la chiave di decrittazione, decifriamo l’SSD e vediamo cosa abbiamo. Abbiamo estratto l’SSD, l’abbiamo montato in un adattatore e l’abbiamo collegato:

Abbiamo creato un’immagine del disco dell’unità su cui abbiamo operato andando avanti. È interessante notare che nell’intero processo della catena di attacco la parte che richiede più tempo è semplicemente la copia dei 256 GB di file. Una volta che abbiamo avuto l’immagine localmente, potremmo usare il set di strumenti Dislocker per decrittografare l’unità:

Ora che abbiamo accesso offline ai contenuti in chiaro, abbiamo iniziato il nostro processo standard per il saccheggio dei dati. Estrazione di hash di password, testo in chiaro o credenziali codificate, file sensibili esposti, ecc. Sfortunatamente, non è stato trovato nulla di utile e non abbiamo ottenuto alcuna credenziale offline di alcun tipo, il che non dovrebbe sorprendere poiché questo non era il laptop di un vero dipendente con anni di file, era un laptop costruito appositamente per questo test specifico. Tuttavia, abbiamo trovato il client VPN in uso: Global Protect (GP) di Palo Alto . GP ha una “caratteristica” interessante chiamata tunnel di pre-accesso :

Il pre-accesso è un metodo di connessione che stabilisce un tunnel VPN prima che un utente acceda. Lo scopo del pre-accesso è autenticare l’endpoint (non l’utente) e consentire l’esecuzione di script di dominio o altre attività non appena l’endpoint si accende .

Sembra una funzionalità davvero interessante per un reparto IT per gestire i propri endpoint. Sembra anche un ottimo modo per accedere alla VPN senza conoscere le credenziali di nessuno. In teoria, se potessimo avviare una versione backdoor del laptop, ad esempio utilizzando le chiavi adesive backdoor , dovremmo essere in grado di accedere al tunnel VPN senza mai aver bisogno di credenziali. In pratica ci sono molti modi per farlo, ma abbiamo deciso di seguire la strada della virtualizzazione nell’interesse della velocità.

Poiché abbiamo accesso in scrittura all’intero file system, avremmo potuto fare qualsiasi cosa, inclusa la riscrittura dei file dei driver per il malware a livello di kernel, il proxy delle DLL privilegiate e la semplice aggiunta di account. Nell’interesse del tempo e dell’efficienza, i tasti permanenti sono perfetti per questo scenario, il cui processo è semplicemente:

1. Copia C:\Windows\System32\Utilman.exe in Utilman.exe.bak

2. Copia C:\Windows\System32\cmd.exe in Utilman.exe

3. Premi Windows + U nella schermata di accesso

Ora che abbiamo accesso alla backdoor, dobbiamo solo avviare l’unità. Per avviare l’immagine Windows decrittografata come macchina virtuale, abbiamo prima dovuto creare un file VMDK personalizzato. Questo file deve impostare i parametri e mappare i settori iniziali della partizione BitLocker decrittografata e dell’immagine crittografata alle partizioni VM appropriate. Il VMDK risultante era:

Ora, con quel VMDK e l’immagine Windows backdoor dei tasti permanenti, abbiamo creato la macchina virtuale, l’abbiamo avviata e abbiamo premuto WIndows + U nella schermata di accesso.

Stato GlobalProtect: connesso

Era esattamente quello che volevamo. Affinché ciò funzioni, l’autenticazione alla VPN avviene tramite un certificato allegato all’account del computer. Poiché ogni account computer dispone di privilegi di base in Active Directory, possiamo eseguire comandi SMB di base all’interno del dominio. Abbiamo interrogato il controller di dominio per vari tipi di informazioni sul dominio come utenti, gruppi, sistemi, ecc. Potremmo anche elencare e visualizzare il contenuto dei file sulle condivisioni SMB interne:

Possiamo anche utilizzare l’accesso di questo account computer come piattaforma per lanciare attacchi interni ed escalation laterale. Per dimostrare che avevamo accesso in scrittura a un server che non avremmo dovuto avere, abbiamo scelto il file server interno dall’alto. La prova del concetto era scrivere un file su quel server e rileggerlo per dimostrare l’accesso in lettura/scrittura.

Questa condivisione “Scanner” è un’ottima scelta per un utente malintenzionato come abbeveratoio per varie tecniche, ad esempio attacchi LNK, PDF trojan, ecc. A questo punto abbiamo ottenuto l’accesso alla rete interna, i privilegi di base su Active Directory e l’accesso a condivisioni di file interne, più che sufficienti per iniziare a compromettere i dati aziendali sensibili.

Per ricapitolare, abbiamo preso un laptop FDE bloccato, sniffato la chiave di decrittazione di BitLocker proveniente dal TPM, eseguito il backdoor di un’immagine virtualizzata e utilizzato la sua funzione di connessione automatica VPN per attaccare la rete aziendale interna. Questo è un modo per passare da un pc rubato ad una compromissione interna”.