Die Software-Lieferkette ist ein kritisches Element im Lebenszyklus von Anwendungen und Websites. Die für die moderne Softwareentwicklung typischen Interdependenzen und Komponenten können die Angriffsfläche vergrößern und Hackern mitunter ermöglichen, robuste Sicherheitsebenen zu umgehen, die Sie Ihrer Infrastruktur hinzugefügt haben.
Tatsächlich kann bereits eine einzige Schwachstelle in der Codebasis ausreichen, um die gesamte Lieferkette zu kompromittieren. Das Problem ist, dass moderne Projekte unzählige Abhängigkeiten haben. Diese Situation ist als „Dependency Hell“ bekannt, da Ihre Abhängigkeiten wiederum eigene Abhängigkeiten haben und so weiter. Der Versuch, all diese Abhängigkeiten nachzuverfolgen, könnte Sie in den Wahnsinn treiben.
Darüber hinaus stützt sich die Softwareentwicklung stark auf Open-Source-Plattformen und Drittanbieter, schlicht weil dies den Prozess beschleunigt und Entwicklern Standardbibliotheken zur Verfügung stellt. Eine große Zahl von Personen oder Organisationen pflegt den Code, sodass sich Sicherheitslücken nur schwer verhindern lassen.
Nirgendwo wird dies vielleicht deutlicher als bei Paketmanagern. Kürzlich hat das RubyGems-Paket-Repository eine kritische Schwachstelle gepatcht, die kürzlich als CVE-2022-29176 erfasst wurde. RubyGems.org ist der Hostingdienst für Gems der Ruby-Community – so wie NPM die offizielle Registry für die JavaScript-Welt ist.
Diese gigantischen Plattformen hosten Hunderttausende Pakete mit Millionen von Downloads und stehen ständig unter Beschuss. Hacker versuchen regelmäßig, sie zu kapern, Dependency-Confusion- oder Typosquatting-Angriffe durchzuführen, und inzwischen besteht sogar das Risiko der Selbstsabotage.
Lesen Sie auch: Wie Hacker die Software-Lieferkette kompromittieren
Die RubyGems-Schwachstelle im Detail
Die Schwachstelle CVE-2022-29176 wurde auf RubyGems.org gefunden, der Paket-Registry für die gesamte Ruby-Programmiersprachen-Community, und ermöglichte es „jedem Benutzer, bestimmte Gems zu entfernen und zu ersetzen, selbst wenn dieser Benutzer dazu nicht berechtigt war“.
Allerdings galten noch weitere Bedingungen: Das Gem, also das Ruby-Paket, „musste bei seiner Erstellung innerhalb von 30 Tagen einen oder mehrere Bindestriche im Namen enthalten ODER seit über 100 Tagen nicht aktualisiert worden sein“. Dennoch konnte es auf der Plattform auf zahlreiche Gems zutreffen.
Ein Angreifer hätte den Inhalt eines legitimen Gems durch ein Skript zum Diebstahl von Zugangsdaten oder einen Krypto-Miner ersetzen können – eine kritische Schwachstelle.
RubyGems.org erhielt keine Beschwerden von Gem-Besitzern, daher ist es gut möglich, dass die kritische Schwachstelle noch nicht ausgenutzt wurde. In jedem Fall empfiehlt Bundler, der Paketmanager für Ruby, „Bundler --frozen or --deploymentin CI und während der Bereitstellung zu verwenden.“
Diese Best Practice verhindert, dass Ihre Ruby-Anwendung unbemerkt auf eine gekaperte Version wechselt – genau das wollen Hacker mit einem solchen Exploit erreichen.
Benutzer, die ihre Anwendung auf frühere Exploits überprüfen müssen, können die Datei Gemfile.lock untersuchen und nach unerwünschten Plattformänderungen suchen, die bei Gems aufgetreten sind, obwohl sich die Versionsnummer nicht geändert hat.
Lesen Sie auch: SBOMs: Die Software-Lieferkette absichern
Plattformen sind anfällig für Angriffe
Ob RubyGems oder NPM oder sogar pip für Python-Pakete: Solche großen Plattformen sind kritische Bestandteile der Software-Lieferkette. NPM steht regelmäßig wegen verschiedener Kampagnen in den Schlagzeilen, die Millionen von Projekten und Benutzern betreffen.
Das Team von JFrog Security Research entdeckte kürzlich einen neuen NPM-Angriff auf die Lieferkette, ähnlich einem Angriff, über den zuvor bei Azure berichtet wurde. Die Hacker nutzten einen Dependency-Confusion-Angriff, bei dem deutsche Industrieunternehmen ins Visier genommen wurden: Bertelsmann, Bosch, Stihl und DB Schenker.
Die Forscher bezeichneten dies als „sehr gezielten“ Angriff. Jfrog aktualisierte den Beitrag und erklärte, man habe zum Zeitpunkt der Veröffentlichung nicht feststellen können, ob tatsächlich ein Angreifer oder ein „sehr aggressiver“ Pentester hinter dem Angriff steckte.
Es gab verschiedene IoCs (Indicators of Compromise), doch die Hacker nahmen sich nicht die Zeit, den Namen ihres Ziels auf NPM zu verbergen, und verwendeten einen öffentlichen Obfuscator, der sich leicht erkennen und rückgängig machen lässt – für Cyberkriminelle ist das eher ungewöhnlich.
Bei Dependency Confusion werden die Namen privater Pakete verwendet, um öffentliche Pakete mit einer höheren Versionsnummer zu erstellen. Wenn Benutzer eine Installation oder ein Update ausführen, wird der Paketmanager verwirrt und lädt das Paket, das offenbar das aktuellste ist.
Für Hacker, die die Lieferkette angreifen wollen, gibt es zahlreiche Möglichkeiten. Dependency Confusion und Typosquatting sind raffinierte Techniken, aber nicht unbedingt die einfachsten in der Umsetzung.
Der Diebstahl der Zugangsdaten von Besitzern oder Maintainer kann ein praktikablerer Ansatz sein, da sich Angreifer als legitime Benutzer ausgeben können, um alle möglichen Missbräuche zu begehen – etwa Malware oder Backdoors an Millionen von Installationen zu verteilen.
Lesen Sie auch: Die besten Tools für Code-Debugging und Codesicherheit
So schützen Sie sich vor Angriffen auf die Lieferkette
Meistens können Sie eine Bedrohung der Lieferkette nur eindämmen, aber es gibt einfache Maßnahmen, mit denen Sie Ihre Risiken reduzieren können:
- Befolgen Sie Best Practices für Deployment und CI (z. B. die Empfehlungen von Bundler).
- Führen Sie regelmäßig Sicherheitsprüfungen und Audits durch, und bringen Sie niemals etwas Ungetestetes in der Live-Produktionsumgebung zum Einsatz.
- Registrieren Sie eine öffentliche Registry unter dem Namen Ihrer privaten Registry, um Typosquatting-Angriffe zu verhindern.
- Verwenden Sie eine strengere Richtlinie für Anbieter (z. B. die exakte Versionsnummer statt „*“ oder „^“, um stille Updates bei Installationen zu verhindern).
- Wenn Sie Besitzer oder Maintainer eines Pakets sind, aktivieren Sie die Multi-Faktor-Authentifizierung.
- Stellen Sie niemals Konfigurationsdateien oder Sourcemaps in der Produktion bereit.
- Halten Sie alle Abhängigkeiten aktuell.
Der letzte Punkt wirkt etwas paradox, da Hacker versuchen, Update-Mechanismen zu kompromittieren, um ihre Opfer zur Bereitstellung von Malware zu verleiten. Die Bedrohungslandschaft entwickelt sich jedoch zu schnell, um Sicherheitspatches zu vernachlässigen. Veraltete Komponenten gehören zu den allerersten Elementen, die Hacker überprüfen, um festzustellen, ob sie eine bekannte Schwachstelle ausnutzen können.
Die Software-Lieferkette ist voller Gefahren, und dennoch sind diese externen Ressourcen wichtig, um die Entwicklung zu beschleunigen und Praktiken zu standardisieren. Als Entwickler können Sie den Code, den Sie nicht pflegen, nicht kontrollieren – und heutzutage stammt der größte Teil des Codes in Ihrem Projekt nicht von Ihnen. Die beste Antwort besteht darin, Ihre Sicherheitspraktiken konsequent im Blick zu behalten.
Lesen Sie als Nächstes: Die besten Tools für das Management von Drittanbieterrisiken (TPRM)