Intel ist unser Open-Source-Sicherheits-Bedrohungs-Feed , der von KI und unserem internen Forschungsteam unterstützt wird. Intel überwacht und deckt Schwachstellen in Open-Source-Paketen auf, bevor sie veröffentlicht werden. Viele werden nie veröffentlicht.
67 % der stillschweigend gepatchten Software-Schwachstellen wurden nie bekannt gegeben
Open-Source-Software macht die Welt buchstäblich stark. Die Sicherheit von Open-Source-Software ist jedoch auch ein Bereich, in dem große Sicherheitsbedenken bestehen. Open-Source-Tools können, wie alles andere auch, Sicherheitslücken aufweisen. Diese können von Angreifern genutzt werden, um Ihre Anwendung auszunutzen. Software-Anbieter sind somit ohne eigenes Verschulden angreifbar. Das macht die Open-Source-Sicherheit zu einem sehr wichtigen Thema.
Wir verlassen uns nicht nur darauf, dass die Open-Source-Gemeinschaft diese Werkzeuge entwickelt und pflegt, sondern auch darauf, dass sie alle bekannten Sicherheitslücken behebt. Wir verlassen uns auch darauf, dass die Betreuer die Schwachstellen öffentlich melden , wenn sie entdeckt werden. Die öffentliche Bekanntgabe von Schwachstellen durch die Gemeinschaft bildet die Grundlage der Open-Source-Sicherheit.
Beim Silent Patching oder Shadow Patching wird eine Sicherheitslücke zwar behoben (gepatcht), aber nicht bekannt gegeben. Dies ist ein großes Problem, denn es bedeutet, dass Anbieter möglicherweise anfällige Software einsetzen, ohne sich des Risikos bewusst zu sein.
Wir bringen Aikido Intel auf den Markt, um gepatchte Software, die Sie betreffen könnte, aus dem Verborgenen zu holen. Mit Aikido Intel können wir Entwickler so früh wie möglich warnen, wenn wir Sicherheitslücken finden, die sie betreffen könnten, und die Open-Source-Sicherheit verbessern.
Was ist Aikido Intel?
Aikido Intel ist eine Initiative von AI + unserem internen Forschungsteam zur Verbesserung der Open-Source-Sicherheit, 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 geschulte LLMs, um Änderungen in Paketen zu überprüfen und zu erkennen, wann ein Sicherheitsproblem behoben wurde.
Wie bei jeder Software wird auch bei Open-Source-Software in einem Änderungsprotokoll festgehalten, was in jeder neuen Version geändert wurde. Intel setzt KI ein, um all diese öffentlichen Änderungsprotokolle und Versionshinweise zu lesen und Beispiele dafür zu finden, wo Sicherheitsprobleme behoben wurden. Diese werden dann mit 5 Schwachstellen-Datenbanken abgeglichen, um festzustellen, ob das Problem bereits gemeldet wurde. Ist dies nicht der Fall, wird die Schwachstelle von einem Sicherheitsingenieur analysiert und bewertet, der ihr eine Aikido-Schwachstellennummer und einen Schweregrad zuweist und sie öffentlich bekannt gibt, damit Sie wissen, ob Sie betroffen sind. Lesen Sie mehr Details dazu später
Aikido Intel jetzt ausprobieren
Aikido Intel nach Zahlen
Seit der Einführung von Aikido im Januar, hat Intel 511 Sicherheitslücken entdeckt entdeckt, die gepatcht, aber nicht veröffentlicht wurden und eine echte Bedrohung für jeden darstellen, der diese Pakete verwendet.
Manchmal kann es einige Zeit dauern, bis eine Sicherheitslücke gepatcht und eine CVE-Nummer zugewiesen wird. Jede Woche bewertet Aikido den Status früherer Schwachstellen neu, um zu sehen, ob ihnen eine CVE-Nummer zugewiesen wurde. Wir können mitteilen, dass 67 % der von uns entdeckten Sicherheitslücken nie in einer Datenbank für Sicherheitslücken veröffentlicht wurden!
Es überrascht zwar nicht, dass Schwachstellen mit geringem Schweregrad häufiger stillschweigend gepatcht werden, aber es ist dennoch schockierend, dass über 50 % der schwerwiegenden und kritischen Schwachstellen nie offengelegt werden. Dies schafft einen riesigen blinden Fleck für Entwickler und Software-Anbieter.
Ich weiß, dass sich einige von Ihnen jetzt in ihren Sitzen winden und sagen, dass es sich dabei vielleicht um kleine, nicht so populäre Open-Source-Projekte mit begrenzten Sicherheitsrichtlinien handelt, aber da liegen Sie falsch. Wir haben in einigen sehr großen Projekten einige unentdeckte Sicherheitslücken gefunden. .
Axios, ein auf Versprechen basierender HTTP-Client für den Browser und node.js mit 56 Millionen wöchentlichen Downloads und 146.000 + Abhängigen, hat im Januar 2024 eine Schwachstelle für Prototyp-Verschmutzung behoben , die nie öffentlich bekannt gemacht wurde.
Eine interessante Tatsache über diese Sicherheitslücke: Dies war tatsächlich die erste Sicherheitslücke, die Aikido Intel gefunden hat (siehe Nummer 2023-10001).... Sie ist bis heute nicht bekannt geworden!
Nun will ich sie nicht übergehen, Axios ist nicht allein, es gibt noch ein paar andere Namen, die ein besonderes Lob verdienen. Apache hat in aller Stille eine Schwachstelle in der Echarts-Software für Cross-Site-Scripting gepatcht, die nie bekannt gegeben wurde.
Ein weiteres interessantes Beispiel, das wir entdeckt haben, war eine kritische Path-Traversal-Schwachstelle im Chainlit, die im September gepatcht wurde, aber die Schwachstelle wurde nie veröffentlicht.
Die häufigsten Schwachstellen
Cross-Site-Scripting war mit 14,8 % die häufigste nicht gemeldete Schwachstelle, gefolgt von der Offenlegung sensibler Informationen mit 12,3 %. Insgesamt haben wir 90 verschiedene Arten von Schwachstellen entdeckt, die eine lange Reihe von Ergebnissen hervorrufen; im Folgenden sind einige der häufigsten aufgeführt.
Die am häufigsten entdeckten Schwachstellen
Betrachtet man nur die Schwachstellen in den Bereichen "Cuticle" und "High", so ergibt sich ein etwas anderes Bild: Remote Code Execution steht an erster Stelle der Liste
Die am häufigsten entdeckten Schwachstellen - nur kritisch und hoch
Zeit bis zur Offenlegung
Während zum Zeitpunkt der Erstellung dieses Artikels 67 % der Pakete ihre Schwachstellen nie bekannt gaben, taten dies 31 %, sei es von den Betreuern oder von Sicherheitsforschern (ein Lob an sie). Von den Paketen, die die Schwachstellen offengelegt haben, dauerte es durchschnittlich 27 Tage von der Veröffentlichung des Patches bis zur Zuweisung eines CVE. Die schnellste Zeit, die wir beobachtet haben, war nur 1 Tag und die längste Zeit war 9 Monate!
So funktioniert Intel (im Detail)
Ich weiß, dass wir alle den neuen KI-Bullsh*t satt haben, aber Intel ist eine Initiative des Sicherheitsforschungsteams von Aikido, und das KI-Team von Aikido nutzt KI mit einem "Human in The Loop", um einen öffentlichen Bedrohungs-Feed zur Verbesserung der Open-Source-Sicherheit bereitzustellen.
Intel liest alle öffentlich zugänglichen Änderungsprotokolle und Versionshinweise, um festzustellen, ob Sicherheitsbehebungen vorgenommen, aber nicht veröffentlicht wurden. Zu diesem Zweck werden zwei LLM-Modelle verwendet, von denen eines die Daten filtert und alle unnötigen Zusammenhänge entfernt, damit sich das zweite LLM auf die Schwachstellenanalyse konzentrieren kann. Ein menschlicher Sicherheitsingenieur überprüft dann die Entdeckungen des LLM, validiert die Ergebnisse und gibt eine Meldung heraus, wenn eine Schwachstelle bestätigt wird.
Diese Methode ist deshalb so effektiv, weil sie deutlich weniger Rechenleistung verbraucht als der Versuch, all diese Systeme auf Schwachstellen zu überprüfen. Dennoch hat es sich über ein Jahr lang bewährt, viele echte Ergebnisse zu finden.
Wie Changelogs von Aikido Intel betrachtet werden
Changelogs sind Dokumente, die in Open-Source-Projekten gepflegt werden und Aktualisierungen, Fehlerbehebungen, Funktionserweiterungen und Patches aufzeichnen. Beispiele hierfür sind CHANGELOG.md Dateien, Commit-Nachrichten und GitHub-Versionshinweise.
Der Intel LLM identifiziert Einträge, die auf sicherheitsrelevante Änderungen hindeuten, indem er nach ihnen sucht:
- Schlüsselwörter: "Schwachstelle", "Sicherheit", "Behebung", "Exploit", "Eingabeüberprüfung" usw.
- Kontextuelle Hinweise: "Ein kritischer Fehler wurde behoben", "Ein Pufferüberlauf wurde gepatcht", "Authentifizierungsprobleme wurden behoben".
Vom LLM gekennzeichnete Beispieleinträge:- Behebung eines Problems bei der Bereinigung von Eingaben im Login-Handler.
- Behebung eines Speicherlecks, das zu Denial-of-Service-Angriffen führen konnte.
- Behebung einer Path-Traversal-Schwachstelle in der Dateiupload-Funktion.
Open-Source-Sicherheit, wie Sicherheitslücken richtig offengelegt werden
Wie bereits erwähnt, ist die Offenlegung von Schwachstellen ein wichtiger Bestandteil der Open-Source-Sicherheit. Es gibt verschiedene Datenbanken, in denen veröffentlicht wird, wenn eine Software eine Sicherheitslücke aufweist. Die wichtigste Datenbank ist die National Vulnerability Database (NVD), die von der US-Regierung verwaltet wird. Diese Datenbank wird nicht nur von Unternehmen genutzt, um ihre Lieferkette zu überprüfen, sondern auch von Sicherheitssoftware, die Projekte anhand dieser und anderer Datenbanken überprüft (SCA-Software). Es gibt zahlreiche weitere Datenbanken, darunter die Common Vulnerabilities and Exposures-Datenbank (CVE) von Mitre, die GitHub Advisory Database und viele weitere. Insgesamt überprüft Aikido fünf verschiedene Datenbanken. Die meisten dieser Datenbanken haben jedoch gemeinsam, dass sie verlangen, dass Schwachstellen öffentlich bekannt gegeben werden, in der Regel nachdem ein Fix veröffentlicht wurde.
Warum werden Schwachstellen nicht offengelegt?
Das ist eine gute Frage, und ich möchte zunächst sagen, dass es keinen guten Grund gibt, Schwachstellen nicht offen zu legen. Der häufigste Grund ist vielleicht das Reputationsrisiko, dass Ihre Software als unsicher angesehen werden könnte, aber ich würde behaupten, dass man viel mehr verlieren kann, wenn man sie nicht offenlegt, als wenn man sie offenlegt.
Warum Shadow-Patching ein Problem für die Open-Source-Sicherheit ist
Wenn Sie Schwachstellen in Ihrer Software nicht öffentlich bekannt geben, stellt dies ein großes Risiko für Ihre Benutzer dar. Das Sprichwort " Was nicht kaputt ist, soll man nicht reparieren" trifft auf Software oft zu.
Die Aktualisierung von Komponenten Ihrer Software kann oft zu Problemen bei der Leistung und der Benutzerfreundlichkeit führen oder Ihre Anwendung schlichtweg zerstören. Aus diesem Grund ist es nicht immer üblich, Pakete sofort zu aktualisieren, wenn eine neuere Version verfügbar ist.
Wenn es jedoch ein Sicherheitsproblem in einer Komponente gibt, ist es wichtig, dies zu wissen, da es die Dringlichkeit ändert, mit der Sie Ihre Open-Source- und Drittanbieterkomponenten aktualisieren. Wenn diese Informationen nicht bekannt gegeben werden, ist die Wahrscheinlichkeit geringer, dass die Benutzer aktualisieren, was bedeutet, dass sie Sicherheitslücken in ihren Tools haben, von denen sie nichts wussten.
Lassen Sie nicht zu, dass versteckte Schwachstellen Ihre Sicherheit gefährden.
Gehen Sie noch heute eine Partnerschaft mit Aikido Security ein, um Ihre Lieferkette zu schützen und ein Gefühl der Sicherheit zu bekommen.
.png)
.svg)
.png)
.png)
.png)
.jpg)
.jpg)
.jpg)
.jpg)
.png)