AI e PLC: i costi e i limiti del porting di exploit industriali
- Ricercatori di Forescout hanno usato Claude per portare un exploit RCE tra due modelli di PLC WAGO.
- L'operazione ha richiesto 8 ore e 32 minuti di lavoro e un costo di 535,74 dollari in API.
- L'AI non è autonoma: è necessario l'uso di Ghidra e la supervisione costante di un esperto.
- Un errore dell'AI durante la creazione di un impianto C2 ha brickato permanentemente l'hardware.
Un PLC brickato per errore
Il silenzio di un macchinario industriale che smette di rispondere è il peggior incubo di ogni responsabile di impianto. In un ambiente di laboratorio, questo scenario si è verificato non a causa di un guasto meccanico, ma per un errore di scrittura in memoria flash. I ricercatori di Vedere Labs, divisione di Forescout, stavano testando i limiti di un'intelligenza artificiale nel tentativo di espandere un exploit in un impianto di comando e controllo (C2). L'AI ha generato un'istruzione di scrittura errata che ha reso il PLC permanentemente inutilizzabile.
L'incidente è avvenuto durante la fase finale di un esperimento volto a capire se Claude, l'AI di Anthropic, potesse trasformare un semplice accesso remoto in una persistenza strategica sul dispositivo. Questo evento evidenzia un rischio concreto: l'AI può accelerare la scoperta di vulnerabilità, ma la sua mancanza di comprensione profonda dell'hardware fisico può portare a danni irreversibili ai sistemi di controllo industriale.
Può l'intelligenza artificiale scrivere exploit per l'industria?
La risposta breve è sì, ma con riserve sostanziali. L'esperimento si è concentrato sul porting di un exploit di Remote Code Execution (RCE) già noto, basato sulla vulnerabilità CVE-2021-31886. Si tratta di un buffer overflow pre-autenticazione nel server FTP Nucleus che permette a un attaccante di eseguire shellcode ARM arbitrari. Il punto di partenza era un exploit funzionante per il modello WAGO 750-852; l'obiettivo era adattarlo al modello WAGO 750-831.
L'AI è stata in grado di confermare la presenza della vulnerabilità attraverso un mix di analisi statica del firmware e probing live. È riuscita a generare un payload che ha causato il crash del PLC, confermando il difetto. Tuttavia, passare dal semplice Denial of Service (DoS) a un'esecuzione di codice controllata è stato un processo complesso. L'AI ha inizialmente fallito perché il processamento standard dell'FTP azzerava lo shellcode.
Analisi strategica: Per un imprenditore, questo significa che l'AI non ha ancora raggiunto la capacità di lanciare attacchi "zero-click" autonomi contro l'OT (Operational Technology). L'AI agisce come un moltiplicatore di forza per l'hacker esperto, riducendo i tempi di analisi del codice, ma non sostituisce la competenza tecnica necessaria per navigare in sistemi embedded a codice chiuso.
Il costo reale di 535 dollari e 8 ore di lavoro
L'idea che l'AI possa democratizzare gli attacchi cyber rendendoli istantanei e gratuiti è smentita dai numeri di questo test. Il raggiungimento della RCE sul modello WAGO 750-831 non è stato un processo automatico, ma un investimento di risorse precise. I ricercatori hanno documentato un tempo di lavoro di 8 ore e 32 minuti e una spesa di 535,74 dollari in costi di API.
Questi costi derivano dall'utilizzo di modelli avanzati come Claude Sonnet 4.6 e Claude Opus 4.6. La complessità del compito ha richiesto numerosi tentativi, correzioni di ipotesi errate e l'invio di grandi quantità di contesto (disassembly del firmware) all'AI, gonfiando il consumo di token. Il costo economico e temporale, sebbene inferiore a quello di un attacco sviluppato interamente da un umano, rimane una barriera d'ingresso per l'attaccante occasionale.
È possibile approfondire i dettagli tecnici di questa ricerca consultando il report su SecurityWeek, dove viene analizzato l'impatto di queste scoperte sulla sicurezza dei sistemi di controllo.
Perché Claude ha bisogno di Ghidra e di un umano
L'AI non opera nel vuoto. Per avere successo, Claude Code ha avuto bisogno di un ecosistema di strumenti e di una guida costante. I ricercatori hanno fornito all'AI l'accesso a un terminale, a file di riferimento, a strumenti di rete e, soprattutto, a Ghidra, il noto strumento di reverse engineering. Senza la capacità di analizzare il firmware attraverso Ghidra, l'AI non avrebbe potuto mappare il layout della memoria del PLC.
Il ruolo dell'umano è stato fondamentale in tre aree critiche:
- Correzione dei vicoli ciechi: Quando l'AI formulava ipotesi errate sulla gestione del buffer, l'esperto interveniva per riorientare la ricerca.
- Fornitura di contesto: L'umano ha dovuto aggiungere manualmente il contesto di disassembly necessario affinché l'AI comprendesse dove iniettare il codice.
- Gestione del modello: I ricercatori hanno dovuto switchare tra diverse versioni di Claude (da Sonnet a Opus 4.6) per superare specifici ostacoli logici.
L'AI ha agito come un assistente di programmazione estremamente veloce, capace di scrivere script Python per l'analisi e di generare payload UDP (che hanno infine consegnato la stringa 'PWNED' e un payload ICMP echo), ma la strategia di attacco è rimasta interamente nelle mani dell'operatore umano.
Quanto è efficace il porting assistito tra modelli WAGO?
Per comprendere l'efficacia di questo processo, è utile analizzare l'esperimento sotto forma di interrogazioni tecniche basate sui risultati di Dev.to.
L'AI può identificare autonomamente la vulnerabilità?
Sì, attraverso l'analisi del firmware e il probing live, l'AI ha confermato che il buffer overflow del server FTP Nucleus era presente anche nel modello 750-831, non solo nel 750-852.
Qual è stata la sfida tecnica principale?
La transizione dal crash (DoS) all'esecuzione di codice. L'AI ha dovuto capire perché lo shellcode veniva azzerato durante il processamento FTP e trovare un modo per preservare il buffer.
L'AI può operare su hardware chiuso senza debugger?
Sì, ma richiede che l'umano fornisca l'output di strumenti di reverse engineering come Ghidra, poiché l'AI non può 'vedere' fisicamente l'hardware o accedere a debug interni non documentati.
Qual è il risultato finale dell'exploit portato?
Un exploit di RCE pre-autenticazione capace di inviare payload UDP che eseguono comandi specifici sul PLC target.
La sicurezza delle infrastrutture critiche tra NIS2 e l'AI Act
L'esperimento di Forescout non è solo un esercizio tecnico, ma un segnale per le aziende che operano in settori critici. La capacità di portare exploit tra modelli di hardware diversi utilizzando l'AI riduce il tempo di adattamento di un attacco. Se un attaccante possiede un exploit per un modello di PLC diffuso, l'AI può aiutarlo a colpire rapidamente varianti di quel prodotto, aumentando la superficie di attacco di un intero parco macchine.
In Europa, questo scenario si inserisce nel quadro della direttiva NIS2, che impone standard di sicurezza molto più rigorosi per le entità essenziali e importanti. La NIS2 richiede una gestione proattiva del rischio della supply chain e una resilienza operativa che non può più basarsi sulla 'sicurezza per oscurità' (ovvero l'idea che i PLC siano sicuri perché il loro firmware è chiuso e complesso).
Parallelamente, l'AI Act dell'Unione Europea introduce una classificazione dei rischi per i sistemi di intelligenza artificiale. Sebbene l'AI Act miri a limitare l'uso improprio dell'AI, l'esperimento dimostra che modelli general-purpose come Claude possono essere utilizzati per scopi offensivi se guidati da esperti. La sfida per le imprese italiane sarà integrare l'analisi delle vulnerabilità assistita da AI nelle proprie difese, utilizzando gli stessi strumenti degli attaccanti per scoprire i punti deboli prima che vengano sfruttati.
Analisi geopolitica e scenari futuri:
Il rischio principale non è l'AI autonoma, ma l'AI che abbassa la soglia di competenza necessaria per l'attacco a infrastrutture critiche. Se oggi servono 8 ore e un esperto, domani potrebbero servire 2 ore e un tecnico di livello medio.
Indicatore verificabile: La comparsa di tool di 'AI-Red Teaming' specifici per l'OT, capaci di interfacciare automaticamente LLM con Ghidra e simulatori di PLC, segnerebbe il passaggio dall'esperimento manuale all'industrializzazione dell'attacco AI-assisted.
Domande frequenti
Quale vulnerabilità è stata utilizzata nell'esperimento?
È stata utilizzata la CVE-2021-31886, un buffer overflow pre-autenticazione nel server FTP Nucleus.
L'AI ha agito in totale autonomia durante il porting dell'exploit?
No, ha richiesto la supervisione costante di un ricercatore umano per correggere errori, fornire contesto di disassembly e cambiare modello di AI.
Quali sono stati i costi totali dell'operazione?
L'operazione ha richiesto 8 ore e 32 minuti di lavoro e un costo di 535,74 dollari in API di Claude.
Fonti: Securityweek, Dev, Letsdatascience ·
glacom · Intelligenza artificiale per aziende: i modelli girano sui tuoi server, i dati non escono →Scrivila qui: Susanna, l assistente AI di glacom, ti risponde via email con un approfondimento gratuito.
Nessuna consulenza personalizzata (finanziaria, legale o medica): solo informazione e fonti. Email usata solo per rispondere.
oppure scrivile su: WhatsApp · Telegram · SimpleX · Delta Chat · Email
