Google: primo zero-day AI in the wild, bypass 2FA attivo

Google conferma il primo zero-day generato da AI in the wild: bypass del 2FA su un tool admin open-source. La corsa alle vulnerabilità LLM è già iniziata.

Contenuto

Google: primo zero-day AI in the wild, bypass 2FA attivo
Google: primo zero-day AI in the wild, bypass 2FA attivo

L'11 maggio il Google Threat Intelligence Group ha reso pubblico il primo caso documentato di un attore di minaccia che ha impiegato un modello AI per scoprire e weaponizzare uno zero-day in ambiente reale. L'exploit, implementato in uno script Python, bypassa l'autenticazione a due fattori su un diffuso tool open-source di amministrazione web sfruttando un difetto logico semantico. La conferma ufficiale con "high confidence" da parte di un vendor primario come Google sposta il dibattito dall'allarmismo teorico a una minaccia misurabile, interrotta a un passo dalla mass exploitation.

Punti chiave
  • Il bypass del 2FA non si basa su un errore di memoria o di input sanitization, ma su una trust assumption hard-coded che i ricercatori GTIG hanno definito un flaw logico semantico di alto livello; l'attacco richiede credenziali utente valide.
  • L'analisi forense dello script Python ha rilevato abbondanti docstring educative, un punteggio CVSS allucinato e una struttura "textbook Pythonic" con classi ANSI colorate, elementi considerati altamente caratteristici dei training data dei LLM.
  • Google esclude con certezza l'uso di Gemini, ma non ha identificato il modello specifico; la valutazione "high confidence" si fonda sugli artefatti del codice e sulla natura del ragionamento necessario per individuare la vulnerabilità.
  • L'operazione, qualificata come campagna di mass exploitation, è stata disarticolata prima che lo zero-day potesse essere sfruttato su larga scala grazie a una responsible disclosure condotta in collaborazione con il vendor del software.

Il bypass del 2FA nasce da una trust assumption hard-coded

Secondo GTIG, l'exploit non sfrutta una vulnerabilità di tipo memory corruption o un difetto di input sanitization, bensì una falla logica semantica. L'attaccante, in possesso di credenziali valide, manipola la logica di autorizzazione del tool amministrativo sfruttando una trust assumption hard-coded.

I ricercatori hanno osservato che i LLM frontier, pur incontrando difficoltà con logiche enterprise complesse, stanno sviluppando una crescente capacità di reasoning contestuale. Nella loro analisi, GTIG evidenzia che questi modelli riescono a interpretare l'intento originale dello sviluppatore e a mettere in relazione la logica di enforcement del 2FA con le contraddizioni delle sue eccezioni hard-coded. In pratica, l'IA ha individuato una coerenza interna del codice che gli esseri umani avevano dato per scontata.

Il codice Python rivela impronte inequivocabili di un LLM

L'artefatto analizzato è uno script Python che implementa lo zero-day. GTIG ha evidenziato caratteristiche stilistiche che difficilmente trovano riscontro in codice scritto manualmente da un threat actor tradizionale. Il file contiene "an abundance of educational docstrings", un punteggio CVSS allucinato e una formattazione strutturata definita "textbook Pythonic".

Tra i dettagli citati, menu di aiuto dettagliati e una classe _C per i colori ANSI pulita e ordinata. Questi elementi non influenzano la funzionalità dell'exploit, ma costituiscono la firma di un testo generato attingendo a dataset di addestramento tipici dei large language model. La presenza di un CVSS inventato conferma inoltre che il modello ha prodotto contenuto statisticamente plausibile ma tecnicamente inesatto.

High confidence senza nome del modello: come Google ha attribuito l'AI

Google Threat Intelligence Group ha formulato una valutazione di "high confidence" sull'impiego di un modello AI nella fase di discovery e weaponization. Al contempo, l'analisi esclude categoricamente il coinvolgimento di Gemini. Il modello LLM specifico resta ignoto: non è stato possibile risalire all'engine utilizzato né quantificare il grado di supervisione umana nel processo.

L'attribuzione si fonda sulla convergenza tra la natura del flaw scoperto — che richiede reasoning contestuale su logiche di autorizzazione — e gli artefatti stilistici rilevati nel codice. La combinazione di queste prove ha permesso a GTIG di tracciare una linea diretta tra l'output di un LLM e un artefatto dannoso trovato in the wild, superando il livello di semplice ipotesi.

Interrotta la campagna prima della mass exploitation

L'operazione è stata identificata e neutralizzata prima che potesse scalare in una mass exploitation. Google ha collaborato con il vendor del tool open-source, il cui nome non è stato reso pubblico, per chiudere la vulnerabilità e disarticolare la campagna. Non è noto se l'exploit sia stato impiegato attivamente contro obiettivi specifici prima dell'intervento, né quanti attori fossero coinvolti nella rete criminale.

La responsible disclosure ha funzionato come argine, ma il caso dimostra che il tempo tra la scoperta di un flaw logico e la sua weaponizzazione si è compresso drasticamente grazie all'ausilio dell'intelligenza artificiale.

"There’s a misconception that the AI vulnerability race is imminent. The reality is that it’s already begun. For every zero-day we can trace back to AI, there are probably many more out there" — John Hultquist, chief analyst at GTIG

Cosa fare adesso

Verificare le eccezioni hard-coded. Auditare la logica di autorizzazione e le trust assumption statiche nei tool di amministrazione web-based, in particolare dove il 2FA presenta eccezioni o bypass condizionali.

Rivedere le assumption sul 2FA. Il meccanismo a due fattori resta valido, ma va affiancato a controlli comportamentali e monitoring post-autenticazione, dato che l'exploit agisce dopo l'accesso iniziale con credenziali valide.

Rinforzare il disclosure. Stabilire canali diretti con vendor di sicurezza e programmi di responsible disclosure per ridurre la finestra di esposizione, considerando che gli LLM accelerano i tempi tra discovery e weaponization.

Analizzare il codice interno con AI. Usare gli stessi strumenti di reasoning contestuale per individuare contraddizioni logiche nei propri software prima che lo facciano attori di minaccia.

La documentazione forense di Google demolisce la distinzione tra proof-of-concept accademico e weaponization criminale. I LLM frontier non stanno più solo accelerando la scrittura di payload, ma stanno ragionando su logiche di autorizzazione complesse per trovare contraddizioni sfruttabili. Per le aziende, questo significa che la prossima vulnerabilità critica potrebbe non arrivare da un fuzzer o da un reverse engineer umano, bensì da un modello che ha analizzato il codice con una pazienza e una coerenza difficili da replicare manualmente.

Domande frequenti

Perché questo zero-day è considerato diverso da un comune script generato da AI?

Perché l'attribuzione di Google si riferisce non solo alla generazione del codice, ma alla scoperta e alla weaponizzazione di un flaw logico semantico: un LLM ha individuato una trust assumption hard-coded e ha costruito un exploit funzionante attorno a essa.

Se l'exploit richiede credenziali valide, quanto è pericoloso in pratica?

È altamente pericoloso per i tool di system administration, dove l'accesso iniziale può essere ottenuto tramite phishing o password reuse; il bypass del 2FA permette di elevare il controllo senza il secondo fattore di sicurezza.

Che ruolo ha avuto l'intervento umano nella creazione dell'exploit?

Il grado di supervisione umana nel processo di discovery e weaponization non è quantificato; GTIG ha confermato l'uso di AI, ma non ha stabilito se l'operatore abbia guidato il modello, corretto l'output o agito in autonomia.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

Link utili

Apri l'articolo su DeafNews