Die unentdeckte IA: 175.000 Fälle von Olama im Internet und der LLMjacking-Boom

Die Möglichkeit, große Sprachmodelle (LLM) auf Ihrem eigenen Computer oder in einer kleinen Cloud-Maschine zu betreiben, war einer der großen Fortschritte, die die IA demokratisiert. Aber eine neue gemeinsame Untersuchung von SentinelOne SentinelLABS und Censys hat einen Alarm ausgelöst: Diese Demokratisierung hat auch für IA eine enorme "unmanaged und öffentlich zugängliche Ebene der Recheninfrastruktur" geschaffen. Die Studie erkennt ungefähr 175.000 einzigartige Instanzen von Olama auf dem Internet, verteilt über etwa 130 Länder, viele von ihnen außerhalb jeder Geschäftssicherheit und ohne die Schutz, die Plattform-Anbieter oft verhängen.

Der technische Mechanismus, der viel des Problems erklärt, ist überraschend einfach. Olama, ein Open Source Framework, das das Herunterladen, Ausführen und Verwalten von Sprachmodellen in Windows, macOS und Linux erleichtert, ist standardmäßig konfiguriert, um in der lokalen Richtung 127.0.0.1: 11434 zu hören. Allerdings ist mit einer minimalen Änderung - zum Beispiel die Verbindung des Dienstes mit 0,0.0.0 oder einer öffentlichen Schnittstelle - dieselbe Instanz aus dem Internet zugänglich. Diese triviale Geste ist alles, was sowohl die Verwalter als auch die Angreifer dazu braucht, einen Dienst für die lokale Nutzung in einen öffentlichen Zugangspunkt zu verwandeln.

Die Ausstellung ist nicht homogen: Laut dem Bericht befinden sich die meisten dieser Fälle in China (nur über 30%), aber es gibt auch einen erheblichen Fußabdruck in den Vereinigten Staaten, Deutschland, Frankreich, Südkorea, Indien, Russland, Singapur, Brasilien und dem Vereinigten Königreich. Neben der bloßen Präsenz von exponierten Endpunkten unterstreicht die Studie einen Faktor, der das Risiko wesentlich erhöht: Fast die Hälfte der in ihren APIs beobachteten Hosts zeigt die Fähigkeiten von "Tool-Calling" oder Invokation von Funktionen. In der Praxis ermöglicht dies das Modell, mit externen APIs zu interagieren, Code auszuführen oder auf zusätzliche Systeme zuzugreifen, so dass ein Textgenerator ein Schauspieler in der Lage ist, Aktionen mit realen Auswirkungen durchzuführen.

Dieser Sprung - von der Erstellung von Text zu laufenden Operationen - verwandelt das Bedrohungsmodell vollständig. Eine API, die nur Text zurückgibt, kann schädliche Informationen erzeugen, aber es ist nicht die gleiche wie eine API, die, wenn es getäuscht oder missbraucht wird, Anrufe zu internen Diensten, manipulieren Datenbanken oder starten Skripte machen kann. Wenn diese Fähigkeiten mit unzureichender Authentifizierung und Netzwerkexposition kombiniert werden, ist das Ergebnis nach Forschern einer der größten Risikoquellen im Ökosystem.

Die Analyse identifizierte auch Instanzen, die die Kapazitäten über den Text hinaus erweitern, einschließlich erweiterter Argumentation und Vision, und fand konkrete Fälle - 201 Hosts, nach dem Bericht - mit unzensierten prompten Vorlagen, die Sicherheitssicherungen entfernen. Diese Kombination aus leistungsfähigen Funktionalitäten und fehlenden Kontrollen erhöht die Wahrscheinlichkeit von Angriffen wie dem sogenannten LLMjacking, wo die Ressourcen einer LLM-Instanz zugunsten eines Dritten entführt werden, während der Eigentümer die Kosten zahlt.

Die Gefahr ist nicht rein theoretisch. Ein ergänzender Bericht von Pillar Security dokumentiert eine Kampagne namens Operation Bizarre Bazaar, in der bösartige Akteure systematisch das Internet auf der Suche nach exponierten Instanzen von Olama, vLLM und APis kompatibel mit OpenAI, die keine Authentifizierung haben, validieren die Qualität der Antwort und dann Marktzugang. Die von Pillar beschriebene Operation beinhaltet einen vollständigen Prozess der Anerkennung, Validierung und Weiterveräußerung des Zugangs durch ein einheitliches Gateway, das bestätigt, dass es bereits eine kriminelle Wirtschaft um diese Infrastrukturen gibt. Diese Untersuchung verfolgt die Operation einem Schauspieler namens Hecker (alias Sakuya / LiveGamer101).

Die dezentrale Natur dieses Ökosystems - mit Implementierungspunkten, die zwischen Cloud-Lieferanten und Wohnnetzwerken verteilt werden - schafft auch Governance-Kapazitäten. Viele dieser Gremien werden außerhalb der Kontrolle der betrieblichen Sicherheitsausrüstung umgesetzt, wodurch es schwierig ist, konventionelle Politiken umzusetzen. Die Forscher bestehen darauf, dass die Differenzierung zwischen Cloud-managed und Edge (edge) oder Haushaltsgeräten beginnen muss und kontextspezifische Kontrollen annimmt.

Was können Manager und Anwender tun, um das Risiko zu reduzieren? Die grundlegendste und zugleich effektivere Methode ist, jeden Endpunkt von LLM zu behandeln, der als ob es ein weiterer öffentlicher Dienst wäre: eine robuste Authentifizierung, Verschlüsselung, Ereignisregistrierung und Netzwerkkontrollen auferlegen. Wenn der Prozess nur mit localhost verknüpft werden soll, es sei denn, es gibt einen berechtigten Grund, ihn zu öffnen, die Anwendung von Firewall-Regeln, um zu begrenzen, wer verbinden kann, und die Aktivierung von Authentifizierungsmechanismen (keys, mTLS, Tokens) sind sofortige Maßnahmen. Gleichzeitig helfen die Netzwerksegmentierung, die kontinuierliche Überwachung und die Anwendung von Ratengrenzen, Missbrauch zu erkennen und zu mindern. Für Organisationen, die "Tool-Calling" erstellen, ist es angebracht, die verfügbaren Fähigkeiten aus dem Modell zu überprüfen und zu begrenzen und jede Brücke gründlich zu prüfen, die die Codeausführung oder den Zugang zu kritischen Systemen ermöglicht.

Wenn Sie auf der Suche nach Referenzen und Lesungen zu vertiefen sind, die technische Analyse von Sentinel Eine selbst ist auf Ihrem Blog verfügbar und bietet weitere Informationen über die Methodik und Ergebnisse: SentinelOne SentinelLABS. Der Bericht über den kommerziellen Betrieb von LLMjacking findet sich in der Veröffentlichung von Pillar Security: Operation Bizarre Basar - Säulensicherheit. Um die Software zu verstehen, geben die offizielle Seite von Olama und sein Repository Informationen über das Projekt und seine Konfiguration: Olama und GitHub - Olama. Es ist auch nützlich, sich an gute allgemeine Sicherheitspraktiken für APIs, gesammelt in Initiativen wie OWASP: OWASP API Security und Risikoreferenzrahmen für IA wie die von NIST veröffentlichten: NIST - KI.

Das letzte Gleichgewicht ist klar: Open Source IA-Tools haben enorme Chancen eröffnet, aber sie haben mit ihnen eine Verantwortung gebracht. Wenn Modelle Anweisungen in Aktionen übersetzen können, müssen sie den gleichen Kontrollen unterliegen, wie jeder andere Dienst mit Netzwerk-Rechten. Ignorieren dieser Realität lässt offene Türen für Betrug, Missbrauch und den Bau von illegalen Märkten, die die Exposition monetisieren. Die Lehre für IT-Manager, Sicherheitsteams und Endbenutzer ist, dass technische Flexibilität von Anfang an von Richtlinien, Monitoring und sicheres Design begleitet werden muss.