Intel ist unser Open-Source-Security-Threat-Feed, der von AI und unserem internen Forschungsteam betrieben wird. Intel überwacht und deckt Schwachstellen in Open-Source-Paketen auf, bevor sie offengelegt werden. Viele werden nie offengelegt.
67 % der still behobenen Software-Schwachstellen wurden nie offengelegt
Open-Source-Software treibt die Welt an, im wahrsten Sinne des Wortes. Die Open-Source-Sicherheit ist jedoch auch ein Bereich großer Sicherheitsbedenken. Open-Source-Tools können, wie alles andere auch, Sicherheitslücken einführen. Diese können von Angreifern genutzt werden, um Ihre Anwendung auszunutzen. Softwareanbieter werden unverschuldet Angriffen ausgesetzt. Dies macht die Open-Source-Sicherheit zu einem sehr wichtigen Thema.
Wir verlassen uns nicht nur auf die Open-Source-Community, um diese Tools zu entwickeln und zu warten, wir verlassen uns auch auf sie, um bekannte Sicherheitslücken zu beheben. Wichtig ist, dass wir uns auch auf diese Maintainer verlassen, die Schwachstellen öffentlich melden, wenn sie entdeckt werden. Die öffentliche Offenlegung von Schwachstellen durch die Community bildet die Grundlage der Open-Source-Sicherheit.
Silent Patching oder Shadow Patching liegt vor, wenn ein Sicherheits-Fix angewendet (gepatcht), aber nie offengelegt wird. Dies ist ein großes Problem, da es bedeutet, dass Anbieter anfällige Software betreiben könnten, ohne sich des Risikos bewusst zu sein.
Wir führen Aikido Intel ein, um still und heimlich gepatchte Software, die Sie betreffen könnte, ans Licht zu bringen. Mit Aikido Intel können wir Entwickelnden die frühestmögliche Warnung geben, wenn wir Schwachstellen finden, die sie betreffen könnten, und so die Open-Source-Sicherheit verbessern.
Was ist Aikido Intel?
Aikido Intel ist eine Initiative von KI + unserem internen Forschungsteam, um die Open-Source-Sicherheit zu verbessern, indem Schwachstellen in der Open-Source-Lieferkette zum frühestmöglichen Zeitpunkt entdeckt werden. Noch bevor sie in einer Schwachstellendatenbank veröffentlicht werden. Um dies zu erreichen, verwenden wir speziell trainierte LLMs, um Änderungen in Paketen zu überprüfen und zu identifizieren, wann ein Sicherheitsproblem behoben wurde.
Wie jede Software führt Open Source ein Änderungsprotokoll darüber, was in jeder neuen Version angepasst wurde. Intel nutzt KI, um all diese öffentlichen Änderungsprotokolle und Release Notes zu lesen, um Beispiele zu finden, wo Sicherheitsprobleme behoben wurden. Das wird dann mit 5 Schwachstellendatenbanken abgeglichen, um zu sehen, ob das Problem gemeldet wurde. Falls nicht, lassen wir einen Sicherheitsingenieur die Schwachstelle analysieren und bewerten, ihr eine Aikido-Schwachstellennummer und einen Schweregrad zuweisen und sie öffentlich bekannt geben, damit Sie wissen, ob Sie betroffen sind. Lesen Sie später mehr Details dazu
Aikido Intel in Zahlen
Seit dem Start im Januar hat Aikido Intel 511 Schwachstellen entdeckt, die gepatcht, aber nicht öffentlich bekannt gegeben wurden und eine reale Bedrohung für jeden darstellen, der diese Pakete verwendet.
Manchmal kann es dauern, bis eine Schwachstelle gepatcht und eine CVE-Nummer für das Problem zugewiesen wird. Jede Woche bewertet Aikido den Status früherer Schwachstellen neu, um zu sehen, ob eine CVE zugewiesen wurde. Wir können offenlegen, dass 67 % der von uns entdeckten Schwachstellen niemals öffentlich in einer Schwachstellendatenbank bekannt gegeben wurden!
Während es keine Überraschung ist, dass Schwachstellen mit geringer Schwere häufiger stillschweigend gepatcht werden, ist es dennoch schockierend, dass über 50 % der kritischen und schwerwiegenden Schwachstellen nie offengelegt werden. Dies schafft einen riesigen blinden Fleck für Entwickelnde und Softwareanbieter.
Ich weiß, dass einige von Ihnen sich jetzt winden und sagen werden, dass dies vielleicht kleine, nicht so beliebte Open-Source-Projekte mit begrenzten Sicherheitsrichtlinien sind, aber tatsächlich würden Sie sich irren. Wir haben einige nicht offengelegte Schwachstellen in sehr großen Projekten gefunden.
Axios, ein Promise-basierter HTTP-Client für Browser und Node.js mit 56 Millionen wöchentlichen Downloads und über 146.000 Abhängigkeiten, behob eine Schwachstelle für Prototype Pollution im Januar 2024, die nie öffentlich bekannt gegeben wurde.
Interessanter Fakt zu dieser Schwachstelle: Dies war tatsächlich die erste Schwachstelle, die Aikido Intel gefunden hat (Siehe Nummer 2023-10001)…. Sie ist bis heute unveröffentlicht!
Ich möchte es ihnen jetzt nicht überlassen, Axios ist nicht allein, es gibt noch einige andere Namen, die eine besondere Erwähnung verdienen. Apache hat stillschweigend eine Schwachstelle in der echarts-Software für Cross-Site-Scripting behoben, die nie offengelegt wurde.
Ein weiteres interessantes Beispiel, das wir entdeckten, war eine kritische Path-Traversal-Schwachstelle im Chainlit, die im September gepatcht wurde, aber die Schwachstelle wurde nie öffentlich bekannt gegeben.
Die häufigsten Schwachstellen
Cross-Site-Scripting war mit 14,8 % die häufigste unentdeckte Schwachstelle, gefolgt von der Offenlegung sensibler Informationen mit 12,3 %. Insgesamt haben wir 90 verschiedene Arten von Schwachstellen entdeckt, was zu einer langen Liste von Ergebnissen führte; nachfolgend sind einige der häufigsten aufgeführt.
Die häufigsten entdeckten Schwachstellen
Betrachten wir nur die kritischen und hohen Schwachstellen, zeigt sich ein etwas anderes Bild, wobei die Remote Code Execution den ersten Platz auf der Liste einnimmt.
Die am häufigsten entdeckten Schwachstellen – nur Kritisch und Hoch
Zeit bis zur Offenlegung
Während zum Zeitpunkt der Erstellung dieses Dokuments 67 % der Pakete ihre Schwachstellen nie offengelegt haben, taten dies 31 %, sei es von den Maintainern oder Sicherheitsforschenden (ein Lob an sie). Bei den Paketen, die die Schwachstellen offengelegt haben, dauerte es durchschnittlich 27 Tage von der Veröffentlichung des Patches bis zur Zuweisung einer CVE. Die schnellste von uns beobachtete Zeit betrug nur 1 Tag und die längste Zeit betrug 9 Monate!
Wie Intel funktioniert (im Detail)
Ich weiß, wir haben alle den neuen KI-Hype satt, aber Intel ist eine Initiative des Sicherheitsforschungsteams von Aikido und des KI-Teams von Aikido nutzt KI mit einem Human in The Loop, um einen öffentlichen Bedrohungs-Feed bereitzustellen und die Open-Source-Sicherheit zu verbessern.
Intel funktioniert, indem es alle öffentlich verfügbaren Änderungsprotokolle und Release Notes durchliest, um zu verstehen, ob Sicherheitskorrekturen vorgenommen, aber nicht offengelegt wurden. Um dies zu erreichen, werden zwei LLM-Modelle verwendet: eines zum Filtern der Daten und Entfernen aller unnötigen Kontexte, damit das zweite LLM sich auf die Schwachstellenanalyse konzentrieren kann. Ein menschlicher Sicherheitsingenieur überprüft dann die Entdeckungen des LLM, validiert die Ergebnisse und veröffentlicht einen Intel, wenn eine Schwachstelle bestätigt wird.
Dies ist eine so effektive Methode, weil sie bemerkenswert weniger Rechenleistung verbraucht, als der Versuch, all diese Systeme nach Schwachstellen zu scannen. Dennoch hat sie sich über ein Jahr hinweg als erfolgreich erwiesen, viele echte Ergebnisse zu finden.
Wie Changelogs von Aikido Intel betrachtet werden
Changelogs sind Dokumente, die in Open-Source-Projekten gepflegt werden und Updates, Bugfixes, Funktionserweiterungen und Patches festhalten. Beispiele sind CHANGELOG.md Dateien, Commit-Nachrichten und GitHub Release Notes.
Das Intel LLM identifiziert Einträge, die sicherheitsrelevante Änderungen vorschlagen, indem es nach Folgendem sucht:
- Keywords: „Schwachstelle“, „Sicherheit“, „Fix“, „Exploit“, „Eingabevalidierung“ usw.
- Kontextuelle Hinweise: „Kritischen Bug behoben“, „Pufferüberlauf gepatcht“, „Authentifizierungsprobleme gelöst“
Beispieleinträge, vom LLM gekennzeichnet:- Ein Problem bei der Eingabebereinigung im Login-Handler wurde behoben.
- Ein Speicherleck, das zu Denial-of-Service-Angriffen führen könnte, wurde behoben.
- Eine Path-Traversal-Schwachstelle in der Datei-Upload-Funktionalität wurde adressiert.
Open-Source-Sicherheit, wie Schwachstellen ordnungsgemäß offengelegt werden
Wie bereits erwähnt, ist die öffentliche Offenlegung ein wichtiger Bestandteil der Open-Source-Sicherheit. Verschiedene Datenbanken werden genutzt, um Schwachstellen in Software offenzulegen. Die Hauptdatenbank ist die vom US-Regierung gepflegte National Vulnerability Database (NVD). Diese Datenbank wird nicht nur von Unternehmen zur Überprüfung ihrer Supply Chain genutzt, sondern auch von Sicherheitssoftware, die Projekte mit dieser und anderen Datenbanken abgleicht (SCA-Software). Es gibt zahlreiche weitere Datenbanken, darunter Mitres Common Vulnerabilities and Exposures database (CVE), die GitHub Advisory Database und viele andere. Insgesamt prüft Aikido anhand von 5 verschiedenen Datenbanken. Was die meisten dieser Datenbanken jedoch gemeinsam haben, ist die Anforderung, dass Schwachstellen öffentlich bekannt gemacht werden, üblicherweise nachdem ein Fix veröffentlicht wurde.
Warum werden Schwachstellen nicht offengelegt?
Das ist eine gute Frage, und ich möchte vorausschicken, dass es keinen guten Grund gibt, Schwachstellen nicht offenzulegen. Der vielleicht häufigste Grund ist das Reputationsrisiko, dass Ihre Software als unsicher angesehen werden könnte, aber ich würde behaupten, dass man durch Nicht-Offenlegung viel mehr verlieren kann als durch Offenlegung.
Warum Shadow Patching ein Problem für die Open-Source-Sicherheit darstellt
Das Nicht-öffentliche Offenlegen von Schwachstellen in Ihrer Software birgt ein enormes Risiko für Ihre Benutzer. Wie das Sprichwort sagt: „Never change a running system“ – dies gilt oft für Software.
Das Aktualisieren von Softwarekomponenten kann oft Probleme bei der Performance und Benutzerfreundlichkeit verursachen oder Ihre Anwendung einfach zum Absturz bringen. Daher ist es nicht immer gängige Praxis, Pakete sofort zu aktualisieren, wenn eine neuere Version verfügbar ist.
Wenn jedoch ein Sicherheitsproblem in einer Komponente auftritt, ist es wichtig, dies zu wissen, da es die Dringlichkeit ändert, mit der Sie Ihre Open-Source- und Drittanbieterkomponenten aktualisieren. Die Nichtoffenlegung dieser Informationen bedeutet, dass Benutzer seltener aktualisieren, was dazu führt, dass sie Sicherheitslücken in ihren Tools haben, von denen sie nichts wussten. Daher ist Shadow Patching ein solches Problem.
