Claude entdeckte in 25 Open-Source-Projekten 493 Sicherheitsprobleme, darunter Schutzmechanismen, die scheinbar aktiviert waren, während die Software weiterhin unbeabsichtigten Zugriff erlaubte. Einige Probleme waren jahrelang im Code verborgen geblieben.
Die KI-Forschung von Anthropic untersuchte, wie Sicherheitseinstellungen zusammenwirken und wie viel Code vor der Authentifizierung zugänglich bleibt. Zu den Ergebnissen gehörten Schutzmechanismen, die ohne Warnung versagten und die Software über ihre vorgesehenen Einschränkungen hinaus offenlegten.
Eine Entdeckung veranlasste die OpenSSH-Entwickler, die Sicherheitsprüfungen in dem weit verbreiteten Tool für den Fernzugriff zu überarbeiten. Andere Fälle weckten Bedenken hinsichtlich Schwachstellen, die Administratoren bei routinemäßigen Konfigurationsprüfungen möglicherweise nie bemerken würden.
Konfigurationskonflikte deaktivierten Sicherheitsprüfungen
Server, die so konfiguriert waren, dass sie gültige Client-Zertifikate verlangten, konnten Verbindungen dennoch ohne diese akzeptieren – aufgrund eines Konfigurationskonflikts, der 21 Jahre bestanden hatte. Statt die Überprüfung wie vorgesehen zu verzögern, deaktivierte eine separate Einstellung die Prüfung vollständig, ohne die Administratoren zu warnen.
Claude analysierte mehr als fünf Millionen Codezeilen und katalogisierte über 17.000 Konfigurationsoptionen, darunter 3.842 im Zusammenhang mit Sicherheitsfunktionen. Die Untersuchung identifizierte mehrere Probleme, die Kombinationen von Einstellungen betrafen, die die Software ohne Fehlermeldung akzeptierte:
- 94 stillschweigend deaktivierte Kontrollen.Von 162 sicherheitsrelevanten Konfigurationskombinationen, die ohne Warnungen oder dokumentiertes Verhalten akzeptiert wurden, schalteten 94 einen vorhandenen Schutzmechanismus ab.
- 68 inkonsistente Konfigurationen.Andere Kombinationen ließen deaktivierte Anmeldewege zugänglich oder erlaubten es, dass die Reihenfolge der Einstellungen bestimmte, welche Einschränkung Vorrang hatte.
- Vier Projekte mit unwirksamen Verweigerungsregeln.Wenn Reverse-DNS-Abfragen deaktiviert waren, verglichen Server hostnamenbasierte Einschränkungen mit numerischen IP-Adressen. Da die Muster nicht übereinstimmen konnten, konnten die vorgesehenen Zugriffsregeln Verbindungen nicht blockieren.
Anthropic zufolge umfasste die Untersuchung auch die Nachverfolgung der Softwareausführung, um zu beurteilen, ob sich die vermuteten Konfigurationsschwachstellen auf tatsächliche Sicherheitsprüfungen auswirkten.
OpenSSH-Korrekturen verringerten den vor der Authentifizierung erreichbaren Code
Bei 11 Projekten, die für authentifizierte Benutzer konzipiert waren, entdeckte Claude 93 unnötige Codebereiche, die vor der Anmeldung zugänglich waren.
OpenSSH, ein weit verbreitetes Tool für sicheren Fernzugriff, ließ in Version 10.4 etwa 4.500 Zeilen experimentellen Code für postquantenkryptografische Signaturen für nicht authentifizierte Clients erreichbar, selbst wenn der Algorithmus deaktiviert war. Sein Server verarbeitete eingehende Schlüssel, bevor er prüfte, ob die Signaturmethode zulässig war.
Die Entwickler verlagerten die Algorithmenprüfung in Version 10.5, also vor die Schlüsselanalyse, doch zwei Lücken blieben bestehen. Clients konnten einen genehmigten Algorithmus ankündigen und gleichzeitig einen anderen Schlüsseltyp übermitteln, während die Zertifikatsverarbeitung Signaturen weiterhin prüfen konnte, bevor sie die konfigurierten Einschränkungen durchsetzte.
Version 10.6 führte zusätzliche Prüfungen innerhalb des Parsers ein und verringerte den vor der Authentifizierung zugänglichen Code laut Messungen von Anthropic um etwa 20 %.
Die Verringerung der Codeoffenlegung vor der Authentifizierung kann potenzielle Angriffswege begrenzen, doch das Vorhandensein erreichbaren Codes allein belegt noch keine ausnutzbare Schwachstelle.
Sicherheitsteams müssen eingesetzte Schutzmechanismen validieren
Für Unternehmen, die auf Fernzugriff-Gateways und internetseitig erreichbare Dienste angewiesen sind, zeigen Claudes Ergebnisse eine Lücke zwischen freigegebenen Konfigurationen und dem tatsächlichen Verhalten der Software auf.
Ein Server kann über aktuelle Patches und korrekt dokumentierte Einschränkungen verfügen, doch das Zusammenspiel seiner Einstellungen könnte weiterhin unbeabsichtigten Zugriff erlauben. Routinemäßige Sicherheitsprüfungen erkennen diese Abweichung möglicherweise nicht.
Stellen Sie sich eine Organisation vor, die einen kritischen Dienst mit ausschließlich zertifikatsbasierter Authentifizierung schützt. Ein kontrollierter Verbindungsversuch ohne gültige Zugangsdaten würde zeigen, ob der Server die Einschränkung in seiner eingesetzten Konfiguration durchsetzt. Werden solche Prüfungen in Schwachstellenbewertungen einbezogen, können sie Probleme aufdecken, die herkömmliche CVE-Scans und Patch-Inventare möglicherweise übersehen.
Für Sicherheitsteams, die umfangreiche Infrastrukturen verwalten, kann Angriffsflächenmanagement dabei helfen, extern zugängliche Systeme zu identifizieren, bei denen diese Schwachstellen das größte Risiko darstellen würden.
Durch KI erzeugte Ergebnisse müssen weiterhin anhand der betroffenen Softwareversionen überprüft werden, doch bestätigte Sicherheitslücken können eine Behebung rechtfertigen, auch wenn keine CVE veröffentlicht wurde.
Wenn automatisierte Forschung weitere übersehene Probleme aufdeckt, müssen Sicherheitsteams zwischen theoretischen Schwachstellen und nachweisbarer Gefährdung unterscheiden. Belege für die Ausnutzbarkeit, betroffene Konfigurationen und mögliche geschäftliche Auswirkungen sollten maßgeblich dafür sein, welche Korrekturen sofortige Aufmerksamkeit erhalten.
Weitere Nachrichten zur Cybersicherheit: Ein KI-gestütztes Tool für Sicherheitstests ist bei Cyberangriffen zum Einsatz gekommen gegen japanische Unternehmen, was Bedenken hinsichtlich seines Missbrauchs aufwirft.