Gli articoli che spiegano come aggirare TPM 2.0 e Secure Boot in Windows 11 si sono moltiplicati sul Web, e abbiamo persino strumenti che disabilitano entrambi i requisiti automaticamente durante la creazione di una chiavetta di installazione. Tuttavia, parte del lavoro di Microsoft è spiegare perché è necessario usare TPM 2.0 e Secure Boot in Windows 11. Il suo canale ufficiale Microsoft Mechanics ha pubblicato un video di 17 minuti all'inizio di ottobre in cui esplora entrambe le tecnologie in modo più approfondito, e che vale la pena vedere.

Perché è necessario usare TPM 2.0 e Secure Boot in Windows 11?
TPM 2.0 e Secure Boot

L'altra faccia della medaglia

La decisione di Microsoft è controversa, nessuno lo mette in dubbio. Dalla divisione immediata della sua base di utenti alla raccomandazione di acquistare nuovi computer in piena crisi dei semiconduttori, Windows 11 ha dimostrato che i problemi di tatto e comunicazione a Redmond sono ancora presenti. Ma ora che il nuovo sistema operativo è già tra noi, Microsoft cerca di trasmettere ai suoi utenti le principali ragioni per cui è necessario usare TPM 2.0 e Secure Boot in Windows 11... o meglio, «raccomandato».

Questo ci porta a un video pubblicato su Microsoft Mechanics, uno dei canali ufficiali dell'azienda su YouTube. Il canale di solito genera contenuti pensati per i professionisti IT, tuttavia questo video di 17 minuti fa un lavoro decente nel descrivere i vantaggi diretti di queste tecnologie di sicurezza a un pubblico più ampio, e include alcuni attacchi come dimostrazione.

TPM 2.0 e Secure Boot in Windows 11, spiegati da Microsoft

  • Il primo attacco sfrutta l'esposizione di RDP alla rete. Prima individua il bersaglio con Shodan, poi passa a Kali Linux, e infine utilizza Hydra per eseguire un attacco di forza bruta usando un database con password basilari. La simulazione richiede pochi secondi, ma sappiamo bene che un attacco di forza bruta può durare giorni, ed è molto poco pratico eseguirlo alla cieca. Con accesso completo, l'attaccante inietta il suo payload.
  • Il secondo attacco viene eseguito direttamente su un dispositivo senza sicurezza basata sulla virtualizzazione (VBS). Con l'aiuto di un accessorio che utilizza PCILeech, l'attaccante riesce a modificare/sostituire il codice di autenticazione biometrica per le impronte digitali con una patch, in modo da poter entrare usando qualcosa di semplice come una gomma. VBS annulla questa possibilità isolando elementi fondamentali (chiavi, firme, ecc.) dalla sessione standard, entrambi separati dall'hardware. Abilitando la funzione, l'attacco viene neutralizzato.
  • La fase successiva spiega il ruolo di TPM 2.0, che consiste nel proteggere chiavi di crittografia, credenziali utente e altri dati delicati con una barriera hardware. A questo punto dobbiamo ricordare che molti computer hanno già il supporto per TPM 2.0 (il video stesso parla di «computer negli ultimi cinque anni»), ma è disattivato nel UEFI. Molti utenti possono installare Windows 11 senza problemi semplicemente attivandolo.
  • La combinazione di UEFI, Secure Boot e Trusted Boot blocca attacchi come quello osservato nel primo esempio, o minimizza il danno se il computer è già compromesso. Nel video ci insegnano ad attivare Secure Boot, che a sua volta richiede di disattivare la modalità Legacy o CSM. Le modifiche alla sequenza di avvio vengono respinte e il computer torna a un login convenzionale di Windows 11.

Piccoli dettagli

Perché è necessario usare TPM 2.0 e Secure Boot in Windows 11?
Uno dei nostri ambienti virtualizzati di Windows 11, mentre riceve aggiornamenti

Uno degli aspetti più interessanti appare alla fine del video, in cui essenzialmente ammettono che l'aumento delle misure di sicurezza può avere un impatto sulle prestazioni del computer, ed è qui che entrano in gioco i nuovi chip di Intel e AMD. Inoltre, tutti i requisiti di sicurezza in Windows 11 sono opzionali in Windows 10 e possono essere abilitati dall'utente quando lo desidera.

Per quanto riguarda gli attacchi, vorrei aggiungere quanto segue: da un lato, molti dei risultati presentati da Shodan rivelano che RDP è esposto su computer con Windows 8.1 o versioni precedenti, quindi il problema non è uno sviluppo recente. Dall'altro, se un attaccante ottiene l'accesso fisico al dispositivo, non è assurdo dichiararlo compromesso fin dall'inizio. In sintesi, ricevere ulteriori informazioni non fa mai male, e l'idea è che l'utente abbia maggiore potere decisionale, che preferisca cercare un nuovo computer o estendere il ciclo di vita su hardware perfettamente funzionante.

Fonte: Microsoft Mechanics su YouTube.