ModHeader rimossa da Chrome: 900.000 utenti esposti alla raccolta nascosta dei dati

🛡️ Executive Summary

• ModHeader osservava i siti visitati tramite permessi estesi, estraeva i domini e conservava localmente dati cifrati pronti per l’esfiltrazione.
• La telemetria era attiva, mentre l’invio della cronologia risultava dormiente ma attivabile attraverso configurazioni o aggiornamenti successivi.
• Google ha rimosso l’estensione; utenti e aziende devono disinstallarla, bloccare i domini coinvolti e revisionare le policy sulle estensioni.

ModHeader, una nota estensione Chrome utilizzata per modificare gli header HTTP, è stata rimossa dal Chrome Web Store dopo la scoperta di una pipeline nascosta capace di osservare le pagine visitate, estrarre i domini e preparare i dati per una possibile esfiltrazione verso server esterni. L’estensione contava circa 900.000 utenti ed era distribuita attraverso lo store ufficiale con firma valida e identificativo verificato da Google. La versione 7.0.18, pubblicata il 1° luglio 2026, conteneva codice minificato destinato alla raccolta dei dati, mentre una componente di telemetria continuava a comunicare con infrastrutture di terze parti. Google ha rimosso ModHeader il 10 luglio 2026, ma le installazioni già presenti potrebbero continuare a funzionare fino alla disinstallazione manuale.

ModHeader nascondeva la raccolta nel codice di una funzione legittima

La scoperta è avvenuta durante un’attività di incident response condotta dai ricercatori di Stripe OLT, che hanno individuato una serie di anomalie nel pacchetto dell’estensione. Tra gli elementi sospetti figuravano un errore nell’indirizzo attribuito all’autore, riportato come “modhader@”, e la stringa cinese “mod盐header” inserita nel codice. L’analisi successiva ha rivelato una logica di sorveglianza integrata nel codice minificato e mescolata alle funzionalità legittime di ModHeader e alla libreria Dexie, utilizzata per gestire database IndexedDB nel browser. Questa commistione rendeva difficile distinguere le operazioni necessarie alla modifica degli header dalle componenti dedicate alla raccolta dei dati. L’estensione era disponibile con l’ID idgpnmonknjnojddfkpgkljpfnnfcklj, risultava firmata correttamente ed era stata ammessa nello store ufficiale, elementi che potevano indurre utenti e amministratori a considerarla affidabile. Le prime segnalazioni pubbliche relative a possibili iniezioni pubblicitarie risalivano almeno al 2023, periodo nel quale il progetto aveva adottato un modello supportato dalla pubblicità, ma il comportamento più invasivo è rimasto inosservato fino all’indagine del 2026. Il caso conferma come la presenza nel Web Store, il numero elevato di installazioni e una lunga storia operativa non costituiscano garanzie sufficienti. Un rischio simile era già emerso con le 152 estensioni Chrome che falsificavano il traffico Google e nascondevano attività di tracking, dimostrando quanto sia difficile individuare comportamenti malevoli quando sono incorporati in prodotti apparentemente utili e dotati di permessi coerenti con la funzione dichiarata.

I permessi consentivano di osservare tutte le pagine visitate

ModHeader disponeva di autorizzazioni estese, tra cui webRequest, content_scripts applicati a tutti gli URL, alarms, storage e scripting. Per un’estensione destinata a modificare gli header HTTP, una parte di questi permessi può apparire tecnicamente giustificata, perché il prodotto deve leggere e manipolare richieste dirette a numerosi siti. La stessa capacità legittima, tuttavia, consentiva al codice nascosto di iniettare script su ogni pagina, osservare il traffico del browser ed estrarre i domini dagli URL visitati. I domini venivano raccolti fino a un massimo di 1.000 valori unici, quindi cifrati con AES-GCM attraverso una chiave hardcoded e un vettore di inizializzazione casuale. I risultati venivano conservati nei database IndexedDB denominati “temp” e “settings”, creando una riserva locale pronta per un invio successivo. Un service worker generava inoltre un’impronta del dispositivo basata su SHA-256 del timestamp e associava i dati a un identificatore del browser, rendendo possibile distinguere le diverse installazioni. La logica prevedeva una pianificazione giornaliera con jitter, tecnica che distribuisce le comunicazioni nel tempo per evitare pattern troppo regolari e ridurre la probabilità di rilevamento. Al momento dell’analisi, la componente destinata all’esfiltrazione completa dei domini risultava inattiva perché la relativa lista di autorizzazione era vuota, ma il codice necessario era già presente. Una modifica remota, una nuova configurazione o un aggiornamento avrebbero quindi potuto attivare il trasferimento senza introdurre una nuova architettura visibile. Questa possibilità avvicina il caso alle campagne basate su estensioni dormienti o riconvertite dopo aver accumulato una vasta base di utenti, come accaduto con ShotBird e GhostClaw, capaci di sfruttare estensioni Chrome e pacchetti npm per rubare dati.

Telemetria attiva e infrastruttura predisposta per l’esfiltrazione

Sebbene l’invio della cronologia fosse dormiente durante i test, ModHeader manteneva attiva una pipeline di telemetria che trasmetteva informazioni relative a installazione, aggiornamento e disinstallazione. Le comunicazioni erano dirette verso extensions-hub.com, attraverso l’endpoint https://www.extensions-hub.com/partners/, mentre il codice predisposto per l’esfiltrazione dei domini indicava https://api.stanfordstudies.com/app/log come possibile destinazione. L’infrastruttura di backend comprendeva inoltre cluster OpenSearch ospitati su AWS us-east-2 e domini registrati con caratteristiche considerate sospette dai ricercatori. La cifratura lato client avrebbe impedito a proxy e strumenti di monitoraggio tradizionali di leggere direttamente il contenuto dei dati inviati, obbligando le difese a concentrarsi su destinazioni di rete, frequenza delle richieste e comportamento dell’estensione. Parallelamente, l’applicazione conservava in chiaro metadati relativi alle richieste osservate, inclusi scambi pubblicitari e comunicazioni con servizi di analytics. La combinazione tra dati cifrati pronti all’invio, log locali in chiaro e identificativi del browser costruiva una pipeline completa per associare una singola installazione ai siti visitati e alle attività eseguite. Il rischio non dipende quindi soltanto dal fatto che l’esfiltrazione fosse già attiva, ma dalla presenza di un’infrastruttura pronta a essere abilitata su una base installata di 900.000 utenti. L’esperienza delle estensioni Phantom Shuttle, false VPN Chrome che intercettavano traffico e credenziali, mostra come operatori malevoli possano mantenere comportamenti apparentemente innocui per lunghi periodi prima di modificare la configurazione o attivare funzioni più aggressive.

I domini visitati possono rivelare infrastrutture aziendali sensibili

La raccolta dei soli domini può sembrare meno grave rispetto al furto di password o contenuti completi, ma in un ambiente enterprise rappresenta una fonte informativa di grande valore. Gli URL visitati possono rivelare nomi di applicazioni interne, portali VPN, console cloud, pannelli amministrativi, provider di identità, ambienti di sviluppo, repository, sistemi di ticketing e sottodomini non pubblici. La conoscenza di queste risorse permette a un attaccante di ricostruire la superficie digitale di un’organizzazione, identificare tecnologie utilizzate e preparare campagne di phishing o intrusione più credibili. Un dominio come una console AWS, un tenant Microsoft 365, un pannello Okta o un’istanza GitLab privata non espone direttamente una password, ma fornisce indicazioni precise sugli strumenti sui quali concentrare attacchi successivi. Anche i metadati delle richieste pubblicitarie e di analytics possono contribuire alla profilazione dell’utente, collegando navigazione, sessioni e interessi professionali. Il rischio cresce quando l’estensione opera su browser utilizzati per attività personali e lavorative, perché la stessa installazione può osservare servizi bancari, wallet, email, portali sanitari e applicazioni aziendali. La presenza di un’impronta persistente del dispositivo consente inoltre di associare nel tempo i domini visitati a una specifica installazione, costruendo un profilo comportamentale più completo. Per le imprese, il caso dimostra che la sicurezza delle estensioni non può essere affidata esclusivamente alla reputazione dello sviluppatore o alla presenza nello store ufficiale. Devono essere adottate allowlist centralizzate, revisioni periodiche dei permessi, inventari delle versioni installate e controlli sul traffico generato dai componenti del browser.

La rimozione dal Web Store non elimina automaticamente il rischio

Google ha rimosso ModHeader dal Chrome Web Store il 10 luglio 2026 dopo aver ricevuto la segnalazione responsabile, impedendo nuove installazioni e aggiornamenti attraverso il canale ufficiale. La rimozione, tuttavia, non garantisce che ogni copia già presente venga disattivata immediatamente. Gli utenti devono verificare manualmente l’elenco delle estensioni installate e rimuovere ModHeader, mentre le aziende devono utilizzare gli strumenti di gestione centralizzata di Chrome per revocarla dai profili amministrati. È opportuno controllare il traffico verso stanfordstudies.com ed extensions-hub.com, analizzare eventuali richieste storiche e verificare la presenza dei database IndexedDB creati dall’estensione. Nei contesti più sensibili può essere necessario invalidare sessioni attive, riesaminare accessi anomali e valutare se i domini interni osservati abbiano aumentato l’esposizione dell’organizzazione. Il caso conferma un problema ricorrente della supply chain del browser: un’estensione può iniziare come progetto legittimo, cambiare proprietà, modello economico o codice e trasformarsi in un canale di raccolta dati senza richiedere una nuova installazione consapevole. Le aziende dovrebbero quindi limitare le estensioni ai soli strumenti indispensabili, bloccare installazioni non approvate e rivalutare ogni aggiornamento che introduca nuovi permessi o modifiche sostanziali. Anche Google deve affrontare il limite degli scanner automatici, che possono non riconoscere logica malevola minificata e integrata in componenti legittimi. La vicenda di ModHeader dimostra che la sicurezza di un’estensione non è una condizione permanente, ma un attributo che deve essere verificato continuamente durante l’intero ciclo di vita del software.