Sicherheitsforscher von Aqua Nautilus haben aufgedeckt, dass Bedrohungsakteure einen Timing-Angriff auf der API von npm durchführen könnten, um private Pakete aufzuspüren.
Der Timing-Angriff auf den JavaScript-Paketmanager kann sogar dann funktionieren, wenn npm für nicht autorisierte oder nicht authentifizierte Nutzer, die den folgenden Endpunkt anfordern, einen 404-Fehler zurückgibt (allgemeines Muster):
https://registry.npmjs.org/@<scope_name>/<secret_package_name>
Ein böswilliger Angreifer kann mehrere aufeinanderfolgende Anfragen senden, um festzustellen, ob das Paket existiert oder entfernt wurde. Ein solcher Timing-Angriff besteht darin, „die Zeit zu vergleichen, die benötigt wird, um nach einem vorhandenen privaten Paket und einem nicht vorhandenen privaten Paket zu suchen“, schrieb.
Die Forscher stellten fest, dass etwa fünf aufeinanderfolgende API-Anfragen erforderlich sind, damit sich zeigt, dass die API-Antwort deutlich länger dauert, wenn das Paket existiert oder entfernt wurde: 648 ms gegenüber 101 ms. Diese Lücke ermöglicht es, den Aufspürvorgang zu automatisieren, indem eine Liste potenzieller Paketnamen erstellt wird, die getestet werden sollen.
Das Problem wurde im März 2022 dem Bug-Bounty-Programm von GitHub gemeldet, doch die Antwort der Plattform ist nicht beruhigend: „Aufgrund dieser architektonischen Einschränkungen können wir nicht verhindern, dass Timing-Angriffe feststellen, ob ein bestimmtes privates Paket existiert.“
Siehe die wichtigsten Tools für Code-Debugging und Codesicherheit
Wie Hacker den Konstruktionsfehler der API ausnutzen können
Kadkodas Vorgehensweise ist denkbar unkompliziert: Er erstellte ein privates npm-Paket unter einer „Zufallsorganisation“ und lud einige Dateien hoch.
Anschließend überprüfte er mit einem authentifizierten und autorisierten Nutzer (einem Mitglied der Organisation), dass das Paket existierte. Dasselbe tat er mit einem nicht authentifizierten Nutzer, stellte bei einer einzigen aufeinanderfolgenden Anfrage jedoch keine nennenswerten Unterschiede fest. Erst nach fünf aufeinanderfolgenden Anfragen von „verschiedenen Systemen“ wurden die Ergebnisse aussagekräftig:
Diese Informationen könnten dazu missbraucht werden, private Paketnamen offenzulegen und verschiedene böswillige Techniken wie Typosquatting oder Dependency Confusion einzusetzen, um die Software-Lieferkette zu hacken.
Dazu könnten Angreifer allgemeine oder stärker angepasste Wörterbücher mit Namen verwenden, die den Namen der Organisation enthalten. Es ist nicht ungewöhnlich, dass Entwicklerteams eine Namenskonvention anwenden, um für Ordnung und Übersichtlichkeit zu sorgen.
Laut den Forschern von Aqua könnte ein Angreifer außerdem öffentliche Datensätze nutzen, um eine Liste entfernter öffentlicher Pakete zu erhalten, die in private Pakete umgewandelt worden sein könnten.
Es ist definitiv nicht das erste Mal, dass npm (und andere Plattformen) von solchen Bedrohungen betroffen ist, die viele Organisationen gefährden (siehe Software-Lieferkette: Eine riskante Zeit für Abhängigkeiten).
„In den vergangenen Jahren haben wir einen dramatischen Anstieg der Angriffe auf die Lieferkette um Hunderte von Prozentpunkten erlebt“, schrieb Kadkoda. „In einigen Fällen besteht das Ziel der Bedrohungsakteure darin, Zugriff auf Open-Source-Pakete/-Projekte zu erlangen und sie zu manipulieren. In anderen Fällen geben sie sich als private oder öffentliche Pakete beziehungsweise Projekte aus und schreiben deren Namen absichtlich falsch, um arglose Opfer dazu zu bringen, ihr bösartiges Paket statt beliebter legitimer Pakete herunterzuladen.“
So schützen Sie sich vor dem npm-Timing-Angriff
Aqua Nautilus empfiehlt, alle privaten und öffentlichen Pakete zu erfassen – eine gute Vorgehensweise, die sich als „Kenne deine Lieferkette“ zusammenfassen lässt.
Die Forscher erklärten, Entwickler- und Sicherheitsteams sollten außerdem nach Typosquatting-, ähnlich aussehenden oder sich als andere ausgebenden Paketen suchen.
„Vergewissern Sie sich, dass es keine anderen Pakete mit demselben Namen wie Ihre internen privaten Pakete gibt“, erklärten sie. „Wenn Sie ähnliche Pakete finden, stellen Sie sicher, dass sie keine Malware enthalten, und informieren Sie die zuständigen Stakeholder.
„Wenn Sie keine öffentlichen Pakete finden, die Ihren internen Paketen ähneln, sollten Sie die Erstellung öffentlicher Pakete als Platzhalter in Erwägung ziehen, um solche Angriffe zu verhindern.“
Da große Softwareplattformen erheblichen Einschränkungen unterliegen, kann die Behebung fehlerhafter API-Architekturen und anderer Sicherheitslücken lange dauern oder sogar als „wird nicht behoben“ eingestuft werden. Das bedeutet jedoch nicht, dass Unternehmen alle Drittanbieterdienste aufgeben und alles intern selbst erledigen sollten.
- Der Do-it-yourself-Ansatz ist nicht immer lohnend, da er die Verantwortung ans Ende der Kette verlagert, ohne eine bessere Sicherheit zu garantieren.
- Die Gesamtkosten würden deutlich steigen und könnten die Infrastruktur sogar in einen Wartungs- und Sicherheitsalbtraum verwandeln.
Ein weiterer guter Ansatz besteht darin, die Zahl privater Pakete nicht unnötig zu erhöhen – für Entwicklerteams ist das zwar ziemlich verlockend, aber nicht immer der beste Weg, da sich viele Dienstprogramme zusammenfassen und umgestalten lassen. Je mehr private Pakete Sie erstellen, desto größer wird definitionsgemäß die Angriffsfläche.
Viele Teams beginnen mit internen Tools, die sich möglicherweise zu großartigen öffentlichen Open-Source-Paketen entwickeln könnten, aber nicht alles muss am selben Ort bleiben. Niemand braucht die vollständige Historie. Erstellen Sie einfach ein öffentliches Repository mit demselben Namen und lassen Sie es leer, bis es an der Zeit ist, es öffentlich zu teilen.
So vermeiden Sie auch unerwünschte Offenlegungen über Git-Commits.
Nicht zuletzt sollten Sie dokumentierte Verfahren für die Installation und Nutzung von Entwicklungsumgebungen haben und verhindern, dass Entwickler Pakete installieren (und committen). Das Hinzufügen, Aktualisieren oder Entfernen von Paketen erfordert eine Überprüfung durch das Team.
Lesen Sie als Nächstes: Neue Open-Source-Sicherheitsinitiative gegen Angriffe auf die Lieferkette