Poster: Mind the Gap -- Characterizing the Temporal Blind Spot Between GSB and DNS Resolution

Sintesi Tecnica: Caratterizzazione del Punto Cieco Temporale tra GSB e Risoluzione DNS

Definizione del Problema
La navigazione web moderna si basa sull'esecuzione concorrente di controlli di sicurezza a livello di browser, specificamente Google Safe Browsing (GSB), e della risoluzione del Domain Name System (DNS). Sebbene GSB identifichi le risorse potenzialmente malevole e il DNS mappi i domini verso destinazioni di rete, la loro sincronizzazione a livello di pacchetto rimane poco studiata. Ciò è particolarmente rilevante in scenari complessi che coinvolgono catene di Canonical Name (CNAME), dove sono necessari molteplici passaggi DNS per ottenere l'indirizzo finale. Il problema centrale affrontato è se esista un gap temporale misurabile tra la chiusura delle query relative a GSB e l'arrivo delle risposte DNS finali. Se tale gap esiste, potrebbe creare un "punto cieco temporale" in cui il browser prende una decisione di sicurezza prima che l'endpoint di rete sia completamente stabilito, esponendo potenzialmente il sistema a minacce di manipolazione del DNS (ad esempio, avvelenamento della cache o manipolazione del resolver) che alterano l'endpoint dopo che il controllo di sicurezza è stato completato.

Metodologia
Gli autori hanno impiegato un approccio di analisi della cattura dei pacchetti per caratterizzare la relazione temporale tra gli eventi GSB e la risoluzione DNS.

• Definizione della Metrica: Lo studio definisce un gap temporale ($\Delta time$) come la differenza tra l'arrivo della risposta DNS finale ($T_{resolution}$) e la chiusura a livello di trasporto della connessione correlata a GSB ($T_{query\_close}$). Un $\Delta time$ positivo indica che la risposta DNS arriva dopo che la query GSB è stata chiusa.
• Estrazione dei Dati: Il traffico GSB è stato identificato tramite i metadati TLS Server Name Indation (SNI). Poiché i dati applicativi sono criptati, $T_{query\_close}$ è stato determinato dal timestamp del relativo pacchetto TCP FIN o RST. Per le risoluzioni basate su CNAME, $T_{resolution}$ è stato registrato dal pacchetto contenente l'ultimo record A o AAAA.
• Configurazione Sperimentale: Gli esperimenti sono stati condotti su una workstation macOS utilizzando Google Chrome Stable. Per minimizzare gli effetti di caching, la cache DNS di sistema e lo stato del browser sono stati azzerati prima di ogni navigazione. Un framework Node.js ha coordinato l'automazione del browser e la cattura dei pacchetti (utilizzando Tshark) attraverso due dataset derivati dal ranking Tranco:
  1. Domini Generali: I 100 domini più popolari.
  2. Domini CNAME: 103 domini ad alto ranking che richiedono esplicitamente la risoluzione CNAME.

Risultati Chiave
L'analisi empirica ha rivelato un offset temporale costante tra le chiusure delle query GSB e le risposte DNS:

• Prevalenza: Gap temporali positivi sono stati osservati in circa il 78% del dataset dei domini generali (78 su 100 campioni) e nel 79,6% del dataset dei domini CNAME (82 su 103 campioni).
• Magnitudo:
  • Ritardi Mediani: Il ritardo mediano è stato di 79,40 ms per i domini generali e di 67,88 ms per i domini CNAME.
  • Ritardi Massimi: I gap massimi osservati hanno superato significativamente la mediana, raggiungendo i 2.349,54 ms per i domini generali e i 2.477,32 ms per i domini CNAME.
  • Dati Rappresentativi: Domini specifici hanno mostrato gap variabili, con facebook.com a 45 ms e amazonaws.com a 1.034 ms.
• Consistenza: I risultati indicano che, sebbene molti gap siano inferiori a 100 ms, l'esistenza di una "coda lunga" di ritardi superiori ai due secondi è una caratteristica ricorrente del flusso di navigazione.

Significatività e Claim
Il documento sostiene con moderazione che questi risultati identificano un precondizione temporale rilevante per la sicurezza piuttosto che un bypass completo del browser.

• Modello di Minaccia: Sotto un modello di minaccia in cui un avversario può influenzare la risoluzione DNS (ad esempio, tramite avvelenamento della cache o manipolazione on-path), i gap temporali osservati suggeriscono una finestra in cui l'endpoint risolto finale potrebbe essere alterato dopo che il controllo di Safe Browsing è stato completato.
• Implicazione: Ciò crea un potenziale disallineamento tra la decisione di sicurezza del browser e l'effettivo endpoint di rete. Gli autori sostengono che questa desincronizzazione temporale, particolarmente nei CNAME complessi, richiede ulteriori ricerche sui rischi legati al timing.
• Direzioni Future: Il documento suggerisce che il lavoro futuro dovrebbe esplorare scenari di manipolazione DNS controllata per determinare se questi gap possano essere sfruttati in attacchi pratici end-to-end. Propone inoltre di investigare le mitigazioni lato browser, come il vincolo delle decisioni di sicurezza all'endpoint DNS risolto finale o l'attivazione della rivalidazione quando la risoluzione DNS si completa post-controllo.

In sintesi, lo studio fornisce una caratterizzazione fondamentale a livello di pacchetto della desincronizzazione tra GSB e DNS, evidenziando una finestra temporale misurabile e frequente che può essere rilevante per i meccanismi di sicurezza del browser sotto specifici modelli di minaccia.