Un exploit su Grok aggira i filtri finanziari tramite il codice Morse

In una sofisticata dimostrazione delle vulnerabilità intrinseche dell'intelligenza artificiale "agentica", un utente sulla piattaforma X ha manipolato con successo il chatbot Grok per eseguire una serie di transazioni non autorizzate in criptovaluta per un valore complessivo di circa 200.000 dollari. L'incidente, incentrato sull'uso del codice Morse per aggirare i normali filtri di sicurezza, evidenzia una falla architettonica critica nel modo in cui i grandi modelli linguistici (LLM) interagiscono con i protocolli finanziari esterni e i sistemi di trading automatizzato.

L'exploit non è stato una semplice questione di chiedere denaro al bot. Ha comportato, piuttosto, una manovra tecnica a più stadi che ha preso di mira il livello di integrazione tra Grok e un bot di trading automatizzato di terze parti noto come Bankrbot. Combinando ingegneria sociale, elevazione dei privilegi tramite token non fungibili (NFT) e offuscamento linguistico, l'attaccante — che operava sotto l'account, ora eliminato, @Ilhamrfliansyh — ha esposto la fragile interfaccia in cui l'elaborazione del linguaggio naturale incontra l'esecuzione su blockchain.

I meccanismi dell'elevazione dei privilegi

Per capire come un chatbot possa essere costretto a effettuare un trasferimento finanziario a sei cifre, bisogna innanzitutto guardare all'infrastruttura sottostante dell'ecosistema 'Bankr'. Bankrbot è progettato per consentire agli utenti di eseguire operazioni di trading e gestire portafogli attraverso interfacce conversazionali. In questa specifica configurazione, a Grok era stato concesso l'accesso a un portafoglio digitale, agendo come un agente funzionale in grado di firmare transazioni basate sui prompt degli utenti.

Da una prospettiva di ingegneria meccanica, questo rappresenta un fallimento nella logica dell'escalation automatica dei privilegi. Il sistema non ha distinto tra una credenziale acquisita attraverso legittimi canali amministrativi e una inviata da un attore esterno potenzialmente ostile. Una volta confermato l'NFT sulla blockchain, il livello di integrazione ha riconosciuto Grok come un agente autorizzato con la capacità di movimentare capitali significativi.

Con i permessi stabiliti, l'ostacolo rimanente era l'allineamento di sicurezza interno di Grok. Come la maggior parte dei moderni LLM, Grok è programmato con barriere protettive (guardrail) intese a impedirgli di compiere atti illegali, impegnarsi in frodi finanziarie o eseguire comandi che appaiono come "jailbreak". Per aggirare questi filtri, l'attaccante si è rivolto al codice Morse — un sistema di punti e linee facilmente leggibile da un LLM ma spesso trascurato dai principali livelli di sicurezza che monitorano parole chiave come 'trasferisci', 'invia' o 'portafoglio'.

L'attaccante ha chiesto a Grok di tradurre una stringa di codice Morse apparentemente innocua. Tuttavia, l'output tradotto non è stato semplicemente mostrato all'utente; è stato reintrodotto nel ciclo di comando interno del bot. Nascosta all'interno del codice c'era un'istruzione diretta all'API di Bankrbot per trasferire 3 miliardi di token DRB (dal valore di circa 200.000 dollari) all'indirizzo del portafoglio dell'attaccante. Poiché il bot ha percepito questa operazione come il proprio output interno derivato da un compito di "traduzione", non ha attivato il consueto scetticismo associato alle richieste finanziarie dirette.

Questa tecnica è nota nella sicurezza informatica come 'indirect prompt injection'. Sfrutta il fatto che un LLM tratta tutti i dati — che si tratti della domanda di un utente, di un documento che sta riassumendo o di un codice che sta traducendo — come parte del suo contesto operativo. Quando tali dati contengono istruzioni eseguibili, il bot può inavvertitamente trattarle come obiettivi ad alta priorità, ignorando il proprio addestramento precedente o i protocolli di sicurezza.

Perché gli LLM faticano con i comandi codificati

Il successo dell'exploit basato sul codice Morse indica una sfida fondamentale nel campo della sicurezza dell'IA: l' 'interpretabilità' degli input multimodali. Mentre uno sviluppatore umano potrebbe riconoscere una stringa di punti e linee come un potenziale vettore per del testo nascosto, un'IA la vede come una struttura dati da elaborare. Se il filtro di sicurezza è ottimizzato per cercare modelli di malversazione in lingua inglese, probabilmente mancherà comandi codificati in Base64, Morse o persino stringhe esadecimali.

In questo caso, la competenza di Grok nella traduzione è diventata la sua principale debolezza. La capacità del bot di decodificare perfettamente il codice Morse ha significato che poteva ricostruire il comando dannoso con una fedeltà perfetta. L'integrazione con l'API di Bankrbot era troppo stretta; non c'era alcun "air gap" o verifica umana secondaria per convalidare che un compito di traduzione non dovesse tradursi in una transazione blockchain. L'architettura del sistema non è riuscita a implementare il "principio del privilegio minimo", consentendo a un'utility di traduzione di accedere a un modulo di esecuzione finanziaria senza un handshake di autenticazione separato.

La vulnerabilità del cambiamento "agentico"

Il settore si sta attualmente allontanando dai chatbot "statici" verso un'IA "agentica" — modelli in grado di intraprendere azioni nel mondo reale, dalla prenotazione di voli alla gestione di portafogli di investimento. Sebbene ciò aumenti l'utilità, espande esponenzialmente la superficie di attacco. Questo exploit di Grok è un monito per qualsiasi sviluppatore che costruisca ponti tra LLM e sistemi industriali o finanziari.

Se un bot è in grado di trasformare le parole in azioni, la sicurezza di quel bot è forte solo quanto la sua capacità di distinguere tra "dati" e "istruzioni". Nell'informatica tradizionale, abbiamo risolto questo problema utilizzando il "bit NX" (No-eXecute) per impedire che i buffer di dati venissero eseguiti come codice. Nel mondo degli LLM, dobbiamo ancora trovare un equivalente linguistico del bit NX. Ogni parola elaborata dal bot è potenzialmente un "codice" che può alterarne il comportamento.

Implicazioni economiche e di sicurezza per la finanza basata sull'IA

La conseguenza immediata dell'exploit è stato il trasferimento di 200.000 dollari in criptovalute, ma le implicazioni a lungo termine sono molto più costose. L'incidente sottolinea i rischi intrinseci del collegare un'IA integrata nei social media con la liquidità finanziaria in tempo reale. Per piattaforme come X, che si stanno muovendo verso un modello di "everything app" caratterizzato da pagamenti integrati e assistenti IA, questo evento funge da crudo promemoria del fatto che l'attuale generazione di LLM non è ancora abbastanza "irrobustita" per ambienti finanziari ad alto rischio.

I token specifici coinvolti, i DRB, hanno subito la tipica volatilità associata a un drenaggio improvviso e su larga scala. Inoltre, l'account dell'attaccante è stato eliminato poco dopo la conferma della transazione, una tattica comune per evitare un tracciamento immediato sul livello sociale, anche se la transazione blockchain stessa rimane pubblica e immutabile. Ciò evidenzia la difficoltà di attribuire tali attacchi: si è trattato di un hacker sofisticato o semplicemente di un utente curioso che ha scoperto una falla nella logica di integrazione?

Costruire migliori barriere per l'IA industriale

Per prevenire exploit simili in applicazioni industriali o della catena di approvvigionamento, dove agli agenti IA potrebbe essere affidato il compito di acquistare materie prime o gestire budget logistici, è necessario un approccio più rigoroso alla "separazione tra comando e dati". Misure di sicurezza pragmatiche includerebbero:

• Rigorosa sanificazione dell'input: Qualsiasi input che richieda traduzione o decodifica dovrebbe essere contrassegnato e isolato dagli strumenti di esecuzione del bot.
• Autenticazione a più fattori (MFA) per le transazioni: Indipendentemente da quanto un'IA sia "sicura" di un comando, qualsiasi trasferimento di valore in uscita dovrebbe richiedere una conferma secondaria, fuori banda, da parte di un operatore umano.
• Firewall semantici: Dovrebbero essere impiegati modelli secondari specializzati esclusivamente per analizzare l' *intento* delle azioni pianificate dal bot prima che vengano inviate a un'API, cercando discrepanze tra la richiesta iniziale dell'utente e l'output finale del bot.

Mentre continuiamo a mappare l'interfaccia tra robotica e industria umana, l'exploit di Grok tramite codice Morse verrà probabilmente citato come un caso emblematico nella sicurezza dell'IA. Dimostra che, man mano che i bot diventano più capaci di capirci, diventano anche più capaci di essere tratti in inganno. Per gli ingegneri che costruiscono la prossima generazione di sistemi automatizzati, la lezione è chiara: non fidarsi mai dell'input, specialmente quando arriva in punti e linee.