Un ricercatore smonta l'app della Casa Bianca e trova problemi inquietanti

Un’app ufficiale della Casa Bianca (White House App) dovrebbe trasmettere affidabilità anche dal punto di vista tecnico. È per questo che un’analisi indipendente sta attirando in questi giorni un’attenzione spasmodica nella comunità della sicurezza e non solo. Non siamo dinanzi alla scoperta di una vulnerabilità critica ma di una disamina dettagliata dell’architettura software di un’app governativa distribuita pubblicamente sugli store mobili.

L’autore dell’operazione ha analizzato il pacchetto dell’app Android estraendone file e componenti interni, tra cui il codice JavaScript utilizzato dall’applicazione, le impostazioni di Expo – la piattaforma impiegata per lo sviluppo e la gestione dell’app – e gli endpoint API, ovvero gli indirizzi attraverso cui l’app comunica con i server remoti. L’analisi ha evidenziato come sia possibile ottenere informazioni “delicate” anche senza ricorrere a tecniche avanzate.

Il tema non riguarda solo la White House App: da anni le applicazioni mobili governative adottano framework cross-platform per accelerare sviluppo e manutenzione. React Native, Flutter ed Expo riducono tempi e costi; allo stesso tempo aumentano la superficie applicativa, soprattutto quando backend articolati, librerie terze parti e codice JavaScript compilato convivono nello stesso stack. Il punto è che molte Pubbliche Amministrazioni continuano a ragionare in termini di funzionalità e comunicazione, mentre gli specialisti di sicurezza osservano soprattutto telemetria, dipendenze, runtime dinamici e supply chain.

Cos’è ADB e perché permette di estrarre un pacchetto APK

ADB, acronimo di Android Debug Bridge, è un componente ufficiale dell’Android SDK sviluppato da Google. Serve principalmente a sviluppatori e tester per interagire con dispositivi Android tramite USB o rete TCP/IP.

Permette di installare o rimuovere applicazioni; accedere alla shell del dispositivo; leggere log di sistema; copiare file; eseguire comandi amministrativi; effettuare debugging applicativo. Nel caso descritto, il ricercatore ha installato la White House App su un emulatore o su dispositivo reale e poi ha utilizzato comandi simili a:

adb shell pm list packages

per identificare il package name dell’applicazione, seguito da:

adb shell pm path gov.whitehouse.app

per recuperare il percorso dell’APK installato.

A quel punto basta utilizzare adb pull /data/app/.../base.apk per copiare localmente il pacchetto installato e iniziare ad elaborarlo.

APK: cosa contiene realmente un’app Android

Un file APK è sostanzialmente un archivio ZIP strutturato. Rinominandolo in .zip è possibile esplorarne parte del contenuto anche senza strumenti specializzati.

All’interno di un APK tipico troviamo numerose risorse. Nel caso delle applicazioni React Native moderne entra in gioco anche il bundle JavaScript: la White House App utilizza il motore Hermes, sviluppato da Meta per ottimizzare prestazioni e consumo memoria. Il codice JavaScript non è quindi distribuito nella forma di sorgente classica, ma come bytecode Hermes compilato. “Compilato” non significa invisibile: molte informazioni restano comunque recuperabili.

Il ricercatore ha quindi spiegato di aver usato JADX, uno dei decompiler Android più utilizzati nella ricerca sicurezza. Il suo obiettivo consiste nel convertire bytecode Dalvik o ART (Android Runtime) in codice Java leggibile.

Il risultato non coincide quasi mai con il codice sorgente originale: come ben sa chi conosce questi strumenti software, commenti, nomi delle variabili e parte della struttura vengono persi durante le fasi di compilazione e ottimizzazione. Però per un ricercatore basta spesso molto meno.

Endpoint API hardcoded, token dimenticati, URL amministrativi, configurazioni Firebase, riferimenti AWS, chiavi analytics o feature flag emergono frequentemente già da una prima scansione.

Nel caso della White House App, JADX ha aiutato a identificare componenti React Native, plugin Expo, configurazioni relative ai permessi Android e riferimenti a backend WordPress REST API. La lezione importante per chi sviluppa software, soprattutto a livello istituzionale è la seguente: tutto ciò che finisce lato client deve essere considerato potenzialmente pubblico. Vero Commissione Europea? Coff…, coff…

Il browser interno che nasconde banner, login wall e paywall

Entrando nel merito dell’analisi, gli elementi anomali non sono il ricorso a React Native, Expo o Hermes: sono componenti comuni nello sviluppo mobile moderno. A destare perplessità è ciò che il ricercatore sostiene di aver trovato nel pacchetto dell’app: codice per manipolare le pagine aperte nel browser interno, infrastruttura di tracciamento geografico, dipendenze caricate da servizi terzi e residui delle attività di sviluppo finiti nella build di produzione.

Uno dei passaggi più controversi riguarda WebView, il componente che permette all’app di aprire pagine Web in modo diretto. Secondo l’analisi indipendente, ogni volta che una pagina è caricata nella WebView, l’app inietta codice JavaScript.

Il codice individuato crea dinamicamente un elemento style e vi inserisce all’interno una serie di selettori CSS pensati per nascondere elementi riconoscibili dai nomi delle classi o degli ID. I bersagli sono piuttosto espliciti: cookie banner, finestre di consenso, riferimenti GDPR, privacy banner, componenti OneTrust, login wall, signup wall  e persino elementi associati a paywall.

Il CSS forza questi elementi a display: none e visibility: hidden; poi imposta il body della pagina su overflow: auto, così da riattivare lo scroll quando un banner di consenso blocca la pagina sottostante. Non finisce qui: lo script crea anche un MutationObserver, cioè un osservatore del DOM (contenuto delle pagine Web) che intercetta nuovi elementi aggiunti dinamicamente alla pagina e prova a nasconderli appena compaiono.

In pratica l’app non si limita ad aprire un sito esterno. Modifica il modo in cui quel sito viene mostrato all’utente dentro il browser integrato. Va detto però che l’analisi statica non dimostra da sola quali siti siano effettivamente aperti dagli utenti e in quali condizioni lo script risulti invocato.

La geolocalizzazione: non attiva per forza, ma già pronta

Un altro punto importante riguarda la posizione dell’utente. Nel file di configurazione Expo compaiono plugin chiamati withNoLocation e withStripPermissions, nomi che suggeriscono un tentativo di eliminare o ridurre i permessi di localizzazione dalla build finale.

L’analisi non dice che l’app tracci automaticamente tutti gli utenti appena installata: sostiene che l’app dispone dell’infrastruttura tecnica per farlo, compilata nel pacchetto APK.

Nel codice di OneSignal emergono costanti relative ai permessi Android ACCESS_FINE_LOCATION, ACCESS_COARSE_LOCATION e ACCESS_BACKGROUND_LOCATION. Compaiono anche i riferimenti agli intervalli di aggiornamento: 270.000 millisecondi in foreground, cioè circa 4,5 minuti; 570.000 millisecondi in background, circa 9,5 minuti.

I dati raccolti, sempre secondo il ricercatore, includono latitudine, longitudine, accuratezza, timestamp, indicazione foreground o background e tipo di posizione, accurata o approssimativa. L’informazione finisce poi nel modello di proprietà di OneSignal, destinato alla sincronizzazione con l’API del servizio.

Il punto critico non è quindi “l’app spia tutti“: sarebbe una forzatura. Il fatto è che un’app istituzionale, stando all’analisi, include già l’intera catena tecnica necessaria per raccogliere e inviare la posizione degli utenti a un fornitore terzo, anche se l’attivazione richiede condizioni ulteriori. Il plugin che avrebbe dovuto eliminare la geolocalizzazione, almeno secondo quanto osservato, non ha rimosso il codice nativo del relativo SDK.

JavaScript caricato da GitHub Pages per i video YouTube

Uno dei dettagli più sorprendenti riguarda l’integrazione dei video YouTube: l’app usa la libreria react-native-youtube-iframe che carica il player HTML da un indirizzo ospitato su GitHub Pages, non certo un supporto “ufficiale”.

Il problema non è la libreria in sé; il problema è il modello di fiducia. Se un’app governativa carica HTML e JavaScript da una pagina personale ospitata su GitHub Pages, la sicurezza di quella porzione dell’app dipende anche dall’account GitHub del manutentore, dalle impostazioni del repository, dalle credenziali usate per pubblicare il contenuto e dall’intera catena GitHub Pages.

Se quell’account venisse compromesso, chi ne prendesse il controllo potrebbe teoricamente servire codice modificato a tutte le istanze dell’app mobile che caricano quella risorsa.

Per un’app istituzionale, una dipendenza del genere appare quantomeno discutibile. Non perché ogni GitHub Pages sia insicuro per definizione, ma perché il livello di controllo richiesto da una piattaforma governativa dovrebbe essere nettamente più alto.

Widget social e servizi esterni non governativi

L’analisi segnala anche il caricamento di JavaScript da Elfsight, piattaforma commerciale usata per incorporare feed social e widget.

Anche qui la questione è di supply chain: e in un periodo in cui gli attacchi alla catena di fornitura crescono a dismisura, prendere sotto gamba questo tema può essere un errore imperdonabile.

Un widget esterno può cambiare comportamento nel tempo, raccogliere telemetria, introdurre nuove dipendenze o modificare codice senza che l’app sia aggiornata sugli store. È una comodità enorme per chi gestisce contenuti social; è anche un rischio non trascurabile quando il contenitore è un’app governativa ufficiale.

Lo stesso discorso vale per altri servizi individuati: Mailchimp per iscrizioni email, Uploadcare per le immagini, Facebook page plugin e oggetti in embedding collegati a Truth Social.

Il quadro complessivo racconta un’app pubblica che dipende da molte infrastrutture non governative per contenuti, tracking, immagini, moduli e componenti social.

Assenza di certificate pinning

Secondo l’autore, l’app non implementa certificate pinning personalizzato e si affida al TrustManager standard di Android. Significa che la validazione TLS segue le autorità di certificazione considerate affidabili dal sistema operativo.

In condizioni normali è un comportamento comune: moltissime app funzionano così. Tuttavia il certificate pinning può ridurre il rischio di intercettazione in scenari specifici, per esempio reti aziendali con CA installate, proxy aggressivi o dispositivi compromessi.

Va evitato l’allarmismo: l’assenza di pinning non significa automaticamente traffico in chiaro: le connessioni HTTPS restano cifrate e validate. Però per un’app governativa, soprattutto se integra notifiche, WebView, servizi esterni e identificativi utente, la scelta merita almeno una valutazione tecnica più severa.

Artefatti di sviluppo nella build finale e altri problemi rilevanti

La parte forse più imbarazzante riguarda gli artefatti di sviluppo finiti nella build di produzione. L’analisi cita un URL localhost verso una rotta WordPress, un IP locale 10.4.4.109 nelle risorse, componenti Expo dev client e dev menu compilati nella release, oltre a una Compose PreviewActivity esportata nel file manifest.

Il ricercatore elenca oltre 68 librerie integrate nell’app della Casa Bianca: molti prodotti commerciali superano abbondantemente questi numeri. Ma nel caso di un’app governativa il conteggio delle dipendenze non è un dettaglio insignificante. Ogni libreria introduce codice, aggiornamenti, vulnerabilità potenziali, licenze, manutentori, dipendenze acquisite di riflesso e superfici di attacco.

La White House App, almeno secondo questa analisi, non appare come un client istituzionale minimale. Sembra piuttosto un’app editoriale e promozionale costruita con un insieme molto ampio di strumenti commerciali, framework mobile, SDK di engagement, WebView, librerie multimediali e servizi terzi.

Perché tutto questo è davvero inquietante e cosa accadrebbe in Europa

La conclusione più equilibrata è anche la più scomoda: l’analisi non dimostra una compromissione, non prova l’esistenza di una backdoor segreta e non consente di dire che possa esserci un pericolo per gli utenti. Però mostra qualcosa che, per un’app ufficiale governativa, dovrebbe bastare a generare domande serie.

L’app modifica pagine terze nella WebView per nascondere banner e “barriere”; contiene un apparato di localizzazione compilato e potenzialmente attivabile; carica codice da GitHub Pages e da piattaforme widget esterne; usa servizi non governativi per email, immagini e social embed; non implementa pinning certificati; porta in produzione artefatti di sviluppo; integra molte librerie e capacità non immediatamente riconducibili alla sola funzione per cui l’app risulta concepita.

In Europa una situazione simile sarebbe letta prima di tutto attraverso il principio di minimizzazione: una Pubblica Amministrazione deve raccogliere e trattare solo i dati davvero necessari alla finalità dichiarata. Non “tutto ciò che può essere utile“, non “tutto ciò che l’SDK rende disponibile“, ma solo ciò che serve in modo proporzionato, documentabile e verificabile.

Il principio di minimizzazione nelle app della Pubblica Amministrazione

Il GDPR prescrive che ogni trattamento debba avere una base giuridica chiara, una finalità esplicita, tempi di conservazione definiti, informative comprensibili e misure tecniche adeguate.

Per le app governative italiane ed europee il tema è ancora più delicato. Strumenti come app statali, app sanitarie, portali comunali, servizi di protezione civile o piattaforme ministeriali non sono semplici prodotti digitali: rappresentano un’interfaccia diretta tra cittadino e Stato.

In Italia esistono già riferimenti utili: linee guida AgID sul riuso e sull’acquisizione del software, Codice dell’amministrazione digitale, indicazioni del Garante Privacy, regole europee su sicurezza e protezione dei dati. Ma la pratica resta spesso disomogenea. Alcune piattaforme pubbliche hanno standard elevati; altre sembrano ancora prodotti realizzati in fretta, con librerie accumulate, informative generiche e poca chiarezza su cosa accada davvero lato dispositivo.

La lezione della White House App, quindi, riguarda anche noi. Un’app governativa deve poter essere spiegata, verificata e difesa pubblicamente. Deve mostrare perché raccoglie un dato, perché usa un fornitore, perché integra un SDK, perché apre una WebView, perché richiede un permesso. Se queste risposte non sono immediate, il problema non è solo tecnico: è di fiducia istituzionale.

Come chiosa finale: l’articolo 5 del GDPR parla chiaramente di “minimizzazione dei dati” ma non limita al principio alla sola Pubblica Amministrazione. Un’app, di qualunque fornitore, dovrebbe raccogliere solo ciò che serve davvero per mettere a disposizione il servizio dichiarato.

Si possono raccogliere dati per finalità commerciali e di marketing, ma entro limiti molto precisi. Il GDPR impone condizioni rigorose su trasparenza, proporzionalità e consenso. Se un’app raccoglie dati per inviare newsletter, personalizzare contenuti, misurare engagement o fare advertising, deve dirlo chiaramente all’utente e deve avere una base giuridica valida. Nella maggior parte dei casi, per profilazione e marketing personalizzato serve un consenso libero, specifico e revocabile.