Spegnere NFC e Bluetooth aumenta davvero la sicurezza? La verità tecnica dietro il mito

Negli ultimi tempi ci siamo imbattuti in alcuni articoli, pubblicati da note testate italiane e straniere, che suggeriscono di spegnere NFC e Bluetooth sugli smartphone per evitare attacchi, intrusioni, tracciamenti o furti di dati. Questa narrazione, molto diffusa in articoli divulgativi e blog generalisti, mescola elementi tecnicamente fondati con semplificazioni eccessive, quando non vere e proprie distorsioni. Per affrontare il tema in modo serio è necessario spostare l’attenzione dal sensazionalismo alla valutazione del rischio, distinguendo tra possibilità teorica, sfruttabilità pratica e impatto reale.

L’elemento centrale, spesso trascurato, è che NFC e Bluetooth sono tecnologie wireless e canali di comunicazione. Come qualunque altro canale – rete Wi-Fi, stack TCP/IP, USB – possono diventare vettori di attacco solo in presenza di condizioni precise: un bug implementativo, una configurazione errata, un contesto operativo favorevole all’attaccante. Senza questi fattori, la semplice attivazione dell’interfaccia non equivale a un’esposizione automatica.

In un altro articolo di approfondimento, che suggeriamo di consultare, abbiamo messo a fuoco le principali differenze tra NFC e Bluetooth e come le due tecnologie sono integrate nei dispositivi che usiamo ogni giorno.

NFC: prossimità fisica come meccanismo di sicurezza implicito

NFC (Near Field Communication) nasce con un presupposto architetturale chiaro: la comunicazione deve avvenire a distanza estremamente ridotta. Questo vincolo fisico non è un dettaglio secondario, ma un vero e proprio meccanismo di mitigazione del rischio. Parliamo di pochi centimetri, non di metri, e questo cambia radicalmente lo scenario.

In termini pratici, un attacco NFC richiede che l’attaccante si trovi fisicamente molto vicino al dispositivo bersaglio, con un allineamento sufficiente delle antenne e in una finestra temporale compatibile con l’operazione in corso. Ciò esclude automaticamente la quasi totalità degli attacchi opportunistici e remoti, che costituiscono la maggior parte delle minacce reali su larga scala.

Gli scenari di attacco più citati, come il relay attack, non sono fantasie, ma neppure eventi comuni. Si tratta di tecniche complesse che prevedono la cattura del segnale NFC e la sua ritrasmissione verso un secondo dispositivo, spesso a distanza, con l’obiettivo di simulare la presenza fisica della vittima. Dal punto di vista accademico e dimostrativo sono esperimenti molto interessanti, ma nella realtà operativa presentano costi, complessità e rischi elevati per l’attaccante, a fronte di benefici limitati e facilmente rilevabili dai sistemi antifrode.

Nel caso dei pagamenti contactless, inoltre, il livello di protezione non è affidato unicamente a NFC. Tokenizzazione (sostituzione dei dati reali con identificativi temporanei inutilizzabili fuori dal contesto), limiti di importo (soglie massime oltre le quali l’operazione viene bloccata o richiede verifica), autenticazione periodica (richiesta ricorrente di conferma dell’identità dell’utente) e sistemi di rilevamento comportamentale (analisi automatica delle operazioni per individuare comportamenti anomali) rendono il vettore NFC davvero poco appetibile rispetto a tecniche molto più semplici come il phishing o la compromissione diretta delle credenziali.

Disattivare NFC in contesti affollati può avere senso, ma parlare di NFC come di una minaccia costante e invisibile significa ignorare il suo stesso modello di sicurezza.

Bluetooth: una superficie di attacco storicamente più ampia

Il discorso cambia sensibilmente quando si analizza Bluetooth. Non tanto per una presunta “insicurezza intrinseca”, quanto per la sua complessità strutturale e per l’evoluzione storica del protocollo.

Bluetooth è uno stack articolato, progettato per scenari diversi: audio, input device, sensori, automotive, IoT. Una versatilità che ovviamente non può non avere un prezzo da pagare in termini di superficie di attacco.

Nel corso degli anni sono emerse vulnerabilità reali, alcune anche gravi, che permettevano l’esecuzione di codice o l’accesso non autorizzato senza necessità di pairing esplicito (associazione manuale confermata dall’utente tra due dispositivi, necessaria per autorizzare la comunicazione).

Questi episodi hanno alimentato la narrativa secondo cui “basta avere il Bluetooth acceso per essere hackerati”. Dal punto di vista tecnico, però, si trattava di bug specifici, legati a implementazioni difettose, non di una proprietà permanente insita nel protocollo. C’è una bella differenza!

Oggi, sui dispositivi aggiornati, si implementa il supporto Bluetooth adottando modelli di sicurezza più maturi: pairing esplicito, cifratura del traffico, gestione delle chiavi, restrizioni sui profili.

Il rischio non deriva quindi tanto dall’interfaccia Bluetooth in sé, quanto da dispositivi obsoleti, firmware non aggiornati, gadget economici progettati senza reali considerazioni di sicurezza. In questi casi Bluetooth diventa il mezzo attraverso cui si sfrutta una vulnerabilità preesistente, non la causa primaria del problema.

Spegnere NFC e Bluetooth aumenta davvero la sicurezza? Perché le vere minacce sono altrove

Molti articoli consigliano di spegnere NFC e Bluetooth come misura prioritaria, trascurando il fatto che la maggior parte delle compromissioni avviene attraverso vettori completamente diversi. Applicazioni malevole, social engineering, phishing, exploit di browser o sistemi non aggiornati hanno un impatto incomparabilmente maggiore sulla sicurezza reale dell’utente.

La disattivazione delle interfacce radio è una misura passiva, facile da spiegare e da applicare, ed è per questo che è sovente proposta come soluzione universale. Dal punto di vista professionale, però, il suo valore è marginale se non inserito in una strategia più ampia di gestione del rischio.

Un dispositivo con Bluetooth spento ma sistema operativo non aggiornato resta un bersaglio facile; uno con Bluetooth attivo ma correttamente mantenuto e configurato è, nella pratica, molto più sicuro.

Bluetooth: cosa è successo davvero in passato (e cosa può ancora succedere)

Nel caso di Bluetooth i problemi storici si sono concentrati su 3 aree.

Vulnerabilità nel sistema operativo

La prima riguarda una vulnerabilità nello stack del sistema operativo (il codice che implementa Bluetooth in Android, iOS, Linux, Windows). Il caso “scuola” è BlueBorne (2017): un insieme di vulnerabilità che, su alcuni sistemi, permetteva attacchi anche senza pairing e con interazione minima o nulla, includendo in certi casi esecuzione di codice.

Per Android, ad esempio, tra i bollettini CVE associati c’è anche un problema di Remote Code Execution (RCE) come CVE-2017-0781.

Queste vulnerabilità restano oggi “attuali” solo in un senso: se il dispositivo è vecchio o non patchato. Su Android moderno e aggiornato, quel capitolo è chiuso; ma su device fuori supporto (o su IoT/embedded) il rischio può rimanere.

Debolezze a livello di protocollo

La seconda area è quella delle debolezze di protocollo, dove non è “un bug del produttore X”, ma un problema nella progettazione o nella negoziazione. L’esempio più citato è KNOB (2019, CVE-2019-9506): un attaccante in prossimità può tentare un downgrade della robustezza della chiave durante la negoziazione su Bluetooth Classic, abilitando scenari di man-in-the-middle in condizioni specifiche. Importante: affinché l’attacco possa funzionare, l’aggressore dev’essere vicino e deve inserirsi nel momento giusto della comunicazione.

Lacune del genere rimangono “attuali” solo in caso di combinazioni sfortunate: dispositivi che implementano mitigazioni in modo incompleto, device molto vecchi, oppure accessori con stack datati. Su piattaforme aggiornate molte mitigazioni sono state introdotte (i vari vendor hanno storicamente dedicato ampi sforzi alla gestione del problema KNOB, che è conosciuto e gestito).

Vulnerabilità nel chipset

La terza area è spesso la più sottovalutata: firmware e stack nel chipset Bluetooth (quello dentro cuffie, altoparlanti, auto, IoT e talvolta anche in componenti integrati) possono contenere, loro stessi, delle lacune di sicurezza.

Citiamo BrakTooth (2021), una famiglia di vulnerabilità nel Link Manager/stack di vari SoC: in diversi casi l’impatto pratico era soprattutto sul versante Denial of Service o DoS (crash/freeze), ma in alcuni scenari si parlava anche di impatti più seri a seconda del chip e dell’integrazione. Il punto importante è che, quando il problema è nel firmware del chip, patchare può essere più difficile o dipendere dal produttore del dispositivo finale.

Hijacking della procedura di accoppiamento

Infine, un tema “sempreverde” (e molto realistico) è l’hijacking del pairing, quando i dispositivi entrano in modalità di accoppiamento in modo troppo permissivo o “automatico”. È un’area che continua a produrre studi e ricerche: ad esempio lavori recenti mettono in evidenza rischi legati a comportamenti di pairing automatico su device commerciali.

Ciò non significa che mantenere Bluetooth acceso porti ad eventuali compromissioni, bensì che il pairing è un momento delicato: è lì che si gioca buona parte della sicurezza.

NFC: dove sono state le vere crepe

Per NFC la storia è diversa perché, come evidenziato in precedenza, la distanza limita molto l’opera dell’attaccante, ma ci sono stati problemi reali soprattutto su NFC peer-to-peer / beaming e su parsing di contenuti NFC (NDEF/tag) che portavano ad azioni non desiderate.

Con NFC peer-to-peer / beaming si intende lo scambio diretto di dati tra dispositivi: poteva avviare azioni automatiche non intenzionali. Con il parsing di contenuti NFC (NDEF/tag) l’interpretazione di dati NFC che, in presenza di bug, poteva innescare comportamenti imprevisti del sistema o delle app installate.

Un caso concreto su Android è CVE-2019-2114, legato al “beaming” (Android Beam) e a bypass di controlli in specifiche condizioni: è stato corretto con aggiornamenti di sicurezza e si inserisce in quella classe di problemi dove NFC non “ruba dati da solo”, ma può essere usato come grilletto per consegnare un payload o forzare un flusso non previsto se l’implementazione ha un bug.

Inoltre Android Beam, funzione che permetteva di condividere contenuti (link, contatti, app) tra due dispositivi semplicemente avvicinandoli, non è più supportata ed è da anni del tutto accantonata.

Ci sono poi CVE legati a configurazioni o componenti NFC (ad esempio casi di impostazioni di default insicure o problemi di gestione), ma anche qui alla domanda “quanto il problema è attuale?” si risponde quasi sempre con: dipende dal livello di patch e dal fatto che il dispositivo sia ancora supportato o meno.

Le frodi legate a NFC, secondo ESET

Alcuni articoli fanno riferimento esplicito all’indagine Threat Report H2 2025 ESET per giustificare la necessità impellente di spegnere NFC e abilitarlo soltanto quando strettamente necessario.

ESET riporta un aumento dell’87% nelle rilevazioni di malware Android che abusano dell’NFC nella seconda metà del 2025. Il dato è corretto, ma è spesso estrapolato senza il contesto necessario a comprenderne il significato. Lo stesso report chiarisce che questa crescita segue una fase iniziale di diffusione esplosiva, osservata nei mesi precedenti, quando le frodi NFC hanno iniziato a circolare su larga scala. Il periodo analizzato mostra piuttosto una normalizzazione del fenomeno, con campagne meno rumorose, più mirate e qualitativamente più sofisticate.

Non si tratta quindi di una minaccia improvvisa che colpisce indiscriminatamente tutti gli smartphone con NFC attivo, ma di un’evoluzione di tecniche criminali già note, adattate a contesti geografici e bancari specifici. Questo punto è fondamentale, perché ridimensiona immediatamente l’idea di un rischio universale legato alla semplice presenza del chip NFC.

NGate e PhantomCard: frodi guidate dall’utente, non attacchi invisibili

I casi più citati nel report ESET, come NGate e PhantomCard, sono spesso descritti come esempi di malware capaci di “rubare i dati NFC” in modo automatico o a distanza. In realtà il loro funzionamento è molto più banale, e proprio per questo più efficace dal punto di vista criminale.

NGate non sfrutta vulnerabilità dell’NFC né intercetta comunicazioni passive. Il malware viene installato dall’utente stesso, convinto da phishing, finti operatori bancari o applicazioni che imitano servizi di sicurezza. Una volta ottenuti i permessi necessari, il malware chiede esplicitamente all’utente di avvicinare la carta di pagamento al telefono e di inserire il PIN, simulando una procedura di verifica o protezione. NFC è utilizzato solo in questo momento, come canale tecnico per trasmettere dati che l’utente sta già fornendo volontariamente.

PhantomCard non fa altro che replicare lo stesso schema in un contesto geografico diverso, adattando il linguaggio, le banche di riferimento e l’aspetto delle applicazioni a uno specifico mercato (brasiliano). Dal punto di vista tecnico non introduce nuovi meccanismi di attacco, ma dimostra quanto sia efficace l’ingegneria sociale.

In entrambi i casi, spegnere l’NFC non impedisce l’installazione del malware, non blocca il furto dei contatti, non neutralizza le chiamate di vishing successive. Riduce solo una fase finale che richiede comunque la cooperazione attiva della vittima.

RatOn: il vero salto di qualità è nel controllo remoto, non nell’NFC

RatOn rappresenta l’elemento tecnicamente più interessante del report ESET, perché segna una convergenza tra frodi NFC, trojan bancari e funzionalità tipiche dei Remote Access Trojan. È in grado di abusare dei servizi di accessibilità, simulare interazioni sullo schermo, installare ulteriori payload e persino disattivare l’autenticazione biometrica.

Anche in questo caso, però, NFC non è il punto di ingresso. RatOn arriva sul dispositivo tramite pubblicità ingannevoli, siti falsi e applicazioni fraudolente che promettono servizi inesistenti.

Solo dopo aver ottenuto un controllo profondo del sistema, il malware utilizza NFC come parte di una strategia di frode bancaria più ampia. Attribuire a RatOn la dimostrazione che “NFC è pericoloso” significa confondere un mezzo con lo specifico contesto che lo rende sfruttabile.

Difesa “seria” lasciando NFC e Bluetooth attivi (Android)

Come abbiamo evidenziato in precedenza, il punto non è spegnere le interfaccia NFC e Bluetooth, ma ridurre al minimo ciò che resta sfruttabile: niente superfici inutili, patching rigoroso, pairing controllato, permessi stretti. Alcune impostazioni sono talmente determinanti che, se configurate bene, rendono l’idea dello spegnere tutto molto meno sensata e al limite del puerile.

NFC: come lasciarlo attivo senza esporsi inutilmente

Su molti Android recenti esiste una voce che cambia parecchio lo scenario: Richiedi sblocco del dispositivo per NFC. Attivandola, anche se NFC è abilitato, il telefono non esegue operazioni NFC “sensibili” quando è bloccato, riducendo drasticamente l’utilità di qualsiasi attacco opportunistico di prossimità.

Il percorso da seguire prevede tipicamente l’accesso alle impostazioni quindi una serie di tocchi su Dispositivi connessi, Preferenze di connessione, NFC, Richiedi sblocco del dispositivo per NFC.

La disponibilità di questa configurazione, tuttavia, può variare per brand/ROM. Quando non c’è, con ogni probabilità, NFC è configurato per rispondere alle “sollecitazioni” solo quando lo smartphone è sbloccato.

Conviene poi verificare che non siano attive funzioni di condivisione NFC stile Beam (quando presenti su device/ROM particolari): abbiamo detto che Android Beam è stato abbandonato ma alcuni produttori ne hanno mantenuto delle varianti.

Bluetooth: come tenere attivo riducendo i rischi concreti

Il principio difensivo più importante è evitare che il telefono diventi un bersaglio facile da trovare e agganciare. In pratica: non essere rilevabile (non rispondere alle richieste di discovery via Bluetooth) e rendere il pairing un’azione intenzionale.

Su Android, per impostazione tipica, il dispositivo non resta costantemente discoverable: lo diventa in particolare quando l’utente sta espressamente cercando/aggiungendo un altro device Bluetooth (le cuffie, gli speaker, la TV, il PC, il sistema di infotainment dell’autovettura,…). Anche le linee guida per sviluppatori descrivono la discoverability come temporanea (di default circa 2 minuti).

Android, inoltre, può avviare una scansione Bluetooth scanning per migliorare la localizzazione anche quando l’opzione Bluetooth è disattivata nelle impostazioni. Ciò se la funzione è attiva nei servizi di localizzazione. Non ci sono rischi di compromissione ma è comunque una superficie di esposizione “ambientale” che vale la pena controllare. Su Android 12+ si può farlo accedendo alle impostazioni del dispositivo mobile, scegliendo Posizione, Servizi di localizzazione, Scansione di dispositivi Bluetooth (è possibile disattivare la funzione).

Infine il tema del controllo applicativo. Soprattutto da Android 12 in poi, l’accesso al Bluetooth per i dispositivi limitrofi passa sempre più da permessi espliciti eventualmente accordati alle singole app installate (app con autorizzazione di accesso ai dispositivi nelle vicinanze).

Ancora una volta, non c’è bisogno di spegnere Bluetooth del tutto: basta togliere i permessi Bluetooth/Posizione alle app che non ne hanno bisogno, perché molte “storie” di tracciamento e scansione derivano da app con permessi larghi, non da una vulnerabilità dello stack.

Le due misure di protezione che battono tutte le “super-impostazioni”

1. Verificare e mantenere aggiornato il livello patch Android (Security patch level). Gran parte delle vulnerabilità “storiche” (BlueBorne, bug NFC/Beam, varie RCE nello stack) diventano irrilevanti se il device è patchato. Ovviamente, questo prevede che il proprio dispositivo sia supportato dal produttore e non abbia raggiunto il suo fine vita (End of Life, EoL).
2. Trattare il pairing come un’operazione “privilegiata”: accoppiare dispositivi Bluetooth solo quando serve, in un luogo controllato, e se arriva una richiesta inattesa rifiutarla senza indugio. Un comportamento del genere taglia le gambe alla maggior parte degli scenari realistici di hijacking, soprattutto con accessori audio che entrano in pairing “da soli” in certe condizioni.

Bluejacking e Bluesnarfing

Molti articoli che lanciano l’allarme sul fatto di tenere sempre acceso Bluetooth citano Bluejacking e Bluesnarfing come minacce dalle quale è imperativo proteggersi. Ma è davvero così?

Bluejacking nasce nei primi anni 2000 ed è, tecnicamente, l’invio di messaggi non richiesti via Bluetooth sfruttando meccanismi di condivisione di contatti o testi. Non prevede accesso ai dati, non prevede esecuzione di codice, non prevede compromissione del dispositivo.

Oggi, su Android e iOS moderni, il Bluejacking è di fatto irrilevante perché la discoverability del dispositivo (come spiegato in precedenza) non è permanente; l’utente deve confermare attivamente ricezioni o pairing; molte delle vecchie modalità di invio sono state rimosse o limitate. In ogni caso, Bluejacking è assimilabile a spam locale a corto raggio, non a un vettore di attacco. È fastidioso, non pericoloso.

Il Bluesnarfing, al contrario, è stato un vero problema di sicurezza, soprattutto tra il 2003 e il 2006. In questo caso parliamo di accesso non autorizzato a dati (rubrica, SMS, calendario); sfruttamento di implementazioni difettose; assenza o bypass dei controlli di autenticazione.

Tecnicamente, il Bluesnarfing funzionava perché alcuni stack Bluetooth permettevano l’invio di richieste (OBEX) senza pairing; i controlli di autorizzazione erano assenti o mal implementati; i dispositivi restavano visibili e “ricercabili” in modo persistente. Non era un limite del Bluetooth, ma un bug di implementazione negli stack di allora.

Sugli smartphone moderni il Bluesnarfing non è più possibile e resta legato ai soli dispositivi molto vecchi, che la maggior parte di noi ha conferito nei rifiuti RAEE o che ancora tiene in qualche cassetto.

Conclusioni

L’analisi del funzionamento di NFC e Bluetooth porta a una conclusione piuttosto chiara: non esiste una correlazione diretta e automatica tra “interfaccia attiva” e compromissione del dispositivo. Esistono invece contesti, condizioni e vulnerabilità specifiche che possono rendere queste tecnologie sfruttabili, ma sempre all’interno di scenari ben delimitati e, nella maggior parte dei casi, evitabili con misure di igiene digitale di base.

Due parole finali su NFC…

NFC, per progettazione, nasce come tecnologia a rischio intrinsecamente contenuto. La prossimità fisica richiesta, unita ai meccanismi di sicurezza aggiuntivi introdotti negli ecosistemi di pagamento e nei sistemi operativi moderni, fa sì che il suo abuso su larga scala sia poco conveniente e raramente invisibile. I casi reali di frode osservati negli ultimi anni dimostrano che NFC non è il vettore di ingresso, ma uno strumento utilizzato dopo che l’utente è già stato manipolato tramite phishing o ingegneria sociale.

…e due su Bluetooth

Bluetooth, al contrario, presenta una superficie di attacco storicamente più ampia, ma non perché “insicuro di natura”. La complessità dello stack, la varietà di profili supportati e la lunga eredità di dispositivi obsoleti spiegano gran parte dei problemi emersi nel tempo. Anche qui, però, il fattore determinante non è l’accensione dell’interfaccia, bensì lo stato del sistema: patch applicate, firmware aggiornati, pairing gestito in modo consapevole, permessi concessi con criterio.

Spegnere NFC e Bluetooth non è una misura di sicurezza prioritaria

L’idea che spegnere NFC e Bluetooth rappresenti una misura di sicurezza prioritaria è, in definitiva, una semplificazione rassicurante ma fuorviante. Serve più a trasmettere un senso di controllo che a ridurre realmente il rischio. Le minacce concrete continuano a concentrarsi altrove: applicazioni malevole installate volontariamente, exploit su sistemi non aggiornati, abuso dei servizi di accessibilità, frodi guidate dall’interazione umana.

La sicurezza reale non nasce dalla disattivazione preventiva di tecnologie legittime (Bluetooth, peraltro, può essere riattivato dal sistema operativo e da alcune applicazioni sempre se si concedono i relativi permessi…), ma da una gestione attiva e informata del rischio. Tenere il sistema aggiornato, limitare i permessi delle app, trattare pairing e autorizzazioni come operazioni privilegiate e diffidare di richieste inattese resta infinitamente più efficace di un “interruttore off”.