Datenkrieg im Open-Source-LLM-Zeitalter

Eine Welle von Sicherheitsverletzungen enthüllt Schwachstellen

Die rasche Verbreitung von Open-Source Large Language Models (LLMs) wie DeepSeek und Ollama hat sich als zweischneidiges Schwert erwiesen. Während Unternehmen diese leistungsstarken Tools zur Effizienzsteigerung einsetzen, führt die Offenheit, die ihr Wachstum antreibt, zu einem parallelen Anstieg der Datensicherheitsrisiken. Ein aktueller Bericht des NSFOCUS Xingyun Lab zeichnet ein düsteres Bild: Allein in den ersten beiden Monaten des Jahres 2025 wurden weltweit fünf signifikante Datenlecks direkt mit LLMs in Verbindung gebracht. Diese Vorfälle führten zur Offenlegung riesiger Mengen sensibler Informationen, von vertraulichen Chatverläufen und API-Schlüsseln bis hin zu kritischen Benutzeranmeldeinformationen. Diese Ereignisse sind ein Weckruf und verdeutlichen die oft übersehenen Sicherheitslücken, die unter der Oberfläche modernster KI-Technologie lauern. Diese Untersuchung wird diese fünf Vorfälle analysieren, die Angriffsmethoden sezieren, sie dem etablierten MITRE ATT&CK-Framework zuordnen und die Sicherheitslücken aufzeigen, die Unternehmen dringend angehen müssen.

Vorfall 1: DeepSeeks fehlkonfigurierte Datenbank – Ein Fenster in private Gespräche

Zeitpunkt: 29. Januar 2025

Ausmaß des Lecks: Millionen von Zeilen an Protokolldaten, einschließlich sensibler Chatverläufe und Zugriffsschlüssel.

Entfaltung der Ereignisse:

Das Sicherheitsforschungsteam von Wiz initiierte diese Entdeckung. Sie identifizierten einen exponierten ClickHouse-Dienst, der über das öffentliche Internet zugänglich war. Weitere Untersuchungen bestätigten, dass dieser Dienst dem chinesischen KI-Startup DeepSeek gehörte. ClickHouse, das für die effiziente Verarbeitung großer Datenmengen in der analytischen Verarbeitung entwickelt wurde, wurde leider zu einem Gateway zu den internen Daten von DeepSeek. Die Forscher griffen auf etwa eine Million Zeilen des DeepSeek-Protokollstroms zu und enthüllten eine Fundgrube sensibler Informationen, darunter historische Chatprotokolle und wichtige Zugriffsschlüssel.

Wiz informierte DeepSeek umgehend über die Schwachstelle, was zu sofortigen Maßnahmen und der sicheren Beseitigung des exponierten ClickHouse-Dienstes führte.

Sezierung des Angriffs:

Das Kernproblem lag in der Anfälligkeit von ClickHouse für unbefugten Zugriff. ClickHouse, ein Open-Source-spaltenorientiertes Datenbankmanagementsystem, zeichnet sich durch Echtzeitabfrage und -analyse massiver Datenmengen aus und wird häufig für die Protokoll- und Benutzerverhaltensanalyse verwendet. Wenn es jedoch ohne ordnungsgemäße Zugriffskontrollen bereitgestellt wird, ermöglicht seine exponierte API-Schnittstelle jedem, SQL-ähnliche Befehle auszuführen.

Der Ansatz des Wiz-Sicherheitsteams umfasste einen methodischen Scan der dem Internet zugewandten Subdomains von DeepSeek. Zunächst konzentrierten sie sich auf die Standardports 80 und 443 und fanden typische Webressourcen wie Chatbot-Schnittstellen und API-Dokumentationen. Um ihre Suche zu erweitern, dehnten sie sie auf weniger gebräuchliche Ports wie 8123 und 9000 aus und entdeckten schließlich exponierte Dienste auf mehreren Subdomains.

Die kompromittierten Protokolldaten, die bis zum 6. Januar 2025 zurückreichen, enthielten eine Fülle sensibler Informationen: Anrufprotokolle, Textprotokolle für interne DeepSeek-API-Endpunkte, detaillierte Chatverläufe, API-Schlüssel, Details zum Backend-System und Betriebsmetadaten.

VERIZON-Ereignisklassifizierung: Sonstige Fehler

MITRE ATT&CK Framework-Zuordnung:

• T1590.002 (Collect Victim Network Information - Domain Name Resolution): Angreifer haben wahrscheinlich den primären Domänennamen verwendet, um eine Subdomain-Enumeration durchzuführen.
• T1046 (Web Service Discovery): Die Angreifer identifizierten offene Ports und Dienste, die der Zieldomäne zugeordnet sind.
• T1106 (Native Interface): Die Angreifer nutzten die ClickHouse-API, um mit der Datenbank zu interagieren.
• T1567 (Data Exfiltration via Web Service): Die Angreifer nutzten die ClickHouse-API, um Daten zu stehlen.

Vorfall 2: DeepSeeks Supply-Chain-Angriff – Ein Trojanisches Pferd im Code

Zeitpunkt: 3. Februar 2025

Ausmaß des Lecks: Benutzeranmeldeinformationen und Umgebungsvariablen.

Entfaltung der Ereignisse:

Der Angriff begann am 19. Januar 2025, als ein böswilliger Benutzer, identifiziert als ‘bvk’, zwei schädliche Python-Pakete namens ‘deepseek’ und ‘deepseekai’ in das beliebte PyPI (Python Package Index)-Repository hochlud.

Das Threat-Intelligence-Team des Positive Technologies Expert Security Center (PT ESC) entdeckte diese verdächtige Aktivität am selben Tag. Ihre Analyse bestätigte die bösartige Natur der Pakete, und sie benachrichtigten umgehend die PyPI-Administratoren.

Die PyPI-Administratoren entfernten die schädlichen Pakete schnell und informierten PT ESC. Trotz der schnellen Reaktion zeigten Statistiken, dass die Malware über verschiedene Kanäle über 200 Mal in 17 Ländern heruntergeladen worden war. Die schädlichen Pakete wurden anschließend isoliert.

Sezierung des Angriffs:

Die von ‘bvk’ hochgeladenen schädlichen Pakete konzentrierten sich auf zwei Hauptziele: Informationsbeschaffung und Diebstahl von Umgebungsvariablen. Die gestohlenen Daten enthielten sensible Informationen wie Datenbankanmeldeinformationen, API-Schlüssel und Zugriffsberechtigungen für S3-Objektspeicher. Die schädliche Nutzlast wurde immer dann ausgelöst, wenn ein Benutzer DeepSeek oder Deepseekai von der Befehlszeile aus ausführte.

Der Angreifer nutzte PipeDream als Command-and-Control-Server, um die gestohlenen Daten zu empfangen. Der Vorfall beleuchtet mehrere Faktoren, die dazu beigetragen haben:

• Dependency Confusion Attack: Die Angreifer nutzten den Prioritätsunterschied zwischen den privaten Paketen einer Organisation und öffentlichen Paketen mit demselben Namen aus.
• Package Name Impersonation: Die schädlichen Pakete ahmten den Markennamen von DeepSeek, einem bekannten KI-Unternehmen, nach, um Benutzer zu täuschen.
• PyPI Registration Weakness: Dem PyPI-Registrierungsprozess fehlte eine effektive Überprüfung der Entwickleridentität und der Legitimität des Paketnamens.
• Developer Security Awareness: Entwickler haben möglicherweise versehentlich die ähnlich benannten schädlichen Pakete installiert.

VERIZON-Ereignisklassifizierung: Social Engineering

MITRE ATT&CK Framework-Zuordnung:

• T1593.003 (Search Open Websites/Domains - Search Publicly Available Dependency Repository): Die Angreifer suchten nach Informationen auf PyPI.
• T1195.002 (Supply Chain Compromise - Compromise Software Supply Chain): Die Angreifer verwendeten Malware, die als Python-Abhängigkeiten getarnt war, und luden sie auf PyPI hoch.
• T1059.006 (Command and Scripting Interpreter - Python): Die Angreifer implantierten schädlichen Code in das Paket, der bei Ausführung sensible Daten preisgab.
• T1041 (Exfiltration Over C2 Channel): Die Angreifer exfiltrierten sensible Informationen über den PipeDream C2-Kanal.

Vorfall 3: LLM-Hijacking – DeepSeek als Ziel für Ressourcendiebstahl

Zeitpunkt: 7. Februar 2025

Ausmaß des Lecks: Ungefähr 2 Milliarden Modell-Token wurden illegal verwendet.

Entfaltung der Ereignisse:

Das Sysdig-Threat-Research-Team entdeckte im Mai 2024 erstmals einen neuartigen Angriff auf LLMs, der als ‘LLM-Jacking’ oder ‘LLM-Hijacking’ bezeichnet wird.

Bis September 2024 berichtete Sysdig über eine zunehmende Häufigkeit und Verbreitung dieser Angriffe, wobei DeepSeek zunehmend zum Ziel wurde.

Am 26. Dezember 2024 veröffentlichte DeepSeek ein fortschrittliches Modell, DeepSeek-V3. Kurz darauf stellte das Sysdig-Team fest, dass DeepSeek-V3 in einem OpenAI-Reverse-Proxy (ORP)-Projekt implementiert wurde, das auf Hugging Face gehostet wird.

Am 20. Januar 2025 veröffentlichte DeepSeek ein Inferenzmodell namens DeepSeek-R1. Bereits am nächsten Tag erschien ein ORP-Projekt, das DeepSeek-R1 unterstützte, und Angreifer begannen, es auszunutzen, indem sie mehrere ORPs mit DeepSeek-API-Schlüsseln füllten.

Die Forschung von Sysdig ergab, dass die Gesamtzahl der großen Modell-Token, die illegal über ORPs verwendet wurden, 2 Milliarden überschritten hatte.

Sezierung des Angriffs:

Beim LLM-Hijacking nutzen Angreifer gestohlene Cloud-Anmeldeinformationen, um auf in der Cloud gehostete LLM-Dienste zuzugreifen. Die Angreifer nutzen einen OAI (OpenAI)-Reverse-Proxy und gestohlene Anmeldeinformationen, um im Wesentlichen den Zugriff auf die abonnierten LLM-Dienste des Opfers zu verkaufen. Dies führt zu erheblichen Cloud-Service-Kosten für das Opfer.

Der OAI-Reverse-Proxy fungiert als zentraler Verwaltungspunkt für den Zugriff auf mehrere LLM-Konten und maskiert die zugrunde liegenden Anmeldeinformationen und Ressourcenpools. Angreifer können teure LLMs wie DeepSeek verwenden, ohne dafür zu bezahlen, indem sie Anfragen über den Reverse-Proxy leiten, Ressourcen verbrauchen und legitime Servicegebühren umgehen. Der Proxy-Mechanismus verbirgt die Identität des Angreifers und ermöglicht ihm, Cloud-Ressourcen unentdeckt zu missbrauchen.

Während der OAI-Reverse-Proxy eine notwendige Komponente für das LLM-Hijacking ist, ist das entscheidende Element der Diebstahl von Anmeldeinformationen und Schlüsseln für verschiedene LLM-Dienste. Angreifer nutzen häufig traditionelle Webdienst-Schwachstellen und Konfigurationsfehler (wie die Schwachstelle CVE-2021-3129 im Laravel-Framework), um diese Anmeldeinformationen zu stehlen. Sobald diese Anmeldeinformationen erlangt wurden, gewähren sie Zugriff auf Cloud-basierte LLM-Dienste wie Amazon Bedrock, Google Cloud Vertex AI und andere.

Die Forschung von Sysdig ergab, dass Angreifer die Verbrauchskosten der Opfer innerhalb von Stunden schnell auf Zehntausende von Dollar und in einigen Fällen auf bis zu 100.000 Dollar pro Tag erhöhen konnten. Die Motivation der Angreifer geht über die Datenerfassung hinaus; sie profitieren auch vom Verkauf von Zugriffsrechten.

VERIZON-Ereignisklassifizierung: Grundlegende Webanwendungsangriffe

MITRE ATT&CK Framework-Zuordnung:

• T1593 (Search Open Websites/Domains): Angreifer verwendeten OSINT (Open-Source Intelligence)-Methoden, um Informationen über exponierte Dienste zu sammeln.
• T1133 (External Remote Services): Die Angreifer identifizierten Schwachstellen in exponierten Diensten.
• T1586.003 (Compromise Accounts - Cloud Accounts): Angreifer nutzten Schwachstellen aus, um LLM-Dienst- oder Cloud-Dienst-Anmeldeinformationen zu stehlen.
• T1588.002 (Obtain Capabilities - Tool): Die Angreifer setzten ein Open-Source-OAI-Reverse-Proxy-Tool ein.
• T1090.002 (Proxy - External Proxy): Angreifer verwendeten OAI-Reverse-Proxy-Software, um den Zugriff auf mehrere LLM-Konten zu verwalten.
• T1496 (Resource Hijacking): Angreifer starteten einen LLM-Injektionsangriff, um LLM-Ressourcen zu kapern.

Vorfall 4: OmniGPT-Datenleck – Benutzerdaten im Dark Web verkauft

Zeitpunkt: 12. Februar 2025

Ausmaß des Lecks: Persönliche Daten von über 30.000 Benutzern, einschließlich E-Mails, Telefonnummern, API-Schlüsseln, Verschlüsselungsschlüsseln, Anmeldeinformationen und Rechnungsinformationen.

Entfaltung der Ereignisse:

Am 12. Februar 2025 postete ein Benutzer namens ‘SyntheticEmotions’ auf BreachForums und behauptete, sensible Daten von der OmniGPT-Plattform gestohlen zu haben und sie zum Verkauf anzubieten. Die durchgesickerten Daten enthielten angeblich E-Mails, Telefonnummern, API-Schlüssel, Verschlüsselungsschlüssel, Anmeldeinformationen und Rechnungsinformationen für über 30.000 OmniGPT-Benutzer sowie über 34 Millionen Zeilen ihrer Gespräche mit Chatbots. Darüber hinaus wurden Links zu Dateien kompromittiert, die auf die Plattform hochgeladen wurden, von denen einige sensible Informationen wie Gutscheine und Rechnungsdaten enthielten.

Sezierung des Angriffs:

Während der genaue Angriffsvektor nicht bekannt ist, deuten Art und Umfang der durchgesickerten Daten auf mehrere Möglichkeiten hin: SQL-Injektion, API-Missbrauch oder Social-Engineering-Angriffe könnten dem Angreifer Zugriff auf die Backend-Datenbank gewährt haben. Es ist auch möglich, dass die OmniGPT-Plattform Fehlkonfigurationen oder Schwachstellen aufwies, die es dem Angreifer ermöglichten, die Authentifizierung zu umgehen und direkt auf die Datenbank mit Benutzerinformationen zuzugreifen.

Die Datei ‘Messages.txt’, die an einem sekundären Leck beteiligt war, enthielt API-Schlüssel, Datenbankanmeldeinformationen und Zahlungskarteninformationen, was möglicherweise weitere Eingriffe in andere Systeme oder Datenmanipulationen ermöglichte. Einige von Plattformbenutzern hochgeladene Dokumente enthielten sensible Geschäftsgeheimnisse und Projektdaten, die bei Missbrauch ein Risiko für den Geschäftsbetrieb darstellen. Dieser Vorfall ist eine deutliche Erinnerung an die Notwendigkeit einer verbesserten Datensicherheit und eines besseren Datenschutzes im KI- und Big-Data-Sektor. Benutzer sollten bei der Nutzung dieser Plattformen äußerste Vorsicht walten lassen, und Organisationen müssen strenge Datenverwendungsrichtlinien festlegen und Maßnahmen wie Verschlüsselung, Datenminimierung und Anonymisierung für sensible Daten implementieren. Andernfalls kann dies zu erheblichen rechtlichen, rufschädigenden und wirtschaftlichen Konsequenzen führen.

VERIZON-Ereignisklassifizierung: Sonstige Fehler

MITRE ATT&CK Framework-Zuordnung:

• T1071.001 (Application Layer Protocol - Web Protocols): Angreifer haben möglicherweise über die Weboberfläche von OmniGPT auf durchgesickerte Benutzerinformationen und sensible Daten zugegriffen.
• T1071.002 (Application Layer Protocol - Application Programming Interfaces): Durchgesickerte API-Schlüssel und Datenbankanmeldeinformationen könnten Angreifern ermöglichen, über die API der Plattform auf das System zuzugreifen und nicht autorisierte Aktionen durchzuführen.
• T1071.002 (Application Layer Protocol - Service Execution): Angreifer könnten Systemdienste oder Daemons missbrauchen, um Befehle oder Programme auszuführen.
• T1020.003 (Automated Exfiltration - File Transfer): Durchgesickerte Dateilinks und von Benutzern hochgeladene sensible Dateien könnten Ziele für Angreifer sein, um sie herunterzuladen und weitere sensible Daten für nachfolgende Angriffe zu erhalten.
• T1083 (File andDirectory Discovery): Angreifer könnten die durchgesickerten Informationen verwenden, um weitere wichtige Geschäftsinformationen zu erhalten.

Vorfall 5: DeepSeek-Anmeldeinformationen in Common Crawl durchgesickert – Die Gefahren des Hardcodings

Zeitpunkt: 28. Februar 2025

Ausmaß des Lecks: Ungefähr 11.908 gültige DeepSeek-API-Schlüssel, Anmeldeinformationen und Authentifizierungstoken.

Entfaltung der Ereignisse:

Das Truffle-Sicherheitsteam nutzte das Open-Source-Tool TruffleHog, um 400 TB Daten vom Dezember 2024 in Common Crawl zu scannen, einer Crawler-Datenbank, die 2,67 Milliarden Webseiten von 47,5 Millionen Hosts umfasst. Der Scan ergab ein erschreckendes Ergebnis: Ungefähr 11.908 gültige DeepSeek-API-Schlüssel, Anmeldeinformationen und Authentifizierungstoken waren direkt in zahlreiche Webseiten hartcodiert.

Die Studie hob auch das Durchsickern von Mailchimp-API-Schlüsseln hervor, wobei etwa 1.500 Schlüssel im JavaScript-Code hartcodiert gefunden wurden. Mailchimp-API-Schlüssel werden häufig für Phishing- und Datendiebstahl-Angriffe ausgenutzt.

Sezierung des Angriffs:

Common Crawl, eine gemeinnützige Web-Crawler-Datenbank, erfasst und veröffentlicht regelmäßig Daten von Internetseiten. Es speichert diese Daten in WARC (Web ARChive)-Dateien und bewahrt den ursprünglichen HTML-, JavaScript-Code und die Serverantworten. Diese Datensätze werden häufig zum Trainieren von KI-Modellen verwendet. Die Forschung von Truffle deckt ein kritisches Problem auf: Das Trainieren von Modellen auf Korpora, die Sicherheitslücken enthalten, kann dazu führen, dass Modelle diese Schwachstellen erben. Selbst wenn LLMs wie DeepSeek während des Trainings und der Bereitstellung zusätzliche Sicherheitsmaßnahmen einsetzen, kann das weit verbreitete Vorhandensein hartcodierter Schwachstellen in den Trainingsdaten solche ‘unsicheren’ Praktiken für die Modelle normalisieren.

Hardcoding, eine übliche, aber unsichere Codierungspraxis, ist ein allgegenwärtiges Problem. Während die Ursache einfach ist, sind die Risiken schwerwiegend: Datenlecks, Dienstunterbrechungen, Supply-Chain-Angriffe und mit dem Aufkommen von LLMs eine neue Bedrohung – LLM-Hijacking. Wie bereits erwähnt, beinhaltet LLM-Hijacking, dass Angreifer gestohlene Anmeldeinformationen verwenden, um in der Cloud gehostete LLM-Dienste auszunutzen, was zu erheblichen finanziellen Verlusten für die Opfer führt.

VERIZON-Ereignisklassifizierung: Sonstige Fehler

MITRE ATT&CK Framework-Zuordnung:

• T1596.005 (Search Open Technical Database - Scan Databases): Die Angreifer sammelten Informationen aus der öffentlichen Crawler-Datenbank.
• T1588.002 (Obtain Capabilities - Tool): Die Angreifer setzten ein Tool zur Erkennung sensibler Informationen ein.
• T1586.003 (Compromise Accounts - Cloud Accounts): Angreifer verwendeten Tools zur Erkennung sensibler Informationen, um sensible Anmeldeinformationen in öffentlichen Datenbanken zu finden.
• T1090.002 (Proxy - External Proxy): Angreifer verwendeten OAI-Reverse-Proxy-Software, um den Zugriff auf mehrere LLM-Konten zu verwalten.
• T1496 (Resource Hijacking): Angreifer starteten einen LLM-Injektionsangriff, um LLM-Ressourcen zu kapern.

Verhinderung von LLM-Datenlecks: Ein vielschichtiger Ansatz

Die analysierten Vorfälle unterstreichen die dringende Notwendigkeit robuster Sicherheitsmaßnahmen zum Schutz vor LLM-bezogenen Datenlecks. Hier ist eine Aufschlüsselung der Präventionsstrategien, kategorisiert nach den relevanten Vorfällen:

Stärkung der Lieferkette:

Anwendbar auf Vorfall II (Angriff mit schädlichem Abhängigkeitspaket) und Vorfall V (Verletzung öffentlicher Daten):

1. Vertrauenswürdige Überprüfung von Abhängigkeitspaketen:

   • Verwenden Sie Tools wie PyPI/Sonatype Nexus Firewall, um nicht signierte oder verdächtig bezogene Abhängigkeitspakete abzufangen.
   • Verbieten Sie das direkte Abrufen von Abhängigkeiten aus öffentlichen Repositorys in Entwicklungsumgebungen. Verlangen Sie die Verwendung von unternehmenseigenen privaten Repository-Proxys (z. B. Artifactory).

2. Überwachung von Bedrohungen in der Lieferkette:

   • Integrieren Sie Tools wie Dependabot/Snyk, um automatisch nach Abhängigkeitsschwachstellen zu suchen und die Einführung von Hochrisikokomponenten zu blockieren.
   • Überprüfen Sie die Codesignatur von Open-Source-Paketen, um sicherzustellen, dass der Hash-Wert mit dem offiziellen übereinstimmt.

3. Bereinigung der Datenquelle:

   • Filtern Sie während der Erfassung von Trainingsdaten sensible Informationen aus öffentlichen Datensätzen (wie Common Crawl) mithilfe regulärer Ausdrücke und KI-basierter Schwärzungstools zur doppelten Überprüfung.

Implementierung des Prinzips der geringsten Rechte und Zugriffskontrolle:

Anwendbar auf Vorfall I (Datenbankkonfigurationsfehler) und Vorfall IV (Datenleck bei Drittanbietertools):

• Aktivieren Sie standardmäßig die bidirektionale TLS-Authentifizierung für Datenbanken (wie ClickHouse) und verhindern Sie die Exposition von Management-Ports in öffentlichen Netzwerken.
• Verwenden Sie Lösungen wie Vault/Boundary, um temporäre Anmeldeinformationen dynamisch zu verteilen und die langfristige Aufbewahrung statischer Schlüssel zu vermeiden.
• Halten Sie sich an das Prinzip der geringsten Rechte und beschränken Sie den Benutzerzugriff auf nur notwendige Ressourcen durch RBAC (Role-Based Access Control).
• Implementieren Sie IP-Whitelisting und Ratenbegrenzung für API-Aufrufe an Drittanbietertools (wie OmniGPT).

Gewährleistung des Schutzes sensibler Daten über den gesamten Lebenszyklus:

Anwendbar auf Vorfall III (LLM-Hijacking):

• Datenschwärzung und -verschlüsselung: Erzwingen Sie die Verschlüsselung auf Feldebene (z. B. AES-GCM) für Benutzereingabe- und -ausgabedaten. Maskieren Sie sensible Felder in Protokollen.
• Aktivieren Sie die Echtzeit-Schwärzung für den interaktiven Inhalt von LLMs (z. B. Ersetzen von Kreditkartennummern und Telefonnummern durch Platzhalter).

Diese Präventivmaßnahmen, kombiniert mit kontinuierlicher Sicherheitsüberwachung und Vorfallreaktionsplanung, sind unerlässlich, um die Risiken zu mindern, die mit der zunehmenden Nutzung von LLMs verbunden sind. Das ‘unsichtbare Schlachtfeld’ der LLM-Sicherheit erfordert ständige Wachsamkeit und einen proaktiven Ansatz zum Schutz sensibler Daten in dieser sich schnell entwickelnden Technologielandschaft.