La domanda “esiste un modo per verificare la sicurezza di una chiavetta USB prima di usarla?” sembra semplice, ma in realtà tocca uno dei nodi più spinosi della sicurezza operativa. Il problema non è teorico: flussi di lavoro consolidati, clienti poco alfabetizzati digitalmente e risorse IT limitate rendono impraticabili molte delle soluzioni “ideali” spesso suggerite online.
Il primo punto da chiarire, senza ambiguità, è questo: non esiste un dispositivo magico che, collegata una chiavetta, garantisca con certezza assoluta che essa sia “solo storage” e non presenti comportamenti pericolosi. Il rischio, infatti, non risiede soltanto nei file contenuti, ma anche nel firmware e nel comportamento del dispositivo USB stesso. La famiglia di attacchi nota come BadUSB dimostra che una chiavetta può presentarsi come tastiera, mouse, scheda di rete o dispositivo ibrido, ed eseguire azioni automatiche prima ancora che un file venga aperto o copiato.
Spesso si parla di antivirus, sandbox, scansioni dei file, quando in realtà una chiavetta USB sconosciuta può essere pericolosa anche senza contenere alcun malware tradizionale.
Perché “scansionare la chiavetta” non basta
La scansione antivirus resta utile, ma non è una panacea. Gli attacchi che sfruttano l’emulazione via USB di periferiche di input non richiedono firme, exploit o vulnerabilità software: sfruttano il normale funzionamento del protocollo USB e la fiducia implicita che i sistemi operativi accordano a tastiere e mouse. Se un dispositivo riesce a farsi riconoscere come periferica di input, può iniettare comandi senza alcuna interazione da parte dell’utente.
Qualche tempo fa abbiamo presentato l’esempio del cavo USB O.MG che può diventare un keylogger e molto altro non appena collegato a un qualunque dispositivo.
Gli strumenti di endpoint security – Defender, SentinelOne, CrowdStrike, GFI LanGuard EDR e simili –, oltre alle soluzioni di profilo più consumer, funzionano correttamente solo se il dispositivo USB non ha già ottenuto un canale di esecuzione privilegiato spacciandosi per quello che non è.
La difesa efficace: bloccare ciò che un dispositivo USB non deve mai essere
La contromisura efficace contro BadUSB consiste nell’impedire a monte che una chiavetta possa autoconfigurarsi come periferica di input o di rete. In ambiente Windows questo è possibile in modo nativo, tramite le Device Installation Restrictions: il sistema può essere configurato per rifiutare l’installazione di nuove tastiere, mouse e dispositivi HID, lasciando funzionanti solo quelli già presenti.
Il risultato pratico è semplice ma potente: una USB che tenta di presentarsi come tastiera non viene installata, non può digitare nulla e l’attacco fallisce prima ancora di iniziare. Le normali chiavette di archiviazione dati, presentandosi come dispositivi di storage, continuano invece a funzionare, mantenendo intatto il flusso operativo.
Windows: come bloccare i dispositivi USB non usati per l’archiviazione dati
In Windows è possibile bloccare in modo preventivo tutti i futuri dispositivi USB che tentano di configurarsi come periferiche di input.
Le aziende che utilizzano un’infrastruttura basata su Active Directory, possono configurare una policy GPO efficace facendo riferimento al percorso Configurazione computer, Modelli amministrativi, Sistema, Installazione dispositivi, Restrizioni per l’installazione di dispositivi.
Con un doppio clic su Impedisci l’installazione di dispositivi utilizzando driver che corrispondono a queste classi di installazione dispositivi, si possono bloccare i seguenti ID:
{745A17A0-74D3-11D0-B6FE-00A0C90F57DA}HID (Human Interface Device){4D36E96B-E325-11CE-BFC1-08002BE10318}Tastiere{4D36E96F-E325-11CE-BFC1-08002BE10318}Mouse
Su singoli PC, si può procedere anche con la modifica diretta del registro di sistema, aprendo il prompt dei comandi con i diritti di amministratore (cmd, Esegui come amministratore):
:: Abilita il blocco per classi di dispositivi
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceInstall\Restrictions" /v PreventDeviceClasses /t REG_DWORD /d 1 /f
:: Impedisce che gli amministratori possano superare il blocco
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceInstall\Restrictions" /v AllowAdminInstall /t REG_DWORD /d 0 /f
:: Blocca nuove periferiche HID (incl. Rubber Ducky e simili)
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceInstall\Restrictions\DenyDeviceClasses" /v 1 /t REG_SZ /d "{745A17A0-74D3-11D0-B6FE-00A0C90F57DA}" /f
:: Blocca nuove tastiere
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceInstall\Restrictions\DenyDeviceClasses" /v 2 /t REG_SZ /d "{4D36E96B-E325-11CE-BFC1-08002BE10318}" /f
:: Blocca nuovi mouse
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceInstall\Restrictions\DenyDeviceClasses" /v 3 /t REG_SZ /d "{4D36E96F-E325-11CE-BFC1-08002BE10318}" /f
Breve spiegazione e note pratiche
Per rendere attive le modifiche presentate al paragrafo precedente, è necessario riavviare il PC. A questo punto si può provare a collegare una tastiera USB mai usata sul sistema: non dovrebbe essere configurata e non dovrebbe essere possibile utilizzarla.
Un amministratore locale può sempre modificare il registro di sistema e rimuovere o cambiare i valori descritti in precedenza: non c’è alcun modo per impedirlo.
Ciò che fa l’intervento su AllowAdminInstall è bloccare l’override operativo, non l’override intenzionale. In altre parole, evita che da un account amministratore si possano collegare nuovi dispositivi USB autoqualificatisi come mouse, tastiere o HID.
Il caso spesso dimenticato: le USB che si presentano come schede di rete (e come bloccarle)
Bloccare le periferiche di input è una misura necessaria ma non sempre sufficiente. Una parte crescente degli attacchi BadUSB non utilizza l’emulazione di tastiere o mouse, ma si basa su dispositivi che si presentano al sistema come schede di rete USB. In questo scenario, la chiavetta non inietta comandi, ma induce Windows a installare una nuova interfaccia di rete, aprendo la strada a tecniche di man-in-the-middle, manipolazione del DNS o instradamento forzato del traffico dati.
Dal punto di vista pratico, questo significa che il semplice blocco delle classi HID non copre l’intera superficie d’attacco.
Su Windows è possibile impedire anche l’installazione di nuovi adattatori di rete, sfruttando le stesse Device Installation Restrictions usate per tastiere e mouse. Operativamente, si tratta di aggiungere alla lista delle classi negate anche la classe Network Adapter, identificata dal relativo GUID di sistema. In questo modo, qualsiasi dispositivo USB che tenti di qualificarsi come scheda di rete viene rifiutato dal sistema al momento dell’enumerazione, prima che possa creare un canale di comunicazione attivo.
L’effetto è immediato: le interfacce di rete già presenti continuano a funzionare normalmente, mentre nuovi dongle Ethernet, adattatori WiFi USB o dispositivi BadUSB non possono essere installati. È una scelta che introduce un vincolo operativo, soprattutto su laptop usati in mobilità, ma che segna una differenza netta tra una mitigazione parziale e una difesa realmente efficace contro i moderni BadUSB attacchi.
Per procedere, è sufficiente valutare l’utilizzo di questa policy aggiuntiva:
:: Blocca nuove schede di rete (incl. USB-Ethernet, RNDIS, CDC-ECM)
reg add "HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceInstall\Restrictions\DenyDeviceClasses" /v 4 /t REG_SZ /d "{4D36E972-E325-11CE-BFC1-08002BE10318}" /f
Come annullare le modifiche
Le restrizioni descritte nei paragrafi precedenti non sono irreversibili. Tutti gli interventi applicati tramite Device Installation Restrictions possono essere annullati in modo pulito rimuovendo le relative chiavi dal registro di sistema.
È importante sia in fase di test, sia nel caso in cui si renda necessario ripristinare temporaneamente la possibilità di installare nuove periferiche USB (ad esempio per manutenzione o aggiornamenti hardware).
Su un singolo PC è sufficiente aprire il prompt dei comandi con privilegi amministrativi ed eliminare i valori aggiunti in precedenza. In particolare, la rimozione delle voci sotto il ramo Restrictions riporta Windows al comportamento standard, consentendo nuovamente l’installazione di nuove periferiche di input e di rete.
Il comando seguente rimuove per intero la chiave di registro contenente tutte le limitazioni imposte in precedenza:
reg delete "HKLM\SOFTWARE\Policies\Microsoft\Windows\DeviceInstall\Restrictions" /f
Da tenere presente che, come suggerisce l’utilizzo dell’hive HKLM, le modifiche valgono ovviamente sull’intera macchina, indipendentemente dall’account utente in uso.
Il ruolo delle “USB intake station”
Il blocco delle periferiche di input non risolve tutto. Rimane il problema dei file potenzialmente malevoli e dell’errore umano. Qui entra in gioco una seconda buona pratica, emersa da anni di esperienza in ambienti corporate e governativi: la USB intake station.
Non si tratta di un prodotto specifico, ma di un processo. Un computer dedicato, separato dagli endpoint degli utenti, è utilizzato esclusivamente per una prima verifica dei supporti rimovibili.
La macchina è configurata in modo restrittivo: sistema operativo aggiornato, EDR attivo, esecuzione da supporti rimovibili limitata o disabilitata, controllo delle classi USB applicato in modo rigoroso.
Il flusso è sempre lo stesso: la chiavetta del cliente è inserita solo su questa postazione, i file vengono copiati in una directory di staging e sottoposti a scansione, e solo successivamente trasferiti verso l’ambiente di lavoro reale.
Il supporto fisico non entra mai in contatto diretto con i laptop degli utenti o con la rete interna. Non è un air gap “militare”, ma una separazione funzionale più che sufficiente per la maggior parte degli scenari realistici.
E su Linux?
Linux viene spesso citato come soluzione “naturale” al problema delle chiavette USB malevole, ma questa percezione è solo parzialmente corretta. È vero che la maggior parte dei malware pensati per Windows non è direttamente eseguibile su sistemi Linux, ma questo non elimina il rischio legato al comportamento del dispositivo USB. Anche su Linux una chiavetta può presentarsi come tastiera, mouse o scheda di rete, sfruttando il normale funzionamento dello stack USB.
Detto questo, Linux offre strumenti di controllo più granulari a basso livello. Tramite meccanismi come udev, usbguard o policy di autorizzazione esplicita dei dispositivi, è possibile limitare quali classi USB sono accettate dal sistema, bloccando periferiche di input o adattatori di rete non autorizzati prima che diventino operativi.
A differenza di Windows, il controllo può essere applicato anche in modo “default deny”, rendendo Linux particolarmente adatto come postazione USB intake station o sistema di analisi preliminare dei supporti rimovibili.
È importante però chiarire un punto: Linux non è una sandbox magica. Se una chiavetta contiene documenti malevoli destinati a essere poi aperti su un sistema Windows, il problema resta invariato. Inoltre, come su Windows, un utente con privilegi di root può sempre modificare o rimuovere le policy di blocco.
Dove si colloca il progetto USBvalve
Su GitHub ha acquistato una certa notorietà l’ottimo progetto USBvalve. Si tratta di un dispositivo “da maker” basato sul conosciutissimo microcontroller Raspberry RP2040, che si mette in mezzo tra la chiavetta e un dispositivo potenzialmente ostile per capire che cosa sta facendo a livello USB/file system, in tempo reale.
USBvalve crea/espone un file system fasullo (una sorta di “disco esca” controllato dal dispositivo) e mostra a schermo se fosse oggetto di accesso (mount/letture iniziali) nonché di letture/scritture.
Il progetto, tuttavia, non fornisce le chiavi per la creazione di un tester universale di chiavette USB e non è una soluzione autonoma che certifica la sicurezza di un dispositivo.
Nella sua modalità principale, USBvalve si presenta come una chiavetta fittizia e serve a osservare il comportamento dell’host a cui viene collegato, non a scansionare un supporto USB reale.
La modalità accessoria permette invece di collegarsi a un dispositivo USB e capire se si presenta come HID (tastiera/mouse) o come device sospetto (o comunque aiutare il debug via seriale). USBvalve non scansiona file: si limita a identificare classi/descrittori USB e comportamenti tipici degli attacchi BadUSB.
Un rischio diverso: USB Killer
In chiusura, è importante citare anche un’altra categoria di minaccia spesso confusa con BadUSB: gli USB Killer. Questi dispositivi non eseguono codice, non emulano periferiche e non contengono malware. Sono strumenti di attacco fisico che accumulano energia e la scaricano ad alta tensione sulle linee USB, con l’obiettivo di danneggiare l’hardware.
Contro questo tipo di minaccia non esistono difese software. Le uniche contromisure sono organizzative o fisiche: limitare l’accesso alle porte USB, utilizzare macchine dedicate o “sacrificabili”, oppure isolatori galvanici. Nei contesti “ordinari”, si tratta in genere di un rischio marginale, ma va ben tenuto distinto concettualmente.