Passa ai contenuti principali

Owna le tue cuffie, exploit HFP via Bluetooth vulnerabile (attivare il microfono delle tue cuffie)

Negli ultimi giorni è stata svelata una serie di vulnerabilità nei chip Bluetooth della famiglia Airoha, integrati in decine di dispositivi audio wireless tra cui auricolari TWS, cuffie, speaker e microfoni venduti da marchi noti come Beyerdynamic, Bose, Sony, Marshall e altri. La scoperta è stata resa pubblica dal team di ricerca tedesco ERNW durante la conferenza TROOPERS, tenutasi il 29 giugno 2025. Queste falle permettono ad un aggressore nelle vicinanze di eseguire azioni come ascoltare l’audio in riproduzione, controllare funzioni del dispositivo via Bluetooth e addirittura attivare il microfono remoto tramite manipolazione del profilo HFP (Hands-Free Profile), che normalmente viene utilizzato per le chiamate vocali.

I ricercatori hanno individuato tre vulnerabilità principali, tutte localizzate nel firmware dei chip Airoha, già ampiamente diffusi nel mercato consumer. Si tratta di CVE‑2025‑20700, CVE‑2025‑20701 e CVE‑2025‑20702, tutte con un punteggio di rischio compreso tra 6.7 e 7.5 su 10. I problemi derivano dall’assenza di autenticazione nell’accesso ai servizi GATT e Bluetooth BR/EDR, oltre che da debolezze nel protocollo custom proprietario impiegato da Airoha. Di fatto, questo consente a un attaccante di impersonare un dispositivo legittimo e iniettare comandi o leggere dati in chiaro (come titoli di canzoni o identificatori di sessione).

Il vettore d’attacco più interessante riguarda il dirottamento del profilo HFP. Utilizzando hardware accessibile e strumenti noti per il penetration testing su Bluetooth, è possibile inviare comandi AT (Attention) simulando una sessione telefonica e, a quel punto, attivare il microfono o inoltrare chiamate a numeri arbitrari. In uno scenario realistico, ciò potrebbe permettere di ascoltare l’ambiente intorno allo smartphone della vittima sfruttando le cuffie accoppiate.

Di seguito un esempio illustrativo in Python, basato su scapy e bluetooth stack. Il codice simula l’invio di un comando AT via Bluetooth per avviare una chiamata. Non è un exploit reale ma serve a comprendere la logica:


from scapy.all import *
from scapy.layers.bluetooth import *

def spoof_hfp_call(target_bdaddr, attacker_bdaddr, phone_number):
    at_call = HCI_Command(HCI_CmdCode=0xFC0C)/  # HCI_VENDOR_CMD (esempio)
             Raw(load=f'ATD{phone_number};')
    sendp(at_call,
          iface="hci0",
          count=1,
          verbose=True)
    print(f"[+] Inviato comando chiamata a {phone_number}")

if __name__ == "__main__":
    spoof_hfp_call("AA:BB:CC:DD:EE:FF", "11:22:33:44:55:66", "+391234567890")



Questo tipo di attacco, nella sua forma completa, richiede l’utilizzo di strumenti come InternalBlue o hardware come Ubertooth o adattatori CSR modificati. È necessario anche effettuare il reverse engineering del firmware, o disporre di log UART provenienti da debugging di dispositivi vulnerabili. Una volta acquisita la chiave di pairing o sfruttata la debolezza nell’autenticazione, l’attaccante può stabilire una connessione senza essere notato, controllare la riproduzione audio, leggere metadati, inoltrare chiamate e — se il firmware lo consente — aggiornare il dispositivo con codice maligno (wormable firmware overwrite).

Per poter mettere in atto l’attacco, è necessaria la prossimità fisica: il Bluetooth Class 2 normalmente opera nel raggio di circa 10 metri, ma in condizioni ottimali con antenne modificate può arrivare anche a 100 metri. L’attacco non è quindi scalabile su larga scala, ma è perfettamente plausibile in contesti come hotel, treni, ambienti corporate, conferenze, ecc.

Attualmente, Airoha ha pubblicato un SDK aggiornato contenente le patch, ma la distribuzione è a carico dei produttori finali. In molti casi, i firmware attualmente in circolazione sono anteriori alla data di pubblicazione del fix (27 maggio 2025), il che lascia milioni di utenti esposti. Gli utenti possono mitigare i rischi disattivando il Bluetooth quando non è strettamente necessario, evitando accoppiamenti con dispositivi sospetti o sconosciuti, e aggiornando il firmware non appena disponibile attraverso i canali ufficiali del produttore.

Questa vulnerabilità dimostra, ancora una volta, come dispositivi ritenuti “innocui” come le cuffie possano diventare vettori di attacco contro la privacy personale e aziendale. Le debolezze nei protocolli low-level e nei firmware closed-source rappresentano un punto cieco nella catena della sicurezza. Seppur non ancora sfruttata in modo massivo, la falla Airoha merita attenzione, soprattutto da parte di chi lavora in ambiti dove la riservatezza è cruciale.

Commenti

Popolari

Le ombre di Teheran nei server USA. Hacker iraniani minacciano ex collaboratori di Trump, caccia all’email perduta

Ho appena letto un report di Reuters – e sì, la notizia è confermata e tombale – che vale un approfondimento. Un collettivo di hacker presumibilmente legato all’Iran, che si fa chiamare “Robert”, ha detto di essere in possesso e pronto a vendere circa 100 GB di email trafugate da ex collaboratori di Donald Trump: Susie Wiles (capo di gabinetto), Lindsey Halligan (avvocata), Roger Stone (consigliere politico) e perfino Stormy Daniels. Il gruppo aveva già fatto trapelare materiale simile a fine 2024, senza però influenzare davvero gli esiti elettorali. Negli scambi con Reuters, “Robert” ha lanciato l’ennesima minaccia: “abbiamo intenzione di organizzare la vendita di queste email e vogliamo che sia Reuters a trasmettere la notizia”, hanno detto . Un tentativo palese di cyber‑propaganda orchestrata a freddo. Le autorità statunitensi – FBI e DOJ – e l’agenzia CISA definiscono il tutto un’“operazione diffamatoria mirata”, un tentativo fatto con cura per destabilizzare, dividere e minare la ...

Quando anche sudo tradisce. Due bug, un root e una chroot

Non succede spesso che sudo, uno dei comandi più fidati e scrutinati del mondo Unix, finisca sotto i riflettori per una vulnerabilità davvero seria. Stavolta è successo due volte, e una delle due fa davvero male. Due bug scoperti e documentati di recente – CVE-2025-32462 e CVE-2025-32463 – mostrano come, anche dopo più di 12 anni di sviluppo, errori silenziosi possano ancora nascondersi in piena vista. Il primo, CVE-32462, è quasi romantico per quanto è vecchio: un difetto nell’uso dell’opzione --host che, in determinate configurazioni di sudoers, può consentire a un utente locale di eseguire comandi con privilegi su host che non dovrebbe nemmeno poter vedere. Roba da manuale, bassa priorità, ma comunque un richiamo interessante per chi pensa che le configurazioni “da laboratorio” non portino guai. Il secondo è molto più cattivo. CVE-32463 sfrutta l’opzione -R di sudo, che consente di specificare una directory chroot. L’idea è che tu possa lanciare comandi in un ambiente isolato, ma ec...