Mettere al sicuro le applicazioni grazie agli LLM: come abbiamo trovato 13 vulnerabilità in microG

Ora che abbiamo fornito il contesto, dobbiamo specificare come vogliamo che l'agente operi e come deve verificare di aver svolto correttamente il lavoro. Questo è il prompt utilizzato:

[...] For each vulnerability you think you have a found, you'll write a report and a POC that can be (1) a minimal app mimicking the behavior of a malicious app or (2) an instrumented test runnable on an Android device or emulator. 
The minimal POC app must be compilable and runnable standalone - using official Google Play client libraries whenever possible - and have an activity with a button to trigger the vulnerability and display the result (e.g. the exfiltrated data) to the screen.

In questo caso abbiamo istruito l’agente per creare subito una Proof-of-Concept (PoC) delle vulnerabilità trovate, in modo da poterle facilmente validare su un dispositivo reale e cercare di ridurre falsi positivi e allucinazioni.

I limiti del metodo

Questa strategia, però, non si è rivelata così efficace come sperato, soprattutto perché nel nostro contesto l'agente non poteva verificare da solo il corretto funzionamento di una PoC e correggere il tiro di conseguenza: queste infatti richiedevano l'interazione dell'utente, stampavano i risultati a schermo e dovevano essere installate su un hardware reale con microG già configurato. Questo ha fatto sì che l'agente, in alcuni casi, producesse delle PoC non funzionanti o sovrastimasse l'impatto della vulnerabilità. Spesso bastava riportare all'agente l'errore ottenuto durante l'esecuzione della PoC affinché la correggesse, un passaggio evitabile se avesse potuto eseguirla autonomamente e accedere all'output.

Un altro rischio che rende la creazione di PoC un'arma a doppio taglio è quello di "auto-censura": se l’agente ritiene poco probabile che una vulnerabilità possa essere dimostrabile con una PoC, potrebbe escluderla dai risultati. Con microG, in un caso è successo che l'LLM avesse deciso di escludere un potenziale candidato proprio per questo motivo. Tuttavia, una volta spinto ad approfondire ulteriormente la questione, ha rivisto la sua decisione ed è stato in grado di produrre una PoC della vulnerabilità, la cui gravità era peraltro elevata (GHSA-qqqw-h762-w2hw).

Proprio per evitare queste situazioni, Anthropic suggerisce, in un eccellente articolo dedicato a questo tema che purtroppo abbiamo scoperto soltanto dopo l'esperimento, di utilizzare un agente separato per verificare ciò che è stato scoperto nella fase di scansione. L'obiettivo di quest'ultima diventa quindi quello di trovare il maggior numero di possibili vulnerabilità, che verranno confermate o smentite nella successiva fase di verifica. 
Un altro punto, a nostro avviso fondamentale, riportato dall'articolo in questione è:

"failure to produce a working PoC is not proof of a false positive" 

Dove l'LLM non riesce o non può arrivare, entra in gioco la competenza umana.

Risultati e osservazioni

Grazie agli LLM siamo riusciti a trovare le seguenti 13 vulnerabilità in microG, che abbiamo segnalato al responsabile del progetto e che sono state corrette nelle versioni 0.3.17 e 0.3.16.1.

È interessante notare come molte di esse nascano da piccole sviste o mancati controlli sui parametri ricevuti dalle altre app (i cosiddetti “untrusted input”). Nel contesto di un'app di sistema con accesso ai dati dell'utente, vulnerabilità di questo tipo possono avere ripercussioni non da poco.

Va detto che oltre alle vulnerabilità sopra elencate, gli LLM hanno riportato una gran quantità di falsi positivi, che si è attestata intorno al 40% con entrambi i modelli utilizzati (Opus 4.8 e Grok 4.6). 
La mancanza di un threat model approfondito è sicuramente il principale responsabile, perché buona parte dei falsi positivi erano in realtà comportamenti voluti che, visti in un contesto diverso, sarebbero potuti apparire come "non sicuri". In altri casi si è trattato di bug in aree di codice sensibili (es. autenticazione) che però non avevano impatti sulla sicurezza dell'applicazione. 
Un esempio evidente di falso positivo riscontrato in microG riguarda un’API la cui presunta vulnerabilità sarebbe quella di consentire a un’app di revocare token di autenticazione appartenenti ad altre app: come può un’applicazione essere in possesso di un token di un’altra app? Se dovesse realmente capitare, si tratterebbe un grave problema di sicurezza dell'app a cui appartiene il token, di cui microG non può farsi carico.

Le allucinazioni, sebbene più rare, non sono mancate: c’è stato un caso in cui il report e una PoC di una presunta vulnerabilità erano completamente basati su un'errata deduzione del comportamento di un’API di Android. 
Fare più scansioni con LLM di famiglie diverse può mitigare questo problema e, dal momento che il loro output è probabilistico e fortemente dipendente dal dataset su cui sono stati allenati, è possibile che due modelli che lavorano su una stessa parte della codebase trovino vulnerabilità differenti. 
Un caso esemplare che si è verificato durante l'esperimento riguarda le vulnerabilità GHSA-29m7-f2vx-8cqq e GHSA-frxh-v6rf-xfg4 che avevano entrambe origine nella stessa funzione del servizio di geolocalizzazione di microG. Opus 4.8 ha trovato solo la prima, causata dall’assenza di un controllo di autorizzazione (riga 36), e ha dato per scontato che l'altra porzione di codice fosse sicura, dove il controllo era presente ma implementato in una maniera vulnerabile (riga 30). Grok 4.6, invece, ha notato il controllo vulnerabile ma non è stato in grado di determinare che l’assenza del controllo poteva essere sfruttata per ottenere la posizione dell’utente senza disporre dei permessi necessari.

Un altro punto a cui fare attenzione è la dimensione della codebase da scansionare. 
Quando un agente si trova di fronte una codebase molto ampia con tanti moduli come quella di microG, si trova costretto a decidere autonomamente su quali aree concentrarsi, a volte basandosi su criteri arbitrari come i nomi dei moduli o delle classi che appaiono più "sensibili" (per es. quelli riguardanti autorizzazione, autenticazione, crittografia). 
Costringendolo invece a focalizzarsi su un singolo modulo o su alcuni piccoli per volta, è più facile per un modello trovare vulnerabilità più complesse, avendo più spazio nella finestra di contesto da usare per "ragionare" su più file dello stesso modulo.

Un chiarimento importante riguarda le restrizioni di sicurezza degli LLM: anche se le proof-of-concept delle vulnerabilità presentano un duplice utilizzo (possono infatti essere usate da attori malevoli per produrre malware), la loro implementazione è consentita in ambiti difensivi come le analisi di sicurezza. Si tratta, del resto, di una pratica raccomandata dalla stessa Anthropic. 
Quelle rare volte in cui i blocchi di sicurezza sono entrati in azione è stato quando, nel far correggere delle PoC non funzionanti, si usava un linguaggio troppo esplicito (es. "data is not getting leaked"); riformulare la richiesta in una chat separata era sufficiente per non mandare più in allarme il modello. 
Al momento della stesura di questo articolo, gli unici modelli proprietari non utilizzabili liberamente per questo tipo di attività sono quelli di OpenAI, per i quali è necessario richiedere l'accesso verificato al programma Daybreak.

Conclusioni

Il nostro esperimento è partito senza un threat model, con un prompt relativamente semplice, eppure ha portato alla luce 13 vulnerabilità, tre delle quali di gravità alta, in un progetto open-source maturo su cui si basano diversi sistemi Android "de-Googled".  
Non è un problema di microG, ma una condizione comune a quasi tutto il software: i progetti crescono, si stratificano, passano ad altre persone, e gli aspetti relativi alla sicurezza finiscono per essere trascurati in favore di altre priorità. La differenza oggi è che i modelli IA consentono di eseguire analisi di sicurezza a costi e tempi impensabili fino a pochi anni fa, dando la possibilità di intervenire prima che i problemi diventino incidenti.

I limiti che abbiamo riscontrato indicano anche dove si può fare molto meglio. Per esempio, con un threat model che fornisca le informazioni di contesto necessarie per ridurre i falsi positivi; un harness che permetta agli agenti di eseguire e verificare le PoC in autonomia; una fase di verifica strutturata delle vulnerabilità trovate, separata dalla scansione. 
E, a valle di tutto, degli esperti in grado di valutare la qualità dei risultati, applicare al software le correzioni necessarie e affinare il processo di conseguenza.

In Claranet stiamo esplorando questo approccio insieme ai nostri clienti, affiancando agli agenti AI l'esperienza dei nostri team di sviluppo e sicurezza. Se un esperimento con mezzi semplici ha prodotto dei risultati concreti, un processo costruito attorno al tuo prodotto può darti una visione molto più completa e affidabile della sua sicurezza. Vorresti capire come applicarlo al tuo software? Contattaci: possiamo partire insieme da un primo confronto.