Mettere in sicurezza il modello linguistico di grandi dimensioni prima della prossima violazione da prompt injection

Il mese scorso ho esaminato un rapporto forense in cui una società di servizi finanziari ha perso il controllo di un bot interno per il servizio clienti. L'azienda disponeva di uno stack di sicurezza all'avanguardia, eppure una singola frase formulata abilmente in un ticket di assistenza ha superato ogni barriera di protezione. Questo è il paradosso architettonico dell'IA moderna. Avvolgiamo questi modelli in strati di sicurezza tradizionale, ma non riusciamo ad affrontare la vulnerabilità principale: il modello è incapace di separare i dati non attendibili dalle istruzioni attendibili. CrowdStrike ha recentemente codificato questo problema in cinque distinti nuovi vettori di attacco che ogni architetto della sicurezza deve comprendere.

Ho trascorso la mattinata di ieri nel mio laboratorio cercando di replicare una di queste tecniche su una versione localizzata di Llama 3. La semplicità dell'exploit è ciò che lo rende pericoloso. Dal punto di vista del rischio, ci troviamo attualmente nel "Wild West" dell'IA generativa. Le cinque nuove minacce di prompt injection identificate da CrowdStrike dimostrano che gli aggressori si stanno spingendo oltre i semplici comandi "ignora tutte le istruzioni precedenti". Ora utilizzano la manipolazione linguistica e la distribuzione multi-fase per compromettere i sistemi.

Il collasso del confine tra dati e istruzioni

La prompt injection esiste a causa del modo in cui i modelli linguistici di grandi dimensioni elaborano le informazioni. Nel software tradizionale, il codice e i dati sono solitamente conservati in spazi di memoria separati. Un database SQL non esegue accidentalmente il cognome di un utente come comando, a meno che non vi sia una vulnerabilità specifica come la SQL injection. In un LLM, le istruzioni dello sviluppatore e i dati dell'utente risiedono nella stessa finestra di contesto. Il modello tratta ogni token con un peso simile.

Questa mancanza di separazione rende il perimetro di rete un fossato di castello obsoleto. Se permetti a un LLM di leggere un'e-mail, stai essenzialmente dando a quell'e-mail un posto alla tastiera. Gli aggressori sfruttano questo design inserendo istruzioni all'interno di dati che il modello finisce per elaborare come una direttiva. La nuova tassonomia di CrowdStrike fornisce una mappa di come questi aggressori stiano evolvendo i loro metodi per superare il filtraggio di base delle parole chiave.

Minacce dormienti attraverso regole attivate da trigger

La prima nuova tecnica è l'aggiunta di regole attivate da trigger. In questo scenario, un aggressore non cerca di rompere il modello immediatamente. Invece, introduce una nuova regola che appare innocua. Ad esempio, l'aggressore potrebbe dire al modello di riassumere sempre il testo in un formato specifico se vede la parola "bluebird". Di per sé, questa non è una violazione. Sembra una personalizzazione minore.

Tuttavia, l'aggressore può attivare questa regola in un secondo momento per causare comportamenti strani o dannosi. La regola agisce come un agente dormiente. Una volta attivato il trigger, il modello potrebbe reindirizzare il suo output a un'API non autorizzata o iniziare a rivelare prompt di sistema sensibili. Poiché l'aggiunta iniziale della regola è innocua, passa attraverso la maggior parte dei sistemi di rilevamento di base. La minaccia rimane dormiente finché non vengono soddisfatte le condizioni specifiche. Valutare la superficie di attacco richiede la ricerca di queste istruzioni "if-then" nascoste nelle cronologie delle conversazioni a lungo termine o nelle istruzioni di sistema.

Rompere il filtro con la soppressione cognitiva dei token

La soppressione cognitiva dei token è un approccio più tecnico per bypassare le misure di sicurezza. La maggior parte degli LLM ha modelli di rifiuto integrati. Se chiedi a un modello di aiutarti a scrivere un malware, è addestrato per dire qualcosa come "Non posso assistere con questa richiesta". I team di sicurezza spesso si affidano a questi modelli di rifiuto stabiliti per mantenere il modello sicuro.

Un aggressore che utilizza la soppressione cognitiva dei token sposta le scelte linguistiche del modello lontano da questi schemi. Potrebbe utilizzare vincoli complessi che proibiscono al modello di usare parole come "non posso", "rifiuto" o "policy". Privando il modello della sua capacità di dire di no nel suo modo abituale, l'aggressore costringe l'LLM in uno stato in cui è più probabile che soddisfi una richiesta malevola. È una forma di manette linguistiche. Il modello è costretto a trovare un percorso attraverso la richiesta che eviti il suo addestramento sulla sicurezza. Di conseguenza, il filtro di sicurezza fallisce perché il modello non ha più accesso al vocabolario necessario per esprimere un rifiuto.

Nascondere il payload attraverso la decomposizione algoritmica

La decomposizione algoritmica del payload è un attacco che si basa sulla capacità del modello di assemblare idee complesse partendo da parti semplici. Un aggressore invia un messaggio in più fasi. Ogni fase è innocente se vista isolatamente. Un prompt potrebbe chiedere al modello di memorizzare una specifica stringa di caratteri. Un secondo prompt potrebbe chiedergli di definire una certa funzione.

Quando combinati, questi pezzi si assemblano in un unico comando minaccioso. Questo è il cavallo di Troia digitale della prompt injection. Gli strumenti di sicurezza che scansionano i singoli prompt alla ricerca di intenti malevoli non vedranno nulla di sbagliato. La minaccia emerge solo a livello architettonico quando il modello integra tutti i pezzi. Ho visto questo metodo funzionare efficacemente in ambienti in cui la finestra di contesto è abbastanza grande da contenere diverse interazioni apparentemente non correlate che alla fine formano una catena di exploit completa.

Il rischio di iniezione di token speciali

L'iniezione di token speciali è una tecnica che prende di mira gli interruttori di controllo dell'LLM. I modelli utilizzano token speciali per contrassegnare la fine di un pensiero o l'inizio di un'istruzione di sistema. Questi token sono come i pulsanti sul cruscotto di un pilota. Se un aggressore riesce a inserire questi token nel proprio input, può ingannare il modello facendogli credere che il contenuto dell'utente sia in realtà una direttiva di sistema ad alta priorità.

Questo attacco introduce una confusione che spinge il modello a elevare il contenuto dell'utente non attendibile. Si tratta di un assalto diretto alla logica interna del modello. Contraffacendo questi interruttori di controllo, l'aggressore ottiene la capacità di sovrascrivere le istruzioni originali dello sviluppatore. Il modello inizia a trattare l'aggressore come l'amministratore. Ciò è particolarmente pericoloso per i modelli collegati a strumenti o database esterni. Una volta che il modello crede che l'aggressore sia una voce di sistema fidata, eseguirà azioni con privilegi elevati.

Ingannare l'utente con l'iniezione di dati di contesto

L'iniezione involontaria di dati di contesto da parte dell'utente è forse la minaccia più pervasiva in questo nuovo elenco. Questo exploit sfrutta il confine tra dati attendibili e istruzioni eseguibili. L'utente è colui che introduce l'istruzione malevola, ma lo fa senza saperlo. Ciò accade quando un utente carica un documento, inoltra un'e-mail o aggiunge contenuti web che l'IA elabora successivamente.

Dietro le quinte, l'istruzione malevola è nascosta all'interno del documento o dell'e-mail. Il prompt scritto dall'utente potrebbe essere innocuo, come "riassumi questo PDF". Il PDF stesso contiene una riga di testo nascosta che dice al modello di ignorare il riassunto e inviare invece il token di sessione dell'utente a un server esterno. L'utente è il veicolo di consegna dell'attacco. In termini di integrità dei dati, questo è un incubo. Significa che ogni informazione toccata da un LLM è un potenziale vettore di compromissione.

Costruire un'architettura di difesa resiliente

I team di sicurezza possono proteggersi da tali attacchi in diversi modi. Proattivamente parlando, il primo passo è la modellazione delle minacce per ogni luogo da cui può avere origine il contesto del modello. È necessario trattare ogni input come un asset tossico. Ciò include i file caricati dagli utenti, le e-mail recuperate da una casella di posta e i dati estratti dai database interni.

CrowdStrike raccomanda di espandere i test per includere specificamente questi cinque vettori. Il red teaming dovrebbe concentrarsi sugli attacchi compositi piuttosto che sui fallimenti del singolo prompt. È necessario verificare se il modello può essere ingannato dalla decomposizione o dalla soppressione. A parte le patch, la vera soluzione è l'ingegneria del rilevamento granulare. Abbiamo bisogno di sistemi in grado di monitorare lo stato interno del modello e di avvisare quando inizia a ignorare le sue istruzioni principali.

Lo Zero Trust deve essere applicato ai dati che fluiscono nell'LLM. Pensatelo come a un buttafuori di un club VIP a ogni porta interna. Non fidatevi mai dei dati, anche se provengono da un utente autenticato. Il buttafuori deve verificare che il contenuto non contenga istruzioni nascoste prima che sia ammesso nella finestra di contesto del modello. Questo è l'unico modo per costruire un sistema resiliente in grado di resistere alla prossima generazione di prompt injection.

Dal punto di vista forense, dovreste anche mantenere log dettagliati dell'intera finestra di contesto per ogni interazione. In caso di violazione, questi log sono fondamentali per capire come un aggressore ha superato i filtri. Se registrate solo l'output finale, vi state perdendo la parte più importante della catena di attacco.

Punti chiave per i leader della sicurezza

• Controllare le fonti di contesto: Identificare tutti gli input di dati che raggiungono i propri LLM e trattarli come istruzioni non attendibili.
• Testare i bypass linguistici: Utilizzare il red teaming per vedere se il modello è vulnerabile alla soppressione cognitiva dei token o alla decomposizione algoritmica.
• Monitorare i token speciali: Implementare filtri che rilevino e rimuovano i token di controllo dai dati forniti dall'utente.
• Istruire gli utenti sui rischi del contesto: Informare i dipendenti che riassumere documenti non attendibili può portare a una compromissione del sistema.
• Implementare l'ingegneria del rilevamento: Andare oltre la semplice corrispondenza delle parole chiave e iniziare a cercare anomalie comportamentali nelle risposte del modello.

L'IA è uno strumento potente, ma è anche un nuovo tipo di superficie di attacco. Comprendendo queste cinque nuove minacce, è possibile iniziare a costruire una difesa intelligente quanto i modelli che si sta cercando di proteggere.

Fonti: CrowdStrike Falcon Intelligence, NIST AI Risk Management Framework, MITRE ATLAS.

Dichiarazione di non responsabilità: questo articolo è solo a scopo informativo ed educativo e non sostituisce un audit professionale di cybersicurezza o un servizio di risposta agli incidenti.