Chrome rende inutili i cookie rubati: Google attiva DBSC

Google ha avviato la distribuzione generale di una protezione che punta a colpire uno dei meccanismi più sfruttati dai gruppi criminali specializzati in infostealer: il furto dei cookie di sessione. La novità riguarda Chrome ed è incentrata sulla tecnologia Device Bound Session Credentials (DBSC), della quale avevamo già parlato tempo e che è concepita per impedire che un token di autenticazione sottratto da un malware possa essere riutilizzato su un altro dispositivo.

La decisione arriva dopo anni in cui il mercato criminale ha trasformato i cookie rubati in una merce estremamente redditizia. In molti casi gli attaccanti non hanno più bisogno di conoscere password o codici 2FA: basta impossessarsi della sessione già autenticata per accedere, per esempio, a servizi cloud, piattaforme aziendali, account Google, Microsoft 365 e applicazioni SaaS. Diverse campagne attribuite a malware come Lumma, Vidar, StealC e altre famiglie di infostealer hanno dimostrato quanto il fenomeno sia diventato esteso e, addirittura, industrializzato.

Perché i cookie di sessione sono diventati un bersaglio prioritario

Quando un utente effettua l’accesso a un servizio web, il server genera normalmente un cookie che rappresenta la sessione autenticata. Finché il token, “lasciapassare” alfanumerico memorizzato all’interno del cookie, rimane valido il browser può continuare a comunicare con il servizio senza richiedere nuovamente username, password o autenticazione a due fattori (o MFA, più fattori).

Molti malware cercano proprio cookie di sessione attivi sui dispositivi delle vittime: una volta ottenuti, li esportano verso server controllati dagli attaccanti. Da quel momento un criminale può importare il cookie nel proprio browser e assumere l’identità della vittima ponendo in essere quello che è chiamato un attacco di session hijacking.

Aggressioni di questo tipo hanno purtroppo mietuto parecchie vittime, alcune di primissimo piano, come vi abbiamo raccontato in passato.

La tecnica ha acquisito enorme popolarità perché aggira molte delle difese tradizionali: anche un account protetto da 2FA/MFA può risultare vulnerabile se il cookie di sessione viene riutilizzato correttamente dall’aggressore.

Come funziona Device Bound Session Credentials in Google Chrome

Google aveva presentato il progetto nel 2024, inizialmente come sperimentazione per gli sviluppatori. Dopo una fase di test che ha coinvolto partner del settore identity e autenticazione, la funzione è entrata nelle release moderne di Chrome per Windows e ora raggiunge progressivamente tutti gli utenti. L’obiettivo è ridurre in modo significativo l’acquisizione del controllo sugli account delle vittime basati sul cosiddetto “pass the cookie“, tecnica che consente di ereditare una sessione autenticata senza conoscere le credenziali originali.

La protezione introdotta da Google in Chrome modifica il modello classico dei cookie di autenticazione. Invece di considerare il token come un semplice elemento trasferibile, Chrome lo associa crittograficamente al dispositivo attraverso il quale l’utente ha effettuato il login.

In pratica il browser genera una coppia di chiavi di cifratura utilizzando componenti hardware di sicurezza presenti nel sistema operativo. Sui sistemi Windows il meccanismo sfrutta il chip TPM: la chiave privata rimane confinata all’interno del modulo hardware e non può essere esportata.

Quando il server deve verificare la validità della sessione, Chrome dimostra di possedere la chiave corretta. Se un malware sottrae soltanto il cookie ma non può ottenere la chiave privata associata, il token perde gran parte del suo valore.

Google ha progettato il sistema affinché i siti possano implementare a loro volta DBSC senza stravolgere la logica applicativa esistente: i server mantengono il controllo delle sessioni mentre il browser gestisce gli aspetti legati alla prova crittografica del possesso della chiave.

I limiti della nuova protezione DBSC

Molti osservatori hanno accolto positivamente il rilascio di DBSC all’intera platea degli utenti di Chrome, ma hanno anche evidenziato alcune limitazioni pratiche.

Se un malware mantiene il controllo diretto del computer della vittima, può continuare a operare localmente utilizzando la sessione autentica presente sul dispositivo. In uno scenario del genere il problema non è più il trasferimento del cookie verso un altro sistema, bensì la presenza stessa dell’attaccante sulla macchina.

Inoltre gli infostealer moderni non raccolgono soltanto cookie: i log sottratti includono spesso password salvate, indirizzi email, dati personali, chiavi SSH, configurazioni VPN, token cloud e numerose altre informazioni sensibili.

Un altro elemento da considerare riguarda la compatibilità. L’adozione completa di DBSC, come accennato al paragrafo precedente, richiede il supporto da parte dei servizi web e dei fornitori di identità. Google ha collaborato con realtà come Okta durante le fasi di test, ma servirà tempo prima che l’intero settore implementi il nuovo modello di protezione.

Come verificare se DBSC è attivo e in uso su Chrome?

Per verificare se la tua installazione di Chrome supporta già DBSC e per capire quando un sito lo utilizza, bisogna distinguere tra supporto del browser e adozione da parte del sito web. Dando per scontata la presenza e l’effettivo impiego, sul sistema in uso, del chip TPM, digitando chrome://flags quindi DBSC, si dovrebbe trovare il riferimento all’impostazione che permette di forzare l’attivazione della nuova funzionalità di sicurezza e di protezione dei cookie di sessione. Nelle versioni più recenti, il flag legato a DBSC potrebbe sparire in quanto la funzione sarà direttamente integrata.

DBSC non aggiunge cookie speciali facilmente identificabili con gli strumenti standard del browser: il meccanismo coinvolge uno scambio crittografico tra browser e server.

Il metodo più affidabile è utilizzare gli Strumenti per sviluppatori di Chrome premendo il tasto F12, accedendo alla sezione Network quindi ricaricando la pagina di autenticazione/login. DBSC utilizza nuove intestazioni HTTP definite dal protocollo: si possono quindi cercare richieste contenenti header come Sec-Session-Google oppure riferimenti a Session-Binding o, ancora, challenge di autenticazione legate a chiavi del dispositivo.

Chrome dispone di un sistema di logging molto dettagliato accessibile digitando chrome://net-export nella barra degli indirizzi. Includendo cookie e credenziali quindi avviando la cattura del traffico, si può effettuare il login sul sito da analizzare e infine interrompere la registrazione.

Come specificato in questa pagina, si può quindi usare Netlog Viewer per esaminare il log generato e cercare termini come device_bound, dbsc, session_binding, bound_session. Tutti i dati restano in locale: nulla è caricato su server remoti. Se il sito utilizza DBSC, spesso compaiono eventi specifici relativi alla creazione o all’uso delle credenziali vincolate al dispositivo.