Microsoft ha pubblicato un bollettino di sicurezza relativo a una funzionalità in grado di sfruttare un’importante vulnerabilità che affligge i tablet Surface Pro 3 (ma che nel modulo TPM abbiano abilitati SHA1 e SHA256 PCRs) e che consentirebbe ad un attacker d’introdurre dispositivi dannosi all’interno di reti aziendali.
La problematica segnalata nel CVE-2021-42299 può essere sfruttata in scenari d’attacco ad alta complessità soprannominati (dai ricercatori cyber security di Google) TPM Carte Blanche.
Per abusare pienamente del bug, tuttavia, un attacker ha necessità di compromettere le credenziali dell’utente o di accedere fisicamente al dispositivo (in questo caso, con “fisicamente” non si intende necessariamente qualcuno che stazioni per delle ore nei pressi del device che desidera compromettere: l’attacker, ad esempio, potrebbe sfruttare una chiavetta USB Linux configurata ad arte per ridurre al minimo le interazioni richieste col suo target ed evidentemente un accesso non presidiato al datacenter).
Indice degli argomenti
Vulnerabilità nei Surface Pro 3: i dettagli
Device Health Attestation è una funzionalità di Windows che si avvale di un modulo TPM (Trusted Platform Module) per certificare l’integrità dello stato di avvio di un PC. Sfrutta le misurazioni effettuate durante l’avvio dal modulo TPM, vagliando le misurazioni con una “chiave di attestazione”.
Le fasi di avvio effettuano delle misurazioni estendendo i registri di configurazione della piattaforma del modulo TPM (ci si riferisce a tali registri con la sigla PCRs, acronimo derivante appunto da Platform Configuration Registers), che ospitano valori residenti nella memoria TPM, e che possono essere modificati solo estendendo la seguente funzione hash:
Queste misurazioni vengono archiviate nel file di log TCG, un registro dettagliato di tutte le misurazioni effettuate durante una sequenza di avvio. Il log potrebbe contenere misurazioni come “UEFI Secure Boot è attivo e configurato con chiavi xyz” o “BIOS ha misurato il caricatore del sistema operativo Windows”, insieme alle corrispondenti estensioni PCR.
Un log TCG può essere convalidato confrontando il digest di tutte le misurazioni estese che descrive, con una “quotazione” PCR in tempo reale, firmata da una chiave di attestazione (AK, o Attestation Key) in un TPM. AK rappresenta una chiave di firma limitata che è garantita dal produttore del TPM per non essere utilizzabile per firmare false quotazioni PCR.
Una chiave di attestazione è a sua volta garantita dalla chiave di approvazione (EK, o Endorsement Key) che può essere utilizzata per decrittare le richieste di attestazione da un servizio di emissione di certificati AK (come quello gestito da Microsoft).
Per ragioni storiche, gli AK sono chiamati AIK (Attestation Identity Keys) nei servizi Microsoft. I TPM supportano blocchi PCR per più algoritmi di hash, così come l’utilizzo contemporaneo di più algoritmi. Ciò significa che entrambi i blocchi PCR SHA1 e SHA256 possono essere abilitati contemporaneamente.
Panoramica della registrazione del certificato da parte del servizio Device Health Attestation (fonte: Google Security).
Panoramica della convalida dal servizio Device Health Attestation (fonte: Google Security).
Su di un tablet Surface Pro 3 che esegue il firmware della piattaforma con SHA1 e SHA256 PCR abilitati (versione BIOS 3.11.2550), se il dispositivo viene avviato in una distribuzione Ubuntu 20.04 LTS, non ci sono misurazioni nei PCR bassi del blocco SHA256 (PCR da 0 a 7, destinati a ricevere misurazioni del firmware della piattaforma, in base alle specifiche della piattaforma EFI TCG) e ciò consente di effettuare misurazioni arbitrarie e false (nell’userland Linux, ad esempio) corrispondenti ad un qualsiasi log di avvio di Windows. Un autentico SHA256 PCR su misurazioni falsificate può essere richiesto utilizzando un AK legittimo nel TPM allegato.
Su GitHub sono disponibili una serie di script in linguaggio Go in grado di contraffare arbitrariamente le misurazioni di un log TCG, citare le misurazioni e recuperare un certificato d’integrità.
Contraffazione delle misurazioni.
Come è possibile verificare sul sito ufficiale, Microsoft non ha ancora rilasciato patch per questo CVE. Altresì, è interessante notare come Microsoft ipotizzi la possibilità che anche altri dispositivi che utilizzano un BIOS simile possano essere vulnerabili.
Riflessioni e raccomandazioni in attesa della patch
Sebbene lo sfruttamento di questa vulnerabilità richieda sostanzialmente una presenza nelle vicinanze del device (o al più, come già accennato, ipotizzando la possibilità che l’attacker sferri più o meno silenziosamente un attacco Evil Maid sfruttando una memoria flash USB, magari dalla lunghezza contenuta, nella speranza che passi inosservata), è comunque importante fare almeno due riflessioni:
- se l’ipotesi di Microsoft fosse vera, ossia se tale vulnerabilità inficiasse anche altri device (anche non Microsoft), potrebbe essere il momento di intensificare o di rivedere (o di impostarle per la prima vota, se fino ad oggi non le si è ancora disgraziatamente messe in campo) quelle policy software che in azienda monitorano e regolamentano l’utilizzo in produzione di chiavette USB non “certificate” (esistono software e sistemi per consentire – in un dominio e non – l’utilizzo esclusivo di chiavette USB effettivamente aziendali, con a bordo certificati digitali riconosciuti dalla medesima Certification Authority utilizzata internamente in azienda), policy che potrebbero anche delegare ad eventuali agent software centralizzati, il compito di comunicare ad un SIEM l’orario e l’account stesso utilizzato in quel momento da chi collega una chiavetta USB al tal device, peraltro tracciando esattamente a quale porta USB (tematica dell’autorizzare l’accesso ad una certa porta USB solo a chiavette USB autenticate, il cui utilizzo è stato pensato per un selezionato set di utenti);
- in azienda il software che si utilizza per fare Asset Management è aggiornato? È veramente operativo? È popolato correttamente? Ad esempio, siamo già al corrente di un nostro eventuale dipendente o collaboratore che collega più o meno abitualmente un tablet Surface Pro 3 alla LAN/WLAN aziendale? E quando lo fa anche un nuovo device, in che modo si alimenta il sistema di Asset Management? Comunica anche i dati aggiornati a un SIEM oppure il processo di migrazione dei dati avviene (quando avviene) dopo mesi, magari manualmente? Il popolamento del database utilizzato dal sistema di Asset Management è automatizzato? Se il suo database viene alterato in maniera fraudolenta, il sistema stesso se ne accorge perché ha dei meccanismi intrinseci antifrode? Il database dell’Asset Management tiene traccia anche delle versioni esatte dei firmware montati su server, workstation, tablet ed eventuali dispositivi IoT utilizzati in produzione?
Domande che ci ricordano quanto un sistema di Asset Management trascurato serva a poco o nulla nel mondo reale dell’Incident Response e, più in generale, nella cyber security.
