Attacchi assistiti dall’LLM: un esempio completo

# 9. Attacchi assistiti dall’LLM: un esempio completo Nei capitoli precedenti abbiamo esaminato le singole capacità che un LLM può mettere a disposizione di un attaccante: analisi delle informazioni, comprensione del codice, generazione di programmi, automazione, elaborazione di documenti e comunicazione. Finora, però, le abbiamo considerate separatamente. Per capire realmente quale sia il cambiamento introdotto dagli LLM è più utile osservare cosa succede quando queste capacità vengono concatenate. L'esempio seguente non descrive un attacco contro un'organizzazione reale e non fornisce una procedura da eseguire contro sistemi di terzi. È un modello concettuale, ambientato in un'infrastruttura di laboratorio deliberatamente vulnerabile. Il suo scopo è mostrare come l'LLM possa inserirsi nelle diverse fasi di un'attività offensiva. ## 9.1 Il bersaglio del laboratorio Immaginiamo una piccola azienda che dispone di un'applicazione Web per la gestione degli ordini. L'architettura, semplificata, è questa: ```text INTERNET │ ▼ WEB APPLICATION │ ┌─────────┴─────────┐ ▼ ▼ DATABASE API ESTERNA ``` L'applicazione presenta alcune funzionalità normali: autenticazione degli utenti, consultazione degli ordini, ricerca dei prodotti e gestione dei dati amministrativi. Nel laboratorio sappiamo inoltre che esiste una vulnerabilità intenzionale nell'applicazione. Il nostro obiettivo non è insegnare come sfruttarla, ma osservare come un LLM possa assistere l'analista nel percorso che porta dalla raccolta delle informazioni alla comprensione del problema. L'attaccante dispone di un LLM e di alcune informazioni iniziali sul bersaglio. La domanda fondamentale diventa: **quanto può accelerare il lavoro l'LLM?** ## 9.2 Prima fase: comprendere il bersaglio L'attaccante raccoglie materiale pubblico relativo all'applicazione: documentazione, descrizione delle funzionalità, frammenti di codice disponibili nel laboratorio e informazioni sulla tecnologia utilizzata. Invece di analizzare manualmente tutto il materiale, può sottoporlo al modello chiedendo di organizzarlo. Per esempio: ```text Analizza questi documenti e individua: - componenti dell'applicazione; - tecnologie utilizzate; - punti di ingresso dei dati; - funzioni che interagiscono con il database; - aree che richiedono una verifica di sicurezza. ``` Il risultato non è ancora un attacco. È analisi. Ma il modello ha già svolto una parte del lavoro che normalmente richiederebbe tempo umano. L'attaccante può quindi approfondire i punti che il modello ha individuato, verificando personalmente se le ipotesi siano corrette. Questo passaggio è importante perché mostra uno dei principali vantaggi dell'LLM: **trasformare rapidamente materiale non strutturato in una rappresentazione più facilmente analizzabile.** ## 9.3 Seconda fase: analizzare il codice Nel laboratorio è disponibile il codice di una delle funzioni dell'applicazione. L'attaccante lo sottopone al modello. L'LLM può essere utilizzato come revisore preliminare: ```text Esamina questa funzione dal punto di vista della sicurezza. Individua quali dati provengono dall'utente, come vengono elaborati e quali controlli vengono effettuati. ``` Il modello osserva il flusso dei dati e segnala una possibile situazione anomala. A questo punto, però, non bisogna commettere un errore concettuale: **il risultato del modello non è ancora una vulnerabilità dimostrata.** Potrebbe essere: ```text analisi corretta oppure falso positivo oppure analisi incompleta ``` L'attaccante, proprio come un analista di sicurezza, deve verificare l'ipotesi. Questo introduce una caratteristica fondamentale dell'utilizzo offensivo degli LLM: il modello può produrre una grande quantità di ipotesi, ma la loro validità deve essere accertata. ## 9.4 Terza fase: trasformare l'ipotesi in una verifica Supponiamo che l'LLM abbia individuato un possibile problema nella gestione di un parametro fornito dall'utente. In un laboratorio autorizzato, l'analista può chiedere al modello di spiegare quale comportamento dovrebbe essere osservato per stabilire se l'ipotesi sia fondata. Il modello può quindi aiutare a costruire una verifica controllata. La sequenza concettuale è: ```text CODICE ↓ ANALISI ↓ IPOTESI DI VULNERABILITÀ ↓ TEST CONTROLLATO ↓ RISULTATO ``` L'LLM non ha necessariamente scoperto qualcosa di nuovo. Ha ridotto il tempo necessario per arrivare dalla lettura del codice alla formulazione di un'ipotesi verificabile. ## 9.5 Quarta fase: interpretare il risultato Supponiamo che il test del laboratorio confermi l'esistenza del problema. A questo punto entra in gioco un'altra capacità dell'LLM: l'interpretazione. L'analista può fornire al modello il comportamento osservato e chiedere di spiegare quali componenti dell'applicazione siano coinvolti. Il modello può mettere in relazione: ```text input ↓ funzione applicativa ↓ componente vulnerabile ↓ database ``` e spiegare quali controlli avrebbero dovuto impedire il comportamento osservato. Questa fase è particolarmente utile quando l'applicazione è composta da molti componenti. L'LLM funziona, in sostanza, come uno strumento di correlazione tra informazioni tecniche. ## 9.6 Quinta fase: cercare il punto di contenimento A questo punto l'analista non deve necessariamente chiedere: **“Come posso sfruttare il problema?”** Una domanda più interessante dal punto di vista della sicurezza è: **“Dove avrebbe dovuto essere bloccata questa operazione?”** Questa domanda porta direttamente alla progettazione delle difese. Immaginiamo che il percorso sia: ```text UTENTE ↓ INPUT ↓ APPLICAZIONE ↓ FUNZIONE ↓ DATABASE ``` Se il controllo manca tra input e funzione, la correzione può essere collocata in quel punto. Se il problema riguarda invece i privilegi del database, la correzione può richiedere una modifica completamente diversa. L'LLM può aiutare a confrontare queste possibilità, ma la decisione architetturale rimane una responsabilità dell'analista. ## 9.7 Sesto passaggio: l'automazione Finora abbiamo immaginato un analista che dialoga direttamente con il modello. Il quadro cambia quando introduciamo l'automazione. Un agente potrebbe ricevere una serie di compiti autorizzati: ```text 1. analizza la documentazione; 2. classifica le tecnologie; 3. esamina il codice; 4. segnala possibili vulnerabilità; 5. prepara un rapporto; 6. propone verifiche da eseguire. ``` Il flusso diventa: ```text LLM │ ┌──────┼──────┐ ▼ ▼ ▼ documenti codice dati │ │ │ └──────┼──────┘ ▼ ANALISI │ ▼ PROPOSTE │ ▼ CONTROLLO UMANO │ ▼ TEST AUTORIZZATI ``` Qui compare una differenza fondamentale rispetto a un semplice chatbot. L'LLM non si limita più a produrre una risposta: **partecipa a una sequenza di attività**. Ed è proprio questa caratteristica a rendere necessario il controllo dei privilegi dell'agente. ## 9.8 Il punto critico: proposta non significa esecuzione Il principio introdotto nel capitolo sugli agenti assume qui un'importanza ancora maggiore. Un sistema sicuro dovrebbe distinguere: ```text LLM │ ├── propone un'azione │ ▼ CONTROLLO │ ├── verifica autorizzazione ├── verifica parametri ├── verifica ambito └── verifica privilegi │ ▼ ESECUZIONE ``` Se invece l'architettura fosse: ```text LLM → esecuzione automatica ``` un errore del modello potrebbe trasformarsi direttamente in un'azione sul sistema. Questo vale anche quando il modello viene utilizzato dall'attaccante. Un agente offensivo dotato di strumenti molto potenti potrebbe aumentare enormemente la velocità delle attività. Ma proprio per questo, dal punto di vista difensivo, i suoi strumenti devono essere confinati e monitorati. ## 9.9 Settima fase: il fattore umano Supponiamo ora che l'LLM commetta un errore. Durante l'analisi individua come vulnerabile una funzione che in realtà non lo è. Se l'analista accetta automaticamente la conclusione, il processo prende una direzione sbagliata. Possiamo quindi avere: ```text informazione ↓ LLM ↓ interpretazione errata ↓ decisione errata ``` Questo problema è particolarmente importante perché l'automazione può amplificare sia le capacità sia gli errori. Un modello che sbaglia una risposta produce un errore. Un agente che prende quella risposta come base per altre dieci operazioni può produrre dieci errori. Un sistema che ripete automaticamente il processo può trasformare un singolo errore in un comportamento sistematico. La supervisione, pertanto, non è un elemento puramente burocratico. È una barriera tecnica. ## 9.10 Dall'attacco singolo all'attacco scalabile È qui che emerge la differenza più importante. Senza automazione: ```text ATTACCANTE ↓ LLM ↓ analisi ↓ azione ↓ analisi ↓ azione ``` Con un sistema fortemente automatizzato: ```text ATTACCANTE ↓ LLM ↓ AGENTE ↓ ┌─────────┼─────────┐ ▼ ▼ ▼ target A target B target C │ │ │ └─────────┼─────────┘ ▼ risultati ``` Il punto non è necessariamente che l'LLM sia più intelligente dell'essere umano. È che può rendere più economica la ripetizione di determinate attività. In sicurezza informatica questa caratteristica può avere conseguenze rilevanti: ciò che prima richiedeva un gruppo di persone può, in alcuni scenari, essere parzialmente automatizzato. ## 9.11 La stessa catena vista dal difensore La cosa interessante è che possiamo osservare esattamente la stessa sequenza dalla parte opposta. L'attaccante vede: ```text INFORMAZIONI ↓ LLM ↓ ANALISI ↓ AUTOMAZIONE ↓ BERSAGLIO ``` Il difensore dovrebbe vedere: ```text INFORMAZIONI PUBBLICHE ↓ ESPOSIZIONE ↓ SUPERFICI DI ATTACCO ↓ COMPORTAMENTI ANOMALI ↓ RILEVAMENTO ↓ BLOCCO ``` Questa simmetria è importante. Ogni capacità che l'LLM mette a disposizione dell'attaccante può diventare, almeno in parte, un problema che il difensore deve imparare a riconoscere. Se l'attaccante può automatizzare l'analisi, il difensore deve migliorare la capacità di rilevare comportamenti automatizzati. Se l'attaccante può generare rapidamente codice, il difensore deve aumentare la capacità di analizzarlo. Se l'attaccante può correlare grandi quantità di informazioni, il difensore deve proteggere meglio quelle informazioni. ## 9.12 Un esempio completo in una sola sequenza Possiamo ora riassumere l'intero scenario. ```text ATTACCANTE │ ▼ LLM │ ┌───────────┼───────────┐ ▼ ▼ ▼ OSINT CODICE DOCUMENTI │ │ │ └───────────┼───────────┘ ▼ ANALISI │ ▼ IPOTESI DI PROBLEMA │ ▼ VERIFICA CONTROLLATA │ ▼ RISULTATO │ ▼ DECISIONE │ ▼ AZIONE │ ▼ BERSAGLIO ``` Questa sequenza contiene un insegnamento importante. L'LLM non è necessariamente l'arma. Può essere qualcosa di più sottile: **un acceleratore presente in molti punti della catena**. Può assistere nella raccolta delle informazioni, nell'analisi, nella programmazione, nella documentazione, nella correlazione dei risultati e nell'automazione. Il rischio nasce dalla loro combinazione. ## 9.13 L'attacco assistito dall'LLM come problema sistemico A questo punto possiamo estendere la definizione di superficie d'attacco. Non dobbiamo più considerare soltanto: ```text bersaglio ← attaccante ``` ma: ```text bersaglio ← strumenti ← LLM ← attaccante ``` e, nel caso di agenti automatizzati: ```text bersaglio ↑ strumenti ↑ agente ↑ LLM ↑ attaccante ``` L'LLM diventa quindi un nuovo elemento della catena offensiva. Non necessariamente il più importante e non necessariamente quello che determina il successo dell'attacco. Ma un elemento capace di ridurre tempi, costi e lavoro manuale. È proprio questa caratteristica che rende l'uso degli LLM nella sicurezza informatica diverso da una semplice evoluzione dei normali strumenti software. ## 9.14 La lezione per la difesa Il difensore non può realisticamente basare la propria strategia sull'idea che l'attaccante non utilizzerà gli LLM. È più utile assumere il contrario: **le capacità di analisi, generazione e automazione saranno disponibili anche dall'altra parte.** La conseguenza non è una nuova lista di strumenti magici, ma un rafforzamento dei principi già fondamentali della sicurezza: * ridurre la superficie esposta; * applicare il principio del minimo privilegio; * separare autenticazione e autorizzazione; * validare gli input; * controllare gli output; * limitare gli strumenti disponibili agli agenti; * registrare le attività; * rilevare comportamenti anomali; * segmentare i sistemi; * verificare continuamente le configurazioni. L'LLM può accelerare l'attacco, ma non dovrebbe poter trasformare un singolo errore in una compromissione totale. Questa è forse la conclusione più importante dell'intero esempio. La sicurezza non consiste nell'impedire all'attaccante di avere un LLM. Consiste nel fare in modo che, **anche quando l'attaccante dispone di strumenti molto potenti, ogni singolo passaggio della catena incontri controlli indipendenti sufficienti a limitarne le conseguenze.** Ed è lo stesso principio che abbiamo incontrato più volte nei capitoli precedenti: non bisogna progettare un sistema contando sul fatto che un singolo componente — e quindi neppure un LLM — si comporterà sempre correttamente. Bisogna progettare il sistema affinché **anche quando un componente viene manipolato, ingannato o utilizzato contro di noi, il danno rimanga confinato.** Il capitolo successivo può ora chiudere il cerchio con **“10. Come difendersi dagli attacchi agli LLM e dagli attacchi assistiti dagli LLM”**, trasformando tutto ciò che abbiamo visto finora in un modello organico di difesa.