Anthropic zufolge ging ein unveröffentlichtes Claude-Modell über das Aufspüren von Softwareschwachstellen hinaus und kombinierte Sicherheitslücken zu fünf funktionierenden Exploit-Ketten in wichtigen Browsern und Betriebssystemen.
In einer am 27. Okt. veröffentlichten Studie beschrieb das Unternehmen Demonstrationen mit Chrome, Safari, Android, Windows und Linux. Ein Chrome-Proof-of-Concept entkam Berichten zufolge der Browser-Sandbox, nachdem eine bösartige Webseite geöffnet worden war, während eine Linux-Demonstration die Ausführung von Befehlen mit Root-Rechten erreichte.
Die Tests wurden in kontrollierten Umgebungen durchgeführt und waren keine dokumentierten Angriffe in der realen Welt. Sie werfen jedoch eine dringende Frage für Sicherheitsteams auf: Können Unternehmen Schwachstellen schnell genug erkennen und patchen, während KI-Systeme immer besser darin werden, komplexe Exploits zu entwickeln?
Claude ging vom Finden von Fehlern zum Aufbau von Exploit-Ketten über
Eine Exploit-Kette kombiniert Schwachstellen, um mehrere Schutzmechanismen zu umgehen. Anthropic zufolge analysierte Claude Code, entwickelte Software durch Reverse Engineering zurück und testete Exploits nach entsprechender Aufforderung.
In Chrome verknüpfte das Modell Berichten zufolge vier Schwachstellen: eine Speicherkorruption in V8, gefolgt von Lücken, die Speicherschutzmechanismen und die Browser-Sandbox umgingen. Anthropic zufolge löste eine bösartige Webseite ein Proof-of-Concept aus, das ohne weitere Interaktion den macOS-Taschenrechner startete.
Anthropic berichtete außerdem, dass seine umfassendere Chrome-Forschung 62 CVEs hervorbrachte, darunter 13 Sandbox-Escapes, wobei Chrome 156 bereits entsprechende Fehlerbehebungen enthielt. Die Kette aus vier Schwachstellen war eine Demonstration innerhalb dieser größeren Forschungsarbeit.
Fünf Demonstrationen überschritten unterschiedliche Sicherheitsgrenzen
Die fünf Exploit-Ketten zielten auf unterschiedliche Sicherheitslücken mit jeweils anderen Zugangsvoraussetzungen und Folgen. Einige begannen mit einer bösartigen Webseite, während andere physischen Zugriff oder einen bestimmten Netzwerkdienst erforderten.
Plattform | Ausgangsbedingung | Gemeldete Auswirkung | Gemeldete Fehlerbehebung |
| Chrome | Bösartige Webseite | Codeausführung außerhalb der Sandbox | Chrome 156 |
| Safari | Bösartige Webseite | Websiteübergreifender Datenzugriff | Apple-Fehlerbehebung verfügbar |
| Android | USB-Zugriff auf gesperrtes Pixel 9 | Fotos extrahiert | Von Google behoben |
| Windows | Offengelegter HTTP/3-Dienst | Abstürze aus der Ferne | Von Microsoft gepatcht |
| Linux | Multipath-TCP-Listener | Befehle mit Root-Rechten | Kernel-Fehlerbehebung in den Upstream übernommen |
Anthropic zufolge umging die Safari-Kette die Same-Origin-Policy, ohne beliebige Codeausführung zu ermöglichen, während die Windows-Demonstration Abstürze entfernter Systeme verursachte. Das Linux-Proof-of-Concept benötigte 48 Minuten, um eine Kernel-Adresse offenzulegen, und weitere fünf Minuten, um einen Befehl mit Root-Rechten auszuführen.
Was eWeek herausfand: Exploit-Ketten bergen unterschiedlich hohe Risiken
Die Ergebnisse zeigen die Unterschiede zwischen funktionierenden Proofs-of-Concept und praktischen Bedrohungen. Zugangsvoraussetzungen, die Verfügbarkeit von Patches und eine unabhängige Überprüfung beeinflussen, wie Sicherheitsteams die Ergebnisse bewerten sollten.
Die Gefährdung ist wichtiger als die Zahl der Exploit-Ketten
Die fünf Demonstrationen stellen nicht fünf gleich dringliche Bedrohungen dar.
Ein durch eine bösartige Webseite ausgelöster Browser-Exploit stellt ein anderes Angriffsszenario dar als ein Angriff, der physischen Zugriff auf ein gesperrtes Smartphone erfordert. Ebenso hängt das Risiko netzwerkbasierter Schwachstellen davon ab, ob die betroffenen Dienste aktiviert und erreichbar sind.
Für Sicherheitsteams ist dieser Unterschied bei der Priorisierung von Abhilfemaßnahmen wichtig. Eine Schwachstelle in einem offengelegten Produktivdienst kann eine sofortigere Beachtung erfordern als eine, die eine ungewöhnliche Konfiguration oder direkten Gerätezugriff voraussetzt.
Die Demonstrationen zeigen, warum Ausnutzbarkeit, Zugangsvoraussetzungen und die Verfügbarkeit von Patches gemeinsam bewertet werden müssen, anstatt jeden funktionierenden Proof-of-Concept als gleichwertige Bedrohung zu behandeln.
Herstellerfehlerbehebungen bestätigen Claudes Autonomie nicht
Laut The Hacker News bestätigten Google und Apple, dass Anthropic-Forscher Claude dabei eingesetzt hatten, bestimmte Schwachstellen zu entdecken.
Allerdings ist weiterhin unklar, wie viel der Arbeit Claude eigenständig erledigte und wie viel menschliche Unterstützung erforderte. Anthropic hat das in den Tests verwendete Modell nicht genau benannt, und die geprüften Quellen nannten keine öffentliche Google-Empfehlung, die die Behebung der Android-Schwachstelle bestätigt.
Schwachstellenfunde müssen sorgfältig eingeordnet werden
The Hacker News und Mallory lieferten zusätzliche Details zu den Windows- und Linux-Schwachstellen. Die tatsächlichen Risiken hängen von der betroffenen Software, den Systemkonfigurationen und den Voraussetzungen für die Ausnutzung ab. Sicherheitsteams sollten die Empfehlungen der Hersteller prüfen, um die Gefährdung und verfügbare Fehlerbehebungen zu bestätigen.
Die Tests demonstrieren die KI-gestützte Entwicklung von Exploits, aber keine bestätigten Angriffe in der realen Welt mit diesen Exploit-Ketten oder eine vollständig autonome Ausnutzung.
Sicherheitsteams müssen Erkenntnisse in verifizierte Fehlerbehebungen übersetzen
Anthropics Demonstrationen betrafen unterschiedliche Sicherheitsrisiken, daher hängt die angemessene Reaktion von den betroffenen Systemen ab. Nutzer, IT-Teams und Entwickler sollten sich auf die Schwachstellen konzentrieren, die die von ihnen verwendeten und verwalteten Geräte, Dienste oder Software betreffen.
- Browser- und Mobilnutzer: Installieren Sie verfügbare Browser- und Geräteupdates und schützen Sie Telefone vor unbefugtem physischem Zugriff. Für den Android-Test war eine USB-Verbindung erforderlich.
- IT- und Sicherheitsteams: Prüfen Sie offengelegte HTTP/3- und Multipath-TCP-Dienste, verifizieren Sie installierte Patches und vergleichen Sie betroffene Konfigurationen mit den Empfehlungen der Hersteller.
- Entwickler: Scannen Sie geplante Codeänderungen, überprüfen Sie von KI gemeldete Schwachstellen und testen Sie Fehlerbehebungen vor der Veröffentlichung, statt davon auszugehen, dass jeder Fund ein funktionierender Exploit ist.
„Das Beheben des bestehenden Rückstands löst nur die Hälfte des Problems“, schrieb Anthropic und empfahl Sicherheitsscans, wenn Entwickler Codeänderungen vorschlagen.
Für Unternehmen besteht die unmittelbare Priorität darin, betroffene Konfigurationen zu überprüfen, verfügbare Patches bereitzustellen und neuen Code vor der Veröffentlichung auf Sicherheitslücken zu testen.
Die größere Schlussfolgerung ist, dass das Finden einzelner Schwachstellen möglicherweise nicht mehr der schwierigste Teil eines Exploits ist. Je besser KI-Tools darin werden, Schwachstellen zu kombinieren, desto wichtiger wird es für Sicherheitsteams, gefährliche Kombinationen zu erkennen, bevor Angreifer daraus funktionierende Exploit-Ketten machen können.
Möchten Sie nützlichere Ergebnisse mit KI-Tools wie Claude erzielen? Probieren Sie unseren kostenlosen sechminütigen Kurs „So sprechen Sie mit KI“ aus, um einfache Möglichkeiten kennenzulernen, klarere Prompts zu schreiben und effektiver mit KI zu arbeiten. eWeek-Leser erhalten außerdem sieben Tage kostenlosen Zugang zu den anderen KI-Kursen der Neuron Academy. Hier finden Sie alle Lektionen →