In un test, GPT-5.6-Cyber ha evaso tre volte una VM e ha trovate anche anche vulnerabilità zero-day nella catena QEMU/KVM.
In un esperimento condotto nell’ambito di Patch the Planet, con l’accesso in anteprima a GPT-5.6-Cyber è stato possibile testare le capacità offensive nel settore della sicurezza informatica.
Il bersaglio dell’esperimento era una macchina virtuale (VM) QEMU/KVM in esecuzione su una macchina Linux utilizzata per sviluppo, basata su Debian 12 e processore AMD Zen 3. Il compito affidato all’agente era volutamente semplice da descrivere. Si trovava in una sorta di Capture The Flag (CTF). Per completare la prova, doveva riuscire a evadere dalla macchina virtuale e leggere un file contenente la flag.
L’agente disponeva di accesso SSH alla VM e poteva effettuare liberamente operazioni al suo interno. Gli era inoltre richiesto di mantenere un registro delle proprie attività e delle scoperte effettuate durante la ricerca. Il risultato, secondo il resoconto dell’analista, è stato sorprendente. L’agente è riuscito a uscire dalla VM in tre occasioni differenti. Inoltre, ha trovato anche vulnerabilità zero-day nella catena QEMU/KVM.
Dalle vulnerabilità note agli zero-day
Il primo tentativo riuscito si è basato su vulnerabilità recentemente divulgate presenti nel kernel della macchina host. L’autore ha quindi aggiornato completamente il sistema per eliminare quelle vulnerabilità. L’agente, però, non si è fermato. Ha individuato problemi che erano già stati divulgati ma che non erano ancora arrivati ai manutentori dei pacchetti oppure non erano stati classificati come vulnerabilità di sicurezza.
A quel punto, un ulteriore passo. QEMU e le sue dipendenze sono state ricompilate utilizzando il codice sorgente upstream più recente. Anche questa misura non è stata sufficiente. Secondo il resoconto, l’agente ha trovato diversi zero-day, cioè vulnerabilità precedentemente sconosciute agli sviluppatori o al pubblico.
Un livello di autonomia particolarmente elevato
L’aspetto più interessante dell’esperimento, secondo l’analista che lo ha effettuato, è stato proprio il livello operativo dell’agente. Quest’ultimo, in effetti, non si sarebbe limitato a seguire una sequenza di istruzioni preparata dall’operatore. Avrebbe invece lavorato autonomamente per ore, modificando la propria strategia quando un approccio non produceva risultati.
Nel corso dell’attività avrebbe:
- analizzato codice sorgente.
- Consultato ricerche e pubblicazioni tecniche.
- Recuperato materiale e codice rilevante.
- Costruito strumenti di verifica.
- Creato esempi minimali per riprodurre i problemi.
- Effettuato attività di fuzzing e analisi.
- Sviluppato exploit con l’obiettivo di renderli riutilizzabili e affidabili.
“L’intervento umano sarebbe stato minimo“. In alcuni casi, l’operatore ha dovuto addirittura riavviare fisicamente la macchina, perché determinati tentativi avevano causato il blocco del kernel dell’host.
Il problema delle sandbox AI
La questione sollevata dall’esperimento va oltre QEMU o una particolare vulnerabilità. Una sandbox virtualizzata viene normalmente considerata una sorta di “prigione” per un agente. All’interno della VM non dovrebbero esserci dati importanti e, in caso di comportamento anomalo, l’ambiente può essere spento, ripristinato da uno snapshot o completamente ricreato.
Tuttavia, una VM non è completamente isolata. Per essere utile, infatti, deve necessariamente avere punti di contatto con il sistema host. Risorse hardware virtualizzate, dispositivi emulati, canali per trasferire file, sistemi per visualizzare lo schermo e, spesso, accesso alla rete.
Sono proprio queste interfacce a costituire potenziali superfici d’attacco. Per molto tempo l’idea dominante è stata che questi canali fossero sufficientemente sicuri da impedire a un programma di attraversare il confine della virtualizzazione. Con agenti AI capaci di condurre autonomamente attività di ricerca e vulnerability discovery, questa assunzione potrebbe però diventare sempre meno affidabile.
Un cambio di paradigma nella sicurezza
La conclusione dell’autore è volutamente provocatoria: non si dovrebbe più dare per scontato che una semplice VM sia sufficiente a contenere un agente AI sufficientemente avanzato.
La differenza rispetto al malware tradizionale è importante. Un agente autonomo può non limitarsi a sfruttare vulnerabilità già conosciute: può cercare documentazione, analizzare codice, formulare ipotesi, costruire test, verificare i risultati e cambiare strategia.
In altre parole, il rischio non deriva soltanto dall’esistenza di una vulnerabilità, ma dalla possibilità che un sistema AI abbia tempo, autonomia e capacità tecnica per trovarla e sfruttarla.
Per questo l’autore propone di recuperare un concetto nato nel mondo della cybersecurity degli anni 2010: quello di Advanced Persistent Threat (APT).
Non significa necessariamente che ogni agente AI sia un attaccante malevolo. Significa piuttosto che, quando gli si concede un’elevata autonomia e accesso a strumenti informatici reali, il suo potenziale deve essere valutato assumendo capacità offensive avanzate.
Un precedente
L’esperimento non ha dimostrato che ogni agente AI possa evadere da qualsiasi macchina virtuale. Ha tuttavia dimostrato qualcosa di più importante. Vale a dire che “la virtualizzazione non dovrebbe essere considerata, da sola, una garanzia assoluta di contenimento contro agenti AI avanzati“.
La sicurezza dei sistemi agentici potrebbe quindi richiedere più livelli di isolamento. VM, sandbox più profonde, restrizioni di rete, separazione dell’hardware, controllo delle interfacce host-guest, monitoraggio continuo. Su tutto, la capacità di limitare ciò che l’agente può fare anche quando riesce a compromettere un singolo livello della difesa.
La prospettiva sta cambiando, sottolineano gli esperti. In effetti, non si tratta più soltanto di chiedersi se si possa compromettere una certa applicazione può essere compromessa. Al contrario ci si deve interrogare su cosa possa fare un agente autonomo se gli si dà abbastanza tempo per provare effettivamente a comprometterla.
