AdGuard sotto la lente: inietta 20.000 righe di JavaScript in ogni pagina Web

L’interesse verso i sistemi di filtraggio del traffico Web è cresciuto con la diffusione capillare di dispositivi mobili e con l’aumento delle minacce online. Un recente post pubblicato su LinkedIn da Andrew Morris, fondatore e chief architect di GreyNoise Intelligence, azienda specializzata nella sicurezza informatica (di recente abbiamo presentato il loro tool per la verifica degli indirizzi IP), ha stimolato una discussione sulla natura e sui rischi delle applicazioni di blocco pubblicità, in particolare AdGuard, sollevando questioni su come tali software operino a livello di sistema e quali implicazioni di sicurezza e privacy possano derivare dal loro funzionamento.

L’analisi si inserisce in un contesto in cui, secondo dati della sicurezza mobile, le soluzioni di ad blocking sono adottate da milioni di utenti globali su piattaforme iOS e Android per contrastare contenuti invasivi e migliorare prestazioni e risparmio dati.

Storicamente, gli ad blocker hanno fatto il loro ingresso nei browser desktop negli anni 2000 con estensioni come AdBlock Plus e uBlock Origin, evolvendosi verso soluzioni integrate o app dedicate per dispositivi mobili. Su iOS, l’architettura di Apple limita l’interazione diretta con il traffico di rete, con meccanismi come Content Blocking API (introdotta in iOS 9) che consente eventualmente di filtrare elementi DOM e risorse URL in Safari, senza alterare direttamente il DNS o inserire codice arbitrario.

L’iniezione di 20.000 righe di codice JavaScript

Un software come AdGuard non si limita a eliminare i riferimenti pubblicitari dai siti Web ma integra una routine che “ripara” il contenuto delle pagine Web, rimuovendo le zone bianche laddove dovrebbe comparire un banner.

Morris ha spiegato di aver effettuato il reverse engineering di AdGuard per iOS scoprendo che l’applicazione scarica 20.000 righe di codice JavaScript da remoto ogni 6 ore e le applica automaticamente su ogni singola pagina Web visitata.

Il codice in questione sembra sia utilizzato proprio per rimuovere gli spazi vuoti dalle pagine Web, laddove sarebbe dovuto apparire un banner pubblicitario. Morris, tuttavia, richiama l’attenzione sul fatto che ogni utente di AdGuard sta di fatto riponendo estrema fiducia nell’app e nei suoi sviluppatori.

Un codice JavaScript del genere può cambiare in qualunque momento, anche senza che l’app sia aggiornata, ed effettuare qualunque tipo di modifica sulla struttura (DOM) e sul contenuto di ogni singola pagina Web. L’esecuzione del codice, inoltre, avviene con gli stessi privilegi del sito Web visitato.

DNS, permessi e fraintendimenti comuni

Uno degli argomenti più frequenti a difesa di questi strumenti è l’assenza di permessi DNS a livello di sistema. L’idea è semplice: se l’app non controlla il DNS, non può intercettare o manipolare il traffico. Tecnicamente, questa è una falsa sicurezza.

La manipolazione descritta non avviene a livello di risoluzione dei nomi di dominio, ma dopo il caricamento della pagina, nel layer di esecuzione JavaScript. Anche senza toccare il DNS, un’app con accesso al contesto WebKit può osservare, modificare e riorganizzare il contenuto finale presentato all’utente.

Questo chiarisce un punto spesso trascurato: il controllo del rendering è, di fatto, più potente del controllo della rete, perché agisce sul risultato finale, non sul trasporto.

Codice open source, binari chiusi e il problema della verificabilità

Un altro elemento critico riguarda la trasparenza del codice. Morris racconta di aver scaricato il codice dell’app AdGuard per iOS da GitHub:

Non ha ricevuto commit per 4 mesi, il che suona strano per un’app con milioni di utenti. Approfondendo un po’, ho scoperto che la libreria che gestisce il DNS è in realtà closed source. Ho fatto un piccolo controllo di sicurezza sul binario compilato, ma non ho notato nulla di sospetto. Data la natura dell’app store, non so nemmeno se il codice su GitHub sia lo stesso compilato nell’app per iPhone.

La presenza di repository pubblici crea un senso di fiducia implicita. Tuttavia, come sottolinea Morris, il codice visibile può essere incompleto, non aggiornato o scollegato dal binario effettivamente distribuito tramite App Store.

L’utente non ha alcun modo di verificare che il binario installato sia una compilazione fedele del codice pubblico. Le reproducible build, pilastro della trasparenza in ambito security, sono semplicemente fuori portata nel caso di App Store. Il risultato, quindi, è una fiducia cieca nel processo di distribuzione.

Note finali

Morris si definisce apertamente un po’ paranoico, aggettivo che nell’ambito della sicurezza informatica non è un difetto. Anzi. La diffidenza metodica è spesso ciò che consente di individuare rischi prima che si manifestino in incidenti concreti.

Il punto centrale dell’analisi di Morris riguarda l’adozione, da parte di milioni di utenti in tutto il mondo, di un ad blocker che di fatto consegna il DOM di qualsiasi pagina Web a un soggetto terzo. Significa delegare a un intermediario esterno la possibilità di osservare, modificare e riorganizzare contenuti provenienti da qualunque dominio, inclusi servizi sensibili, portali aziendali e applicazioni Web complesse. Anche in assenza di intenzioni malevole, questa architettura introduce una concentrazione di fiducia estremamente elevata, spesso sottovalutata dall’utente finale.

Il ricercatore osserva che AdGuard ha sede a Cipro, quindi sotto l’influenza della regolamentazione europea. Sostiene tuttavia che molti sviluppatori hanno sede a Mosca, in Russia.

Nel settore della sicurezza informatica le competenze sono distribuite globalmente e la provenienza geografica, da sola, non determina l’affidabilità di un software. Tuttavia, in un’analisi del rischio, la giurisdizione operativa e il contesto normativo diventano variabili legittime quando si combinano con altri fattori, come l’esecuzione di codice remoto non verificabile e l’impossibilità di auditing indipendente.