Sei falle in AirDrop e Quick Share: crash a distanza, ma nessun furto di dati

Sei falle in AirDrop e Quick Share: crash a distanza, ma nessun furto di dati

Due ricercatori del CISPA hanno analizzato per la prima volta insieme gli stack di AirDrop e Quick Share: sei vulnerabilità, tre crash a distanza su iPhone e Mac, due bypass su Samsung, un bug su Windows

di pubblicata il , alle 16:41 nel canale Sicurezza
iOSmacOS
 

Due ricercatori del CISPA Helmholtz Center for Information Security hanno pubblicato il 30 giugno sei vulnerabilità nei protocolli di trasferimento di prossimità di Apple e Google, tre in AirDrop e tre nel Quick Share di Google e Samsung. Il risultato più concreto per l'utente è un attacco denial-of-service: da un laptop con Wi-Fi, entro pochi metri, si può far crashare AirDrop su un iPhone o un Mac vicino. Nessuna delle sei falle , è bene precisare, consente il furto di file, l'esecuzione di codice arbitrario o l'aggiramento delle protezioni di sicurezza dei sistemi coinvolti.

Il lavoro di Arash Ale Ebrahim e Nils Ole Tippenhauer, raccolto nel paper Protocol Prying, è il primo studio che mette a confronto i due stack sopra il livello radio. Per farlo i ricercatori hanno dovuto ricostruire tramite reverse engineering del codice binario proprietario la macchina a stati a sette livelli di AirDrop e la sua compressione adattiva DVZip, entrambe non documentate.

Cosa succede quando cade sharingd

Le tre vulnerabilità AirDrop (V1, V2, V3) colpiscono il daemon sharingd su macOS e iOS. Il punto interessante è che quel processo non gestisce solo AirDrop: il suo crash abbatte in un colpo solo anche AirPlay, Handoff, Universal Clipboard, Continuity Camera e NameDrop. Un singolo pacchetto malevolo, quindi, può spegnere buona parte delle funzioni di continuità tra dispositivi proprie dell'ecosistema Apple.

Gli attacchi non richiedono pairing, contatti condivisi o una rete in comune: basta un laptop con Wi-Fi entro 10-30 metri dal bersaglio. C'è però una condizione che ne restringe la portata: funzionano solo sui dispositivi impostati su Chiunque per la ricezione, perché le fasi iniziali del protocollo rispondono prima di qualsiasi richiesta di conferma all'utente.

Nel dettaglio, V1 sfrutta una chiamata fatalError in Swift nel router dei path HTTP: una richiesta a un percorso non riconosciuto abbatte l'intero processo, e inviata in loop ogni due secondi circa mantiene i servizi fuori uso a tempo indefinito. Durante i test, nessun trasferimento AirDrop legittimo è andato a buon fine mentre l'attacco era in corso. V2 è uno stack overflow nel parser XML delle property list di Foundation, innescato da un documento con circa 200 livelli di annidamento, e riguarda qualsiasi app Apple che analizzi plist non attendibili, su macOS, iOS, watchOS, tvOS e visionOS. V3 è un null pointer dereference nel parser HTTP/1.1 di Network.framework. I crash sono stati riprodotti su macOS 15.7.4 e 26.3 e su iOS 18.x e 26.3; una build più vecchia basata su iOS 16 non risultava affetta.

Samsung e Windows: gli altri tre bug

Sul fronte Android, i due problemi riguardano il Quick Share di Samsung. Con V4 un dispositivo non autenticato può guidare la macchina a stati della connessione prima dello scambio di chiavi UKEY2. Con V5, testato su un Galaxy S23 Ultra, alcuni frame vengono elaborati anche se inviati in chiaro dopo che la sessione cifrata è già attiva: un attaccante sulla stessa rete Wi-Fi può forzare una connessione nello stato accettato e farsi restituire dal server indirizzi IP e porte che controlla. Anche qui, nessun furto di file.

Il sesto bug, V6, colpisce il Quick Share per Windows di Google: un heap use-after-free nato da una race condition tra due connessioni concorrenti sullo stesso identificatore. Google ha pagato una ricompensa e rilasciato una correzione nel codice, mentre il CVE è ancora in attesa di assegnazione pubblica; i ricercatori hanno confermato il crash ma non hanno sviluppato un exploit funzionante. Un dettaglio interessante: nel sorgente era presente un commento che riconosceva un bug precedente nello stesso punto, "We had a bug here, caused by a race with EncryptionRunner", e la correzione applicata all'epoca aveva reintrodotto lo stesso tipo di difetto.

Codebase diverse, stessa radice

Lo studio va oltre l'elenco delle falle e riscontra un pattern architetturale condiviso: i controlli di sicurezza critici non sono applicati a un unico confine centralizzato, ma distribuiti nei singoli gestori di protocollo. Due basi di codice completamente diverse, sostiene il ricercatore, sono arrivate alle stesse classi di debolezza proprio perché nessuna delle due impone gli invarianti in un solo punto. Da qui i tre principi che il paper propone per i futuri protocolli di prossimità: applicare autenticazione e cifratura una sola volta al confine del framework anziché nei singoli handler, ridurre al minimo il codice privilegiato raggiungibile prima dell'autenticazione, e integrare fuzzing e test della macchina a stati nello sviluppo standard.

Sul versante delle correzioni, Apple ha comunicato ai ricercatori di aver corretto una delle tre vulnerabilità in un aggiornamento software e di aver assegnato un CVE, il cui advisory non è però ancora pubblico; le altre due restano in divulgazione coordinata senza CVE pubblici, mentre i due bug Samsung sono in indagine presso Google. Il fuzzer usato per la ricerca, chiamato AirFuzz, insieme agli script dei crash e alle note di protocollo è disponibile pubblicamente su Zenodo.

0 Commenti
Gli autori dei commenti, e non la redazione, sono responsabili dei contenuti da loro inseriti - info

Devi effettuare il login per poter commentare
Se non sei ancora registrato, puoi farlo attraverso questo form.
Se sei già registrato e loggato nel sito, puoi inserire il tuo commento.
Si tenga presente quanto letto nel regolamento, nel rispetto del "quieto vivere".

La discussione è consultabile anche qui, sul forum.
 
^