Guerra nell'Ombra per i Dati con gli LLM

Un’Ondata di Violazioni Espone le Vulnerabilità

La rapida adozione di Large Language Models (LLM) open-source come DeepSeek e Ollama è diventata un’arma a doppio taglio. Mentre le aziende sfruttano questi potenti strumenti per aumentare l’efficienza, la stessa apertura che alimenta la loro crescita sta creando un parallelo aumento dei rischi per la sicurezza dei dati. Un recente rapporto compilato da NSFOCUS Xingyun Lab dipinge un quadro desolante: solo nei primi due mesi del 2025, il mondo ha assistito a cinque significative violazioni di dati direttamente collegate agli LLM. Questi incidenti hanno portato all’esposizione di vasti tesori di informazioni sensibili, che vanno da cronologie di chat riservate e chiavi API a credenziali utente critiche. Questi eventi sono un campanello d’allarme, che evidenzia le vulnerabilità di sicurezza spesso trascurate che si nascondono sotto la superficie della tecnologia AI all’avanguardia. Questa esplorazione analizzerà questi cinque incidenti, sezionando i metodi di attacco, mappandoli al framework MITRE ATT&CK stabilito ed esponendo i punti ciechi della sicurezza che le organizzazioni devono affrontare con urgenza.

Incidente 1: Database di DeepSeek Mal Configurato – Una Finestra sulle Conversazioni Private

Cronologia: 29 gennaio 2025

Scala della Fuga di Dati: Milioni di righe di dati di log, incluse cronologie di chat sensibili e chiavi di accesso.

Svolgimento degli Eventi:

Il team di ricerca sulla sicurezza di Wiz ha avviato questa scoperta. Hanno identificato un servizio ClickHouse esposto accessibile sulla rete Internet pubblica. Ulteriori indagini hanno confermato che questo servizio apparteneva alla startup cinese di intelligenza artificiale, DeepSeek. ClickHouse, progettato per la gestione efficiente di grandi set di dati nell’elaborazione analitica, è diventato purtroppo un gateway per i dati interni di DeepSeek. I ricercatori hanno avuto accesso a circa un milione di righe del flusso di log di DeepSeek, rivelando un tesoro di informazioni sensibili, tra cui registri di chat storici e chiavi di accesso cruciali.

Wiz ha prontamente avvisato DeepSeek della vulnerabilità, portando a un’azione immediata e allo smaltimento sicuro del servizio ClickHouse esposto.

Sezionando l’Attacco:

Il problema principale risiedeva nella vulnerabilità di ClickHouse all’accesso non autorizzato. ClickHouse, un sistema di gestione di database orientato alle colonne open-source, eccelle nell’analisi e nelle query in tempo reale di enormi set di dati, spesso utilizzato per l’analisi dei log e del comportamento degli utenti. Tuttavia, quando implementato senza adeguati controlli di accesso, la sua interfaccia API esposta consente a chiunque di eseguire comandi simili a SQL.

L’approccio del team di sicurezza di Wiz ha comportato una scansione metodica dei sottodomini di DeepSeek esposti a Internet. Inizialmente concentrandosi sulle porte standard 80 e 443, hanno trovato risorse web tipiche come interfacce chatbot e documentazione API. Per ampliare la loro ricerca, si sono espansi a porte meno comuni come 8123 e 9000, scoprendo infine servizi esposti su più sottodomini.

I dati di log compromessi, risalenti al 6 gennaio 2025, contenevano una vasta gamma di informazioni sensibili: registri delle chiamate, registri di testo per endpoint API DeepSeek interni, cronologie dettagliate delle chat, chiavi API, dettagli del sistema backend e metadati operativi.

Classificazione Evento VERIZON: Errori Vari

Mappatura Framework MITRE ATT&CK:

• T1590.002 (Collect Victim Network Information - Domain Name Resolution): Gli aggressori hanno probabilmente utilizzato il nome di dominio principale per eseguire l’enumerazione dei sottodomini.
• T1046 (Web Service Discovery): Gli aggressori hanno identificato porte e servizi aperti associati al dominio di destinazione.
• T1106 (Native Interface): Gli aggressori hanno sfruttato l’API ClickHouse per interagire con il database.
• T1567 (Data Exfiltration via Web Service): Gli aggressori hanno utilizzato l’API ClickHouse per rubare dati.

Incidente 2: Attacco alla Supply Chain di DeepSeek – Un Cavallo di Troia nel Codice

Cronologia: 3 febbraio 2025

Scala della Fuga di Dati: Credenziali utente e variabili d’ambiente.

Svolgimento degli Eventi:

L’attacco è iniziato il 19 gennaio 2025, quando un utente malintenzionato, identificato come ‘bvk’, ha caricato due pacchetti Python dannosi denominati ‘deepseek’ e ‘deepseekai’ nel popolare repository PyPI (Python Package Index).

Il team di intelligence sulle minacce di Positive Technologies Expert Security Center (PT ESC) ha rilevato questa attività sospetta lo stesso giorno. La loro analisi ha confermato la natura dannosa dei pacchetti e hanno prontamente informato gli amministratori di PyPI.

Gli amministratori di PyPI hanno rapidamente rimosso i pacchetti dannosi e informato PT ESC. Nonostante la rapida risposta, le statistiche hanno rivelato che il malware era stato scaricato oltre 200 volte in 17 paesi attraverso vari canali. I pacchetti dannosi sono stati successivamente isolati.

Sezionando l’Attacco:

I pacchetti dannosi caricati da ‘bvk’ si sono concentrati su due obiettivi principali: raccolta di informazioni e furto di variabili d’ambiente. I dati rubati includevano informazioni sensibili come credenziali del database, chiavi API e credenziali di accesso per l’archiviazione di oggetti S3. Il payload dannoso veniva attivato ogni volta che un utente eseguiva DeepSeek o Deepseekai dalla riga di comando.

L’aggressore ha utilizzato PipeDream come server di comando e controllo per ricevere i dati rubati. L’incidente evidenzia diversi fattori che hanno contribuito:

• Attacco di Dependency Confusion: Gli aggressori hanno sfruttato la differenza di priorità tra i pacchetti privati di un’organizzazione e i pacchetti pubblici con lo stesso nome.
• Impersonificazione del Nome del Pacchetto: I pacchetti dannosi imitavano il marchio di DeepSeek, una nota azienda di intelligenza artificiale, per ingannare gli utenti.
• Debolezza della Registrazione PyPI: Il processo di registrazione PyPI mancava di un’efficace verifica dell’identità dello sviluppatore e della legittimità del nome del pacchetto.
• Consapevolezza della Sicurezza degli Sviluppatori: Gli sviluppatori potrebbero aver installato erroneamente i pacchetti dannosi con nomi simili.

Classificazione Evento VERIZON: Ingegneria Sociale

Mappatura Framework MITRE ATT&CK:

• T1593.003 (Search Open Websites/Domains - Search Publicly Available Dependency Repository): Gli aggressori hanno cercato informazioni su PyPI.
• T1195.002 (Supply Chain Compromise - Compromise Software Supply Chain): Gli aggressori hanno utilizzato malware mascherato da dipendenze Python e lo hanno caricato su PyPI.
• T1059.006 (Command and Scripting Interpreter - Python): Gli aggressori hanno impiantato codice dannoso nel pacchetto, che, all’esecuzione, ha fatto trapelare dati sensibili.
• T1041 (Exfiltration Over C2 Channel): Gli aggressori hanno esfiltrato informazioni sensibili tramite il canale C2 PipeDream.

Incidente 3: Dirottamento LLM – DeepSeek Preso di Mira per il Furto di Risorse

Cronologia: 7 febbraio 2025

Scala della Fuga di Dati: Circa 2 miliardi di token del modello utilizzati illegalmente.

Svolgimento degli Eventi:

Il team di ricerca sulle minacce Sysdig ha inizialmente scoperto un nuovo attacco mirato agli LLM, soprannominato ‘LLM jacking’ o ‘LLM hijacking’, nel maggio 2024.

A settembre 2024, Sysdig ha segnalato una crescente frequenza e prevalenza di questi attacchi, con DeepSeek che diventava sempre più un bersaglio.

Il 26 dicembre 2024, DeepSeek ha rilasciato un modello avanzato, DeepSeek-V3. Poco dopo, il team Sysdig ha scoperto che DeepSeek-V3 era stato implementato in un progetto di reverse proxy OpenAI (ORP) ospitato su Hugging Face.

Il 20 gennaio 2025, DeepSeek ha rilasciato un modello di inferenza chiamato DeepSeek-R1. Il giorno successivo, è apparso un progetto ORP che supportava DeepSeek-R1 e gli aggressori hanno iniziato a sfruttarlo, popolando più ORP con chiavi API DeepSeek.

La ricerca di Sysdig ha indicato che il numero totale di token di modelli di grandi dimensioni utilizzati illegalmente tramite ORP aveva superato i 2 miliardi.

Sezionando l’Attacco:

Il dirottamento LLM prevede che gli aggressori sfruttino le credenziali cloud rubate per prendere di mira i servizi LLM ospitati nel cloud. Gli aggressori sfruttano un reverse proxy OAI (OpenAI) e le credenziali rubate per vendere essenzialmente l’accesso ai servizi LLM sottoscritti dalla vittima. Ciò comporta costi significativi per i servizi cloud per la vittima.

Il reverse proxy OAI funge da punto di gestione centrale per l’accesso a più account LLM, mascherando le credenziali sottostanti e i pool di risorse. Gli aggressori possono utilizzare LLM costosi come DeepSeek senza pagarli, indirizzando le richieste attraverso il reverse proxy, consumando risorse e aggirando gli addebiti di servizio legittimi. Il meccanismo proxy nasconde l’identità dell’aggressore, consentendogli di utilizzare in modo improprio le risorse cloud senza essere rilevato.

Mentre il reverse proxy OAI è un componente necessario per il dirottamento LLM, l’elemento cruciale è il furto di credenziali e chiavi per vari servizi LLM. Gli aggressori spesso sfruttano le vulnerabilità e gli errori di configurazione dei servizi web tradizionali (come la vulnerabilità CVE-2021-3129 nel framework Laravel) per rubare queste credenziali. Una volta ottenute, queste credenziali garantiscono l’accesso a servizi LLM basati sul cloud come Amazon Bedrock, Google Cloud Vertex AI e altri.

La ricerca di Sysdig ha rivelato che gli aggressori potevano gonfiare rapidamente i costi di consumo delle vittime a decine di migliaia di dollari in poche ore e, in alcuni casi, fino a $ 100.000 al giorno. La motivazione degli aggressori va oltre l’acquisizione di dati; traggono anche profitto vendendo diritti di accesso.

Classificazione Evento VERIZON: Attacchi Base alle Applicazioni Web

Mappatura Framework MITRE ATT&CK:

• T1593 (Search Open Websites/Domains): Gli aggressori hanno utilizzato metodi OSINT (Open-Source Intelligence) per raccogliere informazioni sui servizi esposti.
• T1133 (External Remote Services): Gli aggressori hanno identificato vulnerabilità nei servizi esposti.
• T1586.003 (Compromise Accounts - Cloud Accounts): Gli aggressori hanno sfruttato le vulnerabilità per rubare credenziali di servizi LLM o servizi cloud.
• T1588.002 (Obtain Capabilities - Tool): Gli aggressori hanno implementato uno strumento di reverse proxy OAI open-source.
• T1090.002 (Proxy - External Proxy): Gli aggressori hanno utilizzato un software di reverse proxy OAI per gestire l’accesso a più account LLM.
• T1496 (Resource Hijacking): Gli aggressori hanno lanciato un attacco di iniezione LLM per dirottare le risorse LLM.

Incidente 4: Violazione dei Dati OmniGPT – Dati Utente Venduti sul Dark Web

Cronologia: 12 febbraio 2025

Scala della Fuga di Dati: Informazioni personali di oltre 30.000 utenti, inclusi email, numeri di telefono, chiavi API, chiavi di crittografia, credenziali e informazioni di fatturazione.

Svolgimento degli Eventi:

Il 12 febbraio 2025, un utente di nome ‘SyntheticEmotions’ ha pubblicato su BreachForums, affermando di aver rubato dati sensibili dalla piattaforma OmniGPT e offrendoli in vendita. I dati trapelati includevano presumibilmente email, numeri di telefono, chiavi API, chiavi di crittografia, credenziali e informazioni di fatturazione per oltre 30.000 utenti OmniGPT, insieme a oltre 34 milioni di righe delle loro conversazioni con i chatbot. Inoltre, sono stati compromessi i collegamenti ai file caricati sulla piattaforma, alcuni dei quali contenevano informazioni sensibili come voucher e dati di fatturazione.

Sezionando l’Attacco:

Sebbene il preciso vettore di attacco rimanga sconosciuto, il tipo e l’ambito dei dati trapelati suggeriscono diverse possibilità: iniezione SQL, abuso di API o attacchi di ingegneria sociale potrebbero aver concesso all’aggressore l’accesso al database backend. È anche possibile che la piattaforma OmniGPT presentasse configurazioni errate o vulnerabilità che hanno consentito all’aggressore di aggirare l’autenticazione e accedere direttamente al database contenente le informazioni dell’utente.

Il file ‘Messages.txt’ coinvolto in una fuga di dati secondaria conteneva chiavi API, credenziali del database e informazioni sulla carta di pagamento, potenzialmente consentendo ulteriori intrusioni in altri sistemi o manomissioni dei dati. Alcuni documenti caricati dagli utenti della piattaforma contenevano segreti aziendali sensibili e dati di progetto, rappresentando un rischio per le operazioni aziendali in caso di uso improprio. Questo incidente serve come un forte promemoria della necessità di una maggiore sicurezza dei dati e protezione della privacy nei settori dell’intelligenza artificiale e dei big data. Gli utenti dovrebbero prestare estrema cautela quando utilizzano queste piattaforme e le organizzazioni devono stabilire rigorose politiche di utilizzo dei dati, implementando misure come la crittografia, la minimizzazione dei dati e l’anonimizzazione per i dati sensibili. In caso contrario, si possono verificare significative conseguenze legali, reputazionali ed economiche.

Classificazione Evento VERIZON: Errori Vari

Mappatura Framework MITRE ATT&CK:

• T1071.001 (Application Layer Protocol - Web Protocols): Gli aggressori potrebbero aver avuto accesso a informazioni utente trapelate e dati sensibili tramite l’interfaccia web di OmniGPT.
• T1071.002 (Application Layer Protocol - Application Programming Interfaces): Le chiavi API e le credenziali del database trapelate potrebbero consentire agli aggressori di accedere al sistema tramite l’API della piattaforma ed eseguire azioni non autorizzate.
• T1071.002 (Application Layer Protocol - Service Execution): Gli aggressori potrebbero abusare dei servizi di sistema o dei demoni per eseguire comandi o programmi.
• T1020.003 (Automated Exfiltration - File Transfer): I collegamenti ai file trapelati e i file sensibili caricati dall’utente potrebbero essere obiettivi per gli aggressori da scaricare, ottenendo dati più sensibili per attacchi successivi.
• T1083 (File and Directory Discovery): Gli aggressori potrebbero utilizzare le informazioni trapelate per ottenere ulteriori informazioni aziendali chiave.

Incidente 5: Credenziali DeepSeek Trapelate in Common Crawl – I Pericoli dell’Hard-Coding

Cronologia: 28 febbraio 2025

Scala della Fuga di Dati: Circa 11.908 chiavi API, credenziali e token di autenticazione DeepSeek validi.

Svolgimento degli Eventi:

Il team di sicurezza di Truffle ha utilizzato lo strumento open-source TruffleHog per scansionare 400 TB di dati da dicembre 2024 in Common Crawl, un database di crawler che comprende 2,67 miliardi di pagine web da 47,5 milioni di host. La scansione ha rivelato una scoperta sorprendente: circa 11.908 chiavi API, credenziali e token di autenticazione DeepSeek validi erano codificati direttamente in numerose pagine web.

Lo studio ha anche evidenziato la fuga di chiavi API Mailchimp, con circa 1.500 chiavi trovate hard-coded nel codice JavaScript. Le chiavi API Mailchimp sono spesso sfruttate per attacchi di phishing e furto di dati.

Sezionando l’Attacco:

Common Crawl, un database di crawler web senza scopo di lucro, acquisisce e pubblica regolarmente dati da pagine Internet. Memorizza questi dati in file WARC (Web ARChive), preservando l’HTML originale, il codice JavaScript e le risposte del server. Questi set di dati vengono spesso utilizzati per addestrare modelli di intelligenza artificiale. La ricerca di Truffle espone un problema critico: l’addestramento di modelli su corpora contenenti vulnerabilità di sicurezza può portare i modelli a ereditare tali vulnerabilità. Anche se gli LLM come DeepSeek impiegano misure di sicurezza aggiuntive durante l’addestramento e l’implementazione, la diffusa presenza di vulnerabilità hard-coded nei dati di addestramento può normalizzare tali pratiche ‘non sicure’ per i modelli.

L’hard-coding, una pratica di codifica comune ma insicura, è un problema pervasivo. Mentre la causa principale è semplice, i rischi sono gravi: violazioni di dati, interruzioni del servizio, attacchi alla supply chain e, con l’ascesa degli LLM, una nuova minaccia: il dirottamento LLM. Come discusso in precedenza, il dirottamento LLM prevede che gli aggressori utilizzino credenziali rubate per sfruttare i servizi LLM ospitati nel cloud, con conseguenti perdite finanziarie sostanziali per le vittime.

Classificazione Evento VERIZON: Errori Vari

Mappatura Framework MITRE ATT&CK:

• T1596.005 (Search Open Technical Database - Scan Databases): Gli aggressori hanno raccolto informazioni dal database pubblico del crawler.
• T1588.002 (Obtain Capabilities - Tool): Gli aggressori hanno implementato uno strumento di rilevamento di informazioni sensibili.
• T1586.003 (Compromise Accounts - Cloud Accounts): Gli aggressori hanno utilizzato strumenti di rilevamento di informazioni sensibili per trovare credenziali sensibili nei database pubblici.
• T1090.002 (Proxy - External Proxy): Gli aggressori hanno utilizzato un software di reverse proxy OAI per gestire l’accesso a più account LLM.
• T1496 (Resource Hijacking): Gli aggressori hanno lanciato un attacco di iniezione LLM per dirottare le risorse LLM.

Prevenire la Fuga di Dati LLM: Un Approccio Multiforme

Gli incidenti analizzati evidenziano l’urgente necessità di solide misure di sicurezza per proteggersi dalle violazioni di dati relative agli LLM. Ecco una ripartizione delle strategie preventive, classificate in base agli incidenti pertinenti:

Rafforzare la Supply Chain:

Applicabile all’Incidente II (attacco dannoso al pacchetto di dipendenze) e all’Incidente V (violazione dei dati pubblici):

1. Verifica Affidabile dei Pacchetti di Dipendenze:

   • Utilizzare strumenti come PyPI/Sonatype Nexus Firewall per intercettare pacchetti di dipendenze non firmati o provenienti da fonti sospette.
   • Vietare il recupero diretto delle dipendenze dai repository pubblici negli ambienti di sviluppo. Imporre l’uso di proxy di repository privati aziendali (ad esempio, Artifactory).

2. Monitoraggio delle Minacce alla Supply Chain:

   • Integrare strumenti come Dependabot/Snyk per scansionare automaticamente le vulnerabilità delle dipendenze e bloccare l’introduzione di componenti ad alto rischio.
   • Verificare la firma del codice dei pacchetti open-source per garantire che il valore hash corrisponda a quello ufficiale.

3. Pulizia della Fonte dei Dati:

   • Durante la raccolta dei dati di addestramento, filtrare le informazioni sensibili dai set di dati pubblici (come Common Crawl) utilizzando espressioni regolari e strumenti di redazione basati sull’intelligenza artificiale per una doppia verifica.

Implementazione del Minimo Privilegio e del Controllo degli Accessi:

Applicabile all’Incidente I (errore di configurazione del database) e all’Incidente IV (violazione dei dati di strumenti di terze parti):

• Abilitare l’autenticazione TLS bidirezionale per impostazione predefinita per i database (come ClickHouse) e impedire l’esposizione delle porte di gestione sulle reti pubbliche.
• Utilizzare soluzioni come Vault/Boundary per distribuire dinamicamente credenziali temporanee, evitando la conservazione di chiavi statiche a lungo termine.
• Aderire al principio del minimo privilegio, limitando l’accesso degli utenti solo alle risorse necessarie tramite RBAC (Role-Based Access Control).
• Implementare il whitelisting IP e il rate limiting per le chiamate API a strumenti di terze parti (come OmniGPT).

Garantire la Protezione del Ciclo di Vita Completo dei Dati Sensibili:

Applicabile all’Incidente III (dirottamento LLM):

• Redazione e Crittografia dei Dati: Applicare la crittografia a livello di campo (ad esempio, AES-GCM) per i dati di input e output dell’utente. Mascherare i campi sensibili nei log.
• Abilitare la redazione in tempo reale per il contenuto interattivo degli LLM (ad esempio, sostituendo numeri di carte di credito e numeri di telefono con segnaposto).

Queste misure preventive, combinate con il monitoraggio continuo della sicurezza e la pianificazione della risposta agli incidenti, sono essenziali per mitigare i rischi associati al crescente utilizzo degli LLM. Il ‘campo di battaglia invisibile’ della sicurezza LLM richiede una vigilanza costante e un approccio proattivo per salvaguardare i dati sensibili in questo panorama tecnologico in rapida evoluzione.