Einführung

Unternehmen setzen auf GenAI, um Produktivität, Innovation und Wettbewerbsvorteile zu steigern. Cloud-Anbieter stellen hierfür mittlerweile GenAI-as-a-Service-Angebote bereit, wie zum Beispiel Amazon Bedrock, Azure AI Services, und Google Vertex AI. Diese GenAI-as-a-Service-Lösungen beschleunigen die Einführung von GenAI weiter, da sie die Eintrittsbarrieren für Unternehmen drastisch senken. Cloud-Workloads mit GenAI bringen jedoch verschiedene Sicherheits- und Schutzherausforderungen mit sich, die von Anwendern beachtet und adressiert werden müssen. Geeignete Gegenmaßnahmen ermöglichen es Unternehmen, verantwortungsvolle KI-Systeme zu gewährleisten, insbesondere angesichts der zunehmenden Forderungen nach KI-Sicherheit, wie etwa durch den EU AI Act. Leider hat ein aktueller Bericht von IBM und Oxford Economics gezeigt, dass 70 % der Führungskräfte bei GenAI-Strategien Innovation über Sicherheit stellen. Es ist daher unerlässlich, das Bewusstsein für praktische Angriffe auf GenAI-Systeme und deren potenzielle Auswirkungen zu schärfen.

GenAI-Cloud-Workloads: Die neuen attraktiven Ziele

Es ist nichts Neues, dass Angreifer dem Geld folgen, und GenAI-Cloud-Workloads entwickeln sich zunehmend zu einer lukrativen Einnahmequelle, die Aufmerksamkeit erfordert. Forscher bei Wiz bot bereits Anfang des Jahres einen Einblick in die aktuelle Bedrohungslandschaft durch generative KI, als sie mehrere Angriffsvektoren in SAP AI Coreentdeckten, dem führenden KI-Dienst von SAP. Die Forscher zeigten auf, wie Angreifer moderne Angriffsvektoren, wie z. B. IAM, mit KI-spezifischen Vektoren, wie z. B. Model Poisoning, kombinieren können, um komplexe Angriffe durchzuführen. Dies hat zweifellos verdeutlicht, wie komplexe Cloud-Technologien mit GenAI-Workloads die Anforderungen an die Cybersicherheit erhöhen.

‍

‍

LLMJacking – Eine Einführung

Einer der häufigsten Angriffe auf GenAI-Workloads ist LLMJacking. Bei einem LLMJacking-Angriff verschaffen sich Cyberkriminelle unbefugten Zugriff auf ein Large Language Model (LLM) und nutzen es nach Belieben. Das Hauptmotiv besteht darin, die enormen Kosten zu umgehen, die bei der Nutzung von Basismodellen auf Cloud-Plattformen anfallen (bis zu 46.000 US-Dollar LLM-Verbrauch pro Tag). Die meisten LLMJacking-Angriffe zielen auf Amazon Bedrock ab, das verschiedene Basismodelle führender KI-Unternehmen wie Anthropic, Cohere, Meta und Stability AI anbietet.  

‍

Ein aktueller Bericht von Permiso Security wies darauf hin, dass Bedrock in den letzten sechs Monaten einer der am häufigsten angegriffenen Cloud-Dienste war. LLMJacking-Angriffe stehen dabei im Vordergrund. Wenn Sie mit Bedrock, einschließlich dessen Aufbau und Architektur, noch nicht vertraut sind und erfahren möchten, wie man diese aus einer Sicherheitsperspektive betrachtet, lesen Sie unseren früheren Artikel, in dem mehrere Angriffsvektoren, einschließlich Data Poisoning, beschrieben wurden. Forscher bei Sysdig berichteten bereits früher über LLMJacking-Angriffe und veröffentlichten kürzlich einen ausführlichen Bericht mit weiteren technischen Details. Darüber hinaus lieferte KrebsonSecurity kürzlich auf Basis früherer Berichte zusätzliche Erkenntnisse zu LLMJacking-Angriffen. Diese Veröffentlichungen zeigen, wie lukrativ LLMJacking für diese Cyberkriminellen ist. Eine prominente kriminelle Organisation hinter diesen Angriffen hat einen annualisierten Umsatz von 1 Million US-Dollar erzielt. Das Geschäftsmodell basiert auf dem Verkauf von Sex-Chatbots. 

‍

LLMJacking lässt sich unter die Denial-of-Wallet (DoW)-Angriffe einordnen, bei denen die massive Nutzung von Prompts durch Angreifer die Nutzungskosten (Rechnungen) in die Höhe treibt. Dies beeinträchtigt letztlich die allgemeine Servicequalität oder führt sogar zu einem Denial-of-Service (man stelle sich vor, die legitime Nutzung wird aufgrund ausbleibender Zahlungen eingestellt). Beachten Sie, dass herkömmliche Gegenmaßnahmen gegen DoW auf Anwendungsebene bei LLMJacking-Angriffen in der Cloud wirkungslos sind.

LLMJacking – Angriffsschritte

Werfen wir einen kurzen Blick auf die typischen Schritte eines LLMJacking-Angriffs, basierend auf tatsächlich gemeldeten Vorfällen und den Möglichkeiten, die Bedrock bietet. 

1. Diebstahl des AWS-Keys: Der Angreifer verschafft sich auf verschiedene Weise unbefugten Zugriff auf einen AWS-Key, etwa durch den Kauf kompromittierter Keys von Initial-Access-Brokern, den Einsatz von Malware oder den Diebstahl von Keys aus Code-Repositories. Angreifer können auch andere Arten von Anmeldeinformationen verwenden, z. B. IAM-Rollen, und sind nicht zwingend auf AWS-Keys angewiesen.
2. Berechtigungsanalyse: Angreifer validieren die Berechtigungen des Keys und bestätigen den Zugriff auf Bedrock mithilfe von Tools wie dem AWS CLI oder dem IAM Policy Simulator. 
3. Bedrock-Aufklärung: Wenn Bedrock zugänglich ist, durchsuchen Angreifer den Dienst, um verfügbare Modelle, Agenten und Wissensdatenbanken zu entdecken. Dies ermöglicht es ihnen, die Funktionen von Bedrock in der jeweiligen Region zu bestimmen. Beachten Sie, dass Bedrock regional begrenzt ist; Angreifer könnten einfach die Regionen nacheinander durchlaufen.
4. Verschleierung der Angriffsspuren: Raffinierte Angreifer versuchen, unentdeckt zu bleiben, indem sie beispielsweise prüfen, ob die Protokollierung von Modellaufrufen (Model Invocation Logging) aktiviert ist. Es gibt zudem Berichte, dass Angreifer die Protokolle der Modellaufrufe anschließend löschen, um ihre Spuren zu verwischen.
5. Modell-Abonnement: Angreifer suchen nach Modellen, die zu ihrem Anwendungsfall oder ihren Fähigkeiten passen. Wenn das gewünschte Modell noch nicht abonniert bzw. aktiviert ist, könnten sie versuchen, den Zugriff darauf freizuschalten.
6. Eigentlicher LLMJacking-Angriff: Angreifer könnten optional dazu übergehen, die verfügbaren LLMs zu kapern, indem sie sich direkt per API mit ihnen verbinden und sie mit ihren schädlichen Anwendungen (z. B. Rollenspiel-Chatbots) verknüpfen. Es ist auch möglich, dass der Angreifer AgentJacking durchführt, wenn er nicht über ausreichenden Zugriff auf die Modelle verfügt, aber auf einen oder mehrere Agenten zugreifen kann.

Gegenmaßnahmen

Es gibt verschiedene Ansätze, die als Gegenmaßnahmen zur Prävention oder Erkennung von LLMJacking-Angriffen implementiert werden können. Hier sind einige Gegenmaßnahmen:

• Modellsicherheit: Aktivieren Sie nur die Modelle, die Sie tatsächlich nutzen möchten, und implementieren Sie eingeschränkte Zugriffskontrollen, z. B. durch den Einsatz von SCPs oder IAM-Richtlinien/-Rollen. Es ist zudem wichtig, Kontrollen für den Zugriff auf das Abonnieren von Modellen zu implementieren oder den Zugriff auf aktivierte Modelle auf bestimmte Identitäten zu beschränken.
• Protokollierung & Analyse: Wenn die Protokollierung aktiviert ist, ergeben sich für Verteidiger durch die API-Aufrufe Möglichkeiten zur Erkennung. Mehrere Cloudtrail-Ereignisse sind hierbei von Interesse, z. B. ListFoundationModels, ListAgents, GetModel, ListAgents, DeleteModelInvocationLoggingConfiguration, GetModelInvocationLoggingConfiguration usw. Das passive Sammeln von Protokollen ist für forensische Analysen zwar nützlich, für die Praxis ist jedoch ein aktiver Ansatz zur Sammlung und Analyse sinnvoller. Die Aktivierung der Modellaufruf-Protokollierung ist ebenfalls unerlässlich, da sie Transparenz über die API-Aufrufe bietet, die an die Basismodelle gerichtet werden.

‍

‍

• Überwachung der Abrechnung: Sobald der eigentliche LLMJacking-Angriff gestartet wurde, kann die Überwachung der Abrechnung ein wirksames Mittel zur Erkennung sein. Dies ist jedoch möglicherweise wenig effektiv, wenn das betroffene Unternehmen LLMs intensiv nutzt, da die Rechnungen dann als normal wahrgenommen werden könnten.
• Prinzip der geringsten Rechte: Die Verschärfung der Zugriffskontrollen für Bedrock ist eine entscheidende Verteidigungsmaßnahme und eine bewährte Best Practice. IAM-Richtlinien und -Rollen können nach dem Prinzip der geringsten Rechte definiert werden, um den potenziellen Schaden bei einer Kompromittierung zu begrenzen.

• Überwachung von Konfigurationsänderungen: Überwachen Sie Konfigurations- und Ressourcenänderungen, z. B. neue Modelle, Prompts und Anwendungen, die auf Bedrock bereitgestellt werden. Auch wenn dies für die aktuell gemeldeten Angriffe möglicherweise nicht direkt relevant ist, könnten so zukünftige Varianten dieser Angriffe bei ihrer Weiterentwicklung erkannt werden.
• Bedrock Guardrails: Die Implementierung der integrierten Filterfunktion für schädliche Inhalte über Bedrock Guardrails kann spezifische Angreifer-Prompts blockieren, die gegen Richtlinien verstoßen, und ermöglicht es Verteidigern, diese ungewöhnlichen Prompts zu identifizieren. Bedrock Guardrails bieten Funktionen, mit denen Benutzereingaben und FM-Antworten, die als schädlich, unangemessen oder anderweitig bedenklich eingestuft werden, erkannt und blockiert werden können.

‍

‍

‍

‍

Sichere GenAI mit Mitigant

GenAI ist zweifellos innovativ, und während die meisten Unternehmen ihr Potenzial ausschöpfen möchten, sind die Sicherheitsanforderungen eine Verantwortung, die nicht ignoriert werden sollte. Deshalb ermöglicht die Mitigant Security Platform Unternehmen den sicheren Einsatz von GenAI auf folgende Weise:

AI Red Teaming

AI Red Teaming ist ein grundlegender Aspekt der GenAI-Sicherheit. Unternehmen, die GenAI einsetzen, müssen in der Lage sein, schnell und kontinuierlich Red-Teaming-Übungen gegen LLMs und andere Komponenten der GenAI-Infrastruktur durchzuführen, um sicherzustellen, dass die Antworten wie erwartet geliefert werden. Mitigant Attack Emulation für GenAI integriert sich in die Struktur der AWS GenAI-Dienste und ermöglicht die Automatisierung von AI Red Teaming. Es versetzt Unternehmen in die Lage, alle Bedrock-Funktionen schnell zu testen, indem über 20 Angriffe verwendet werden, die dem MITRE ATLASzugeordnet sind. Sehen Sie sich eine kurze Demo an, wie Sie mit Mitigant einen Datenextraktionsangriff gegen Bedrock durchführen - Datenexfiltrationsangriffe auf Amazon Bedrock . Diese Angriffe ermöglichen es Unternehmen zudem, die Erkennungs- und Reaktionsfähigkeiten ihrer Sicherheitstools zu validieren, z. B. Cloud Detection and Response.

‍

‍

AI Security Posture Management

Verschiedene Ansätze zum Management der Sicherheitslage, wie CSPM und DSPM, werden eingesetzt, um unterschiedliche Aspekte der Cloud zu verwalten. Diese Ansätze sind jedoch nicht für KI-spezifische Sicherheitslücken geeignet, weshalb ein dedizierter Ansatz erforderlich ist: AI Security Posture Management (AISPM). Mit AISPM können Unternehmen fehlerhaft konfigurierte GenAI-Cloud-Workloads schnell überprüfen und sicherstellen, dass Best Practices für die Sicherheit umgesetzt werden. Darüber hinaus nutzen Unternehmen AISPM, um die Einhaltung regulatorischer und gesetzlicher Anforderungen, wie etwa des EU AI Act, zu überwachen und sicherzustellen. Nutzen Sie Mitigant AISPM , um Fehlkonfigurationen bei GenAI schnell und kontinuierlich zu überwachen und zu identifizieren.

Melden Sie sich für Ihre einmonatige kostenlose Testversion an und schützen Sie sich proaktiv vor Cloud-Angriffen auf GenAI-Workloads, wie zum Beispiel LLMJacking.

‍