Dies ist die vierte Folge in der Reihe von Beiträgen über bösartige Komponenten, wo wir die Xygeni Ansatz zur Bewältigung dieser Bedrohung als Teil unserer Berichterstattung für Open Source Security.
Wir haben gesehen, dass übermäßiges Vertrauen in Open-Source-Komponenten unsicherer Herkunft von Übeltätern aller Art ausgenutzt wird, um unerwartetes Verhalten zu erzeugen, das entweder auf Entwicklermaschinen ausgeführt wird, CI/CD Systeme oder in die Software der betroffenen Organisation eingebettet, sodass sie an die Kunden der Organisation weitergegeben wird. Wir analysierten in Episode 2 die Angriffe, bei denen öffentliche Register zur Verbreitung von Malware genutzt werden, und was wir gelernt haben, nachdem wir beobachtet haben, wie die Bösewichter vorgehen, und in der Vergangenheit Episode 3 Es wurden die Kontrollen untersucht, die gegen diese Bedrohung funktionieren (und diejenigen, die versagen).
Jetzt ist es an der Zeit, unseren Ansatz für das Problem zu betrachten. In dieser Folge präsentieren wir die Strategie, die wir bei Xygeni für unsere Frühwarnung vor Malware (MEW)-System. Wie dieses mehrstufige System in Echtzeit funktioniert, wenn eine neue Paketversion veröffentlicht wird, wie Beweise aus verschiedenen Quellen erfasst werden, wie die Triage durchgeführt wird, welche Klassifizierungskriterien wir befolgen und warum dennoch eine manuelle Analyse erforderlich ist, um die Art eines bösartigen Paketkandidaten zu bestätigen. Wir werden auch erklären, wie wir NPM, GitHub, PyPI und anderen wichtigen Infrastrukturen in den Open-Source-Ökosystemen helfen, die Verweildauer von Malware zu verkürzen.
Das pipeline
Xygeni Malware Early Warning (MEW) verarbeitet kontinuierlich Komponenten, entweder Paket-Tarballs für Bibliotheken und Frameworks für unterstützte Programmier-Ökosysteme wie JavaScript/Node oder Python, Docker/OCI-Container-Images oder Erweiterungen und Plugins für Tools wie IDEs oder CI/CD Systeme. Solche Komponenten werden in öffentlichen Registern mit unterschiedlichen Stufen der Benutzerüberprüfung veröffentlicht.
Nachfolgend sehen Sie eine schematische Darstellung der Funktionsweise des Systems:
Das Entdecker Der Prozess erhält den Feed der Veröffentlichungsereignisse. Ein Veröffentlichungsereignis ist die Erstellung einer neuen Version einer neuen oder vorhandenen Komponente. Da die gängigen Register keinen Pub-Sub-Mechanismus für interessierte Verbraucher bereitstellen, wird dies häufig durch Abfragen des Registers nach aktuellen Ereignissen erreicht. Ein hervorragendes Projekt der OSSF, Paket-FeedsUnterstützung beliebte Register wie PyPI oder Maven Central und bieten eine einheitliche feedbasierte Schnittstelle. In MEW haben wir einige spezifische Implementierungen hinzugefügt, die die Wartezeit verkürzen, beispielsweise mit einer Replik der von NPM verwendeten CouchDB-Datenbank, die mit der öffentlichen Registerdatenbank synchronisiert ist.
In Xygeni haben wir ein Inventar[1]. aller Komponenten (direkt oder indirekt), die von der Software unserer Kunden verwendet werden. Die Komponentenkoordinaten der Kunden werden regelmäßig an MEW übermittelt, um die Analysen zu priorisieren: Komponenten, die von unseren Kunden verwendet werden, werden früher verarbeitet. Die Priorität basiert auch auf der Reputation des Herausgebers und der Kritikalität der Komponente, sodass Komponenten von Herausgebern mit geringer Reputation ebenfalls priorisiert werden.
Das Analysatoren dann die ausstehenden Komponenten in der Prioritätswarteschlange verbrauchen. Wenn eine Komponentenversion zur Analyse ausgewählt wird, wird ihr Tarball aus der Registrierung heruntergeladen. Beachten Sie, dass die gepackte, binäre Komponente analysiert wird: Die meisten Open-Source-Komponenten stammen normalerweise aus einem Open-Source-Repository, oft unter github.com, das nur für den Kontext verwendet wird, und die Malware wird immer im Komponenten-Tarball gesucht, weil Bedrohungsakteure systematisch über die Quellen lügen, die sie angeblich zum Erstellen des von ihnen veröffentlichten Komponenten-Tarballs verwendet haben.
Aus der Sicht des Benutzers
Ich höre Sie denken: Welchen Nutzen kann ich davon haben, frühzeitig über eine bösartige Paketversion informiert zu werden? In der Folge „Anatomie bösartiger Pakete: Was sind die Trends?“ Wir haben festgestellt, dass die gesamte Verweildauer im Bereich von Tagen liegt, während die erste Benachrichtigung von MEW an Kunden, die die betroffene Komponente verwenden, im Minutenbereich liegt. Mit einer einfachen Leitplanke[2]. Sie können den Build blockieren (es gibt zwei Warnstufen, eine vollständig automatisierte, wenn die Engine zu dem Schluss kommt, dass potenzielle Malware vorhanden ist, und eine spätere Benachrichtigung, wenn unser Sicherheitsteam durch manuelle Überprüfung das Vorhandensein von Malware bestätigt). Zu warten, bis die Registrierung die Malware bestätigt und aus der Registrierung entfernt, ist aufgrund des langen Expositionsfensters normalerweise zu spät.
Die Organisation kann eine Leitplanke verwenden, die prüft, ob eine Komponente mit potenzieller Schadsoftware vorhanden ist (in einer der beiden Warnstufen), oder über eine API schnell erkennen, ob eine der direkten oder indirekten Abhängigkeiten in einem Softwareprojekt eine schädliche Komponente verwendet.
So funktioniert MEW: Insider-Details
Der Kern: Malware-Erkennungs-Engine
Der Analysator verwendet verschiedene Detektoren, um Beweise für Fehlverhalten zu erfassen. Detektoren kombinieren statische Analyse, Fähigkeitenanalyse und Kontextanalyse[3]., wie im vorherigen Beitrag dieser Reihe beschrieben.
Bei Xygeni haben wir ein Entwicklungsteam mit langjähriger Erfahrung in der statischen Analyse, und das ist der Hauptunterschied zu anderen Anti-Malware-Lösungen. Beachten Sie, dass das gepackte Tarball für einige Ökosysteme entweder Quellcode enthält (z. B. JavaScript- oder TypeScript-Code für NPM-Pakete, Python-Quellen für PyPI-Pakete) oder kompilierten Code, der dem Quellcode für eine statische Analyse nahe genug kommt (z. B. Bytecode in JAR-Dateien für Maven). Für andere, wie z. B. Container-Images, sind binäre ausführbare Dateien üblich, sodass die Fähigkeitsinferenz die verwendete Technik ist, zusammen mit herkömmlicher Malware-Erkennung basierend auf YARA-Regeln und Malware-Signaturen.
Bitte beachten Sie, dass einfache Technologien wie reguläre Ausdrücke oder Signaturen nicht geeignet sind, um bösartiges Verhalten zu erkennen. Stellen Sie sich vor, Sie erkennen einen Dropper oder Downloader: Ein Code oder eine Binärdatei befindet sich im Paket oder wurde von einer externen Domäne heruntergeladen, die nicht mit der Komponente zusammenhängt (könnte eine von einer große Liste von Domains, die vom Bedrohungsakteur gekauft wurden[4]., oder eine legitime Domain, um der Erkennung zu entgehen). Dieser Code wird dann mit einer der dafür vorgesehenen Funktionen ausgeführt. Der Code kann so transformiert werden, dass die Download-URL oder die Funktion zum Ausführen des heruntergeladenen Codes verborgen wird. Um dies zu erkennen, ist eine vollständige Datenflussanalyse erforderlich. Im Allgemeinen könnte dies mithilfe der gesamten Maschinerie der statischen Analyse oder einer Sandbox-Ausführung (wenn die Bedingungen für die Ausführung bösartigen Verhaltens tatsächlich erfüllt sind) erkannt werden.
Bedrohungsakteure verwenden dieselben Techniken und Detektoren, die für sie entwickelt und implementiert wurden. Es gibt auch einige Vorverarbeitungsschritte, beispielsweise zum Entfernen von Verschleierung, die oft erforderlich sind, um das verborgene Verhalten aufzudecken.
Kontext hinzufügen
Einige Detektoren verwenden Kontextinformationen. Eine Nichtübereinstimmung zwischen der Version im Komponentenregister und dem Tag/Release im zugehörigen GitHub-Repository ist beispielsweise ein starker Hinweis darauf, dass ein böswilliger Akteur möglicherweise Veröffentlichungsberechtigungen für das Register, aber nicht für das GitHub-Repository erhalten hat. Angriffe wie der, der den Anbieter von Krypto-Wallets betraf Ledger könnte leicht durch diese Nichtübereinstimmung erkannt werden.
A Bösartigkeitswert (MS) wird aus den Ergebnissen der ausgeführten Detektoren berechnet, basierend auf der Stärke der erfassten Beweise. Nicht alle Ergebnisse sind gleich und die Reihenfolge der Ausführung ist relevant.
Benutzer- und Komponentenreputation
Nicht alle Open-Source-Entwickler sind gleich!
Ein seriöser Entwickler kann Opfer eines Hackerangriffs auf sein NPM-Konto werden (das passiert sogar sicherheitsbewussten Personen) und Malware wird über dieses Konto veröffentlicht. Natürlich sollte der Ruf abrupt sinken und erst dann wieder zu altem Glanz zurückkehren, wenn das gehackte Konto wiederhergestellt ist und der Entwickler die Bedingungen behebt, die zur Übernahme des Kontos geführt haben. Ein guter Ruf ist schwer zu erlangen, kann aber in einem Augenblick verloren gehen.
Bei MEW haben wir ein umfassendes Reputationsmanagementsystem implementiert, um positives Verhalten zu belohnen und verdächtige Aktivitäten zu bestrafen. Dieses System beginnt mit neuen Benutzern in einer neutralen Haltung und passt ihren Ruf basierend auf ihren laufenden Aktivitäten an.
Die Reputation eines Benutzers verbessert sich durch positive Aktionen wie die Pflege aktiver Social-Media-Konten, die Aktivierung der Multi-Faktor-Authentifizierung, die regelmäßige Mitarbeit an Projekten und die Unterzeichnung commits mit überprüfbaren Schlüsseln. Umgekehrt verschlechtert sich der Ruf durch feindliche Aktionen wie die Veröffentlichung von Malware, die Verwendung von Wegwerf-E-Mail-Adressen, das Nicht-Signieren commits oder ungewöhnliche Muster in den Beiträgen aufweisen.
Das Hauptziel unseres Systems besteht darin, eine sichere und vertrauenswürdige Umgebung zu gewährleisten. Dies wird erreicht, indem die Reputation der Benutzer dynamisch auf der Grundlage verschiedener Faktoren angepasst wird, wobei gleichzeitig Datenschutzbedenken und die Einschränkungen verschiedener Register berücksichtigt werden.
Für den Benutzer wird ein interner Reputationswert berechnet (durch Beitritt zum Register und zum GitHub-Konto, wenn möglich). Zusätzlich wird der Bösartigkeitswert berechnet, der bei der Klassifizierung der zu analysierenden Komponente verwendet wird und der besser eingrenzt, wer von der Komponentenveröffentlichung betroffen ist.
Es wurden Hinweise auf böswilliges Verhalten gefunden. Was nun? Der manuelle Überprüfungsprozess
Der aktuelle Klassifizierer ordnet die analysierte Komponentenversion einer der Kategorien „bestätigt bösartig“, „wahrscheinlich bösartig“, „hohes Risiko“, „geringes Risiko“ oder „nicht bösartig“ zu, basierend auf Schwellenwerten für die Punktzahlen, die die Ergebnisse und die Reputation von Benutzern/Komponenten zusammenfassen. Eine Einstufung in die Kategorien „hohes Risiko“ oder „wahrscheinlich bösartig“ löst die manuelle Überprüfung und erste Benachrichtigung aus. Die Kategorie „bestätigt bösartig“ wird nach der manuellen Überprüfung festgelegt oder wenn die Beweise mit denselben Beweisen für eine frühere Version übereinstimmen, die als bösartig bestätigt wurde.
Wenn genügend Hinweise auf potenziell bösartiges Verhalten vorliegen, wird eine erste Warnung (Quarantänewarnung) an die betroffenen Organisationen gesendet. Wie bereits erwähnt, kann dies die Installation oder Erstellung von Software blockieren, die von der unter Quarantäne gestellten Komponente abhängt.
Das schafft ein Problem im internen MEW dashboard so dass Sicherheitsanalysten den manuellen Überprüfungsprozess für die Komponente starten können. Das Team verfügt über spezielle Tools (Sandbox, Deobfuscatoren, Verteilung für Malware-Forschung, Tools zur Meldung von Malware), um die Art der untersuchten Komponentenversion schnell zu beurteilen. Der Großteil der Malware („die Sardellen“ oder unkomplizierte bösartige Komponenten) wird überprüft
Das Ergebnis der Überprüfung lautet entweder Safe, sodass die automatische Analyse-Engine ein falsches Positiv gefunden hat, das als Feedback an den Klassifikator des maschinellen Lernens verwendet wird, um das Muster zu erlernen; oder bestätigte Schadsoftware, sodass die Komponente nach dem Meldeprozess verantwortungsbewusst als bösartig im öffentlichen Register gemeldet wird. Eine zweite Benachrichtigung wird an die betroffenen Organisationen gesendet, die wiederum Entfernen Sie die Quarantäne für die Komponente oder blockieren Sie sie endgültig aus dem Versionsaktualisierungsprozess oder der in Ihrer internen Registrierung verwendeten Komponenten-Firewall.
Mit dieser Einstellung können wir täglich Zehntausende neuer Versionen analysieren und die zehn wahrscheinlich bösartigen Versionen identifizieren, die wir dann manuell überprüfen. Erinnern Sie sich an die letzte Episode: Eins zu Zehntausend ist die Rate bösartiger Komponenten, die wir derzeit in freier Wildbahn sehen.
Meldung an das Register
Wir haben festgestellt, dass die meisten öffentlichen Register, eines der Rückgrate der Open-Source-Infrastruktur, nur recht begrenzte Mechanismen zur Meldung von Sicherheitsproblemen und insbesondere von bösartigen Komponenten bieten. Wir bemühen uns, die zugrunde liegende Organisation des Meldeprozesses zu verbessern. Normalerweise erhalten wir höchstens eine Feedback-E-Mail vom Sicherheitsteam des Registers, die bestätigt, dass die Komponente aus dem Register entfernt wurde.
Manchmal wird die Registrierung missbraucht, wobei die Nutzungsbedingungen verletzt werden, ohne dass dies zu böswilligem Verhalten in der bereitgestellten Software führt. Dies wird auch der Registrierung gemeldet, Organisationen werden jedoch nicht benachrichtigt, um den Lärm zu begrenzen.
Zukünftige Arbeit
Viele Verbesserungen stehen derzeit auf dem Plan. In erster Linie eine öffentliches Portal zur Integrität von Betriebssystemkomponenten, insbesondere im Zusammenhang mit den gefundenen Hinweisen auf mögliche Bösartigkeit, befindet sich derzeit in der Entwicklung. Dies ist als bescheidener Beitrag zur Open-Source-Community gedacht. Bleiben Sie dran.
Eine weitere laufende Entwicklung ist eine verbesserte Klassifikator für maschinelles LernenMEW lernt aus früheren Klassifizierungen. Der Vektor der Ergebnisse der Engine-Detektoren sowie der abgeleitete Schadhaftigkeits- und Reputationswert sowohl der Komponente als auch des Herausgebers („die gefundenen Beweise“) werden als Eingabe für ein maschinelles Lernsystem verwendet, das das Klassifikatormodell aktualisiert. Die Ausgabevariable ist lediglich, ob die Registrierung bestätigt hat, dass die Komponente bösartig ist. Dies trägt den Codenamen „das Orakel“ und wird zu einer präventiverencisDer Qualifizierer ist so konzipiert, dass er zuverlässig ist (hoher Rückruf, d. h. keine schädlichen Komponenten übersieht), aber weniger Fehlalarme aufweist (sichere Komponenten nicht als schädlich meldet).
A Kritikalitätsbewertung wird als Priorisierungskriterium hinzugefügt, neben der Zugehörigkeit zu den Abhängigkeiten der Kunden und dem geringen Ruf des Herausgebers. Es ist klar, dass Projekte mit mehr Einfluss und Bedeutung früher in die Analyse einbezogen werden sollten. Wir werden das Rad hier nicht neu erfinden und folgen dem Kritikalitätsbewertung für Open-Source-Projekte.
Die Unterstützung für zusätzliche Ökosysteme ist in der Entwicklung. Weit verbreitete Technologien und Tools wie PHP- oder Jenkins-Plugins sind in der Roadmap.
Wir untersuchen außerdem, ob der manuelle Überprüfungsprozess durch KI unterstützt werden könnte, um die Analyse der wenigen ausgefeilteren Schadkomponenten zu optimieren.
Im nächsten und letzten Teil dieser Serie: „Open Source ausnutzen: Was Sie von den Bösewichten erwarten können“, werden wir uns auf die neuesten Methoden konzentrieren, mit denen die Angreifer ihre Angriffe heimlicher, schwerer zu erkennen, gezielter auf bestimmte Branchen und profitabler gestalten. Werden Ransomware-Angriffe über dieses Mittel durchgeführt? Wie nutzen die Bösewichte KI-Tools, um ausgefeiltere Malware zu verbreiten? Sind beliebte Top-Projekte gefährdet? Dies soll den Lesern einen Eindruck von diesem Wettrüsten vermitteln und zeigen, was sie kurzfristig (zweite Hälfte des Jahres 2024) und mittelfristig (2025) erwarten können.
Abschließend möchten wir einige Überlegungen dazu anstellen, welche kleinen Schritte die Community unternehmen könnte, ohne die Offenheit der Open-Source-Welt allzu sehr zu verändern. Ein effizienterer Mechanismus zum Melden von Malware an öffentliche Register und zum Teilen von Beweisen für potenziell bösartige Komponenten mit den Registern und der Community wäre beispielsweise ein kleiner Schritt in die richtige Richtung, um Bedrohungsakteuren die Tür zu verschließen.
Malware in Open-Source-Komponenten sollte die enormen Vorteile, die die Open-Source-Community unserer Gesellschaft gebracht hat, nicht zunichte machen.
- [1]. Unser Scanner erkennt Open-Source-Komponenten, auf die von den analysierten Softwareprojekten verwiesen wird, sodass das vollständige Abhängigkeitsdiagramm auf dem neuesten Stand bekannt ist, zumindest bei Projekten, die regelmäßig gescannt werden. Das Xygeni OSS stellt eine API bereit, die Kunden auch beim Whitelisting einer Komponente von Interesse verwenden können, einschließlich Informationen zu Schwachstellen und böswilligen Beweisen.
- [2]. Eine Leitlinie kann den Build unterbrechen, wenn eine Bedingung erkannt wird, die Sicherheitsproblemen entspricht. Sicherheitsbefunde wie eine kritische und erreichbare Sicherheitslücke oder die Verwendung einer unter Quarantäne gestellten Komponente könnten als schwerwiegend genug erachtet werden, um den Build für die betroffene Software zu unterbrechen.
- [3].Unsere Sicherheitsanalysten führen die Komponente oder ihre Installationsskripte bei Bedarf in einer Sandbox-Umgebung aus. MEW führt jedoch keine dynamische Analyse durch, hauptsächlich weil das bösartige Verhalten bei gezielten Angriffen nicht immer auftritt und weil Bedrohungsakteure Ausweichlogiken verwenden, um dynamische Analysen zu umgehen.
- [4]. Diese Technik erhielt einen Namen, Registered Domain Generation Algorithms oder RDGA, und neue Bedrohungsakteure wie die so genannten Revolver-Kaninchen hat bis zu 1 Million US-Dollar in 500 Domains investiert und damit gezeigt, wie profitabel die Cybercrime-Branche ist.
