Dependency-Confusion-Angriffe täuschen Entwickler

130.000 Dollar erhielt der Penetrationstester Alex Birsan im vergangenen Jahr im Rahmen verschiedener Bug-Bounty-Programme. Mithilfe einer neuen Angriffstaktik, den Dependency Confusion Attacks, demonstrierte er, wie er nicht autorisierten Code in den Netzwerken von Apple, Microsoft und 33 weiteren Unternehmen ausführen konnte.

Wenige Wochen später bewies ein anderer Sicherheitsforscher, dass Amazon, Slack, Lyft und andere große Unternehmen mit genau dieser Technik angegriffen worden waren. Nachdem das Softwareunternehmen JFrog mehr als 200 bösartige Code-Pakete gemeldet hat, scheint es, als hätten Cyberkriminelle Birsans Angriffstechnik im großen Stil übernommen.

Was sind Dependency-Confusion-Attacken?

Dependency-Confusion-Angriffe nutzen die Abhängigkeit ihrer Opferfirmen von Open-Source-Code aus, den diese aus Repositories wie NPM, PyPI oder RubyGems beziehen. Manche Unternehmenssoftware verbindet sich direkt mit diesen Quellen, um auf Code-Libraries zuzugreifen, die für Anwendungen gebraucht werden. In anderen Fällen speichern Entwickler diese sogenannten Dependencies aus Sicherheitsgründen intern. Dependency Confusion entsteht, wenn Entwickler glauben, Code aus einem internen Repository zu laden, tatsächlich aber bösartigen Code aus einem öffentlichen Repository beziehen.

Übersetzen könnte man die Attacke mit "Abhängigkeitsverwirrungsangriff". Doch was ist das? Bei Dependency Confusion Attacks handelt es sich um eine neuartige Form eines Supply-Chain-Angriffs. Dabei wird ein Nutzer dazu verleitet, eine bösartige Code-Datei aus einem öffentlichen Repository zu laden, anstelle der beabsichtigten gleichnamigen Datei aus einem internen Repository.

Birsan teilt ein Beispiel aus dem Jahr 2020, als er und Justin Gardner im Rahmen eines White-Hacking-Programms versuchten, PayPal zu hacken. Dabei stießen sie auf einen Node.js-Code, der für die interne Verwendung von PayPal gedacht war und sowohl öffentliche wie auch private Dependencies enthielt. Da bei PayPal nicht 100-prozentig klar war, von woher welches Paket mit Code bezogen wurde, kam Birsan auf die Idee, unter demselben Namen bösartigen Code einzuschmuggeln. Mit dieser Idee nahm er an weiteren Bug-Bounty-Programmen teil.

Bei seiner Angriffstaktik verlässt sich Birsan darauf, dass Software-Entwickler dazu neigen, Open-Source-Code grundsätzlich zu vertrauen, wenn sie ihn als Dependency für ihre eigenen Programme laden. Um öffentlich verfügbaren Code zu beziehen, gibt es Tools wie NPM-Registry für die Node.js-Plattform, RubyGems oder den Python Package Index.

Wenn Entwickler Pakete aus einer dieser Quellen herunterladen und verwenden, setzen sie letztendlich darauf, dass deren Herausgeber keine bösartigen Absichten haben und der Code sicher ist. Doch dieses Vertrauen kann von kriminellen Hackern ausgenutzt werden.

Deutsche Konzerne bedroht?

Auf einen solchen Vorgang schienen zwei Sicherheitsforscher des Sicherheitsforscher von JFrog gestoßen zu sein. Sie entdeckten bösartige NPM-Pakete, die seriöse Maintainer und Package-Namen der Firmen Bertelsmann, Bosch, Stihl und DB Schenker nutzten. Im Vergleich zu anderer Malware, die sie im NPM-Repository gefunden hatten, schien diese Malware allerdings besonders gefährlich zu sein.

Die Angreifer verfolgten offenbar den Plan, die Entwickler dieser Unternehmen in der Sicherheit zu wiegen, ihre eigenen Dependencies zu nutzen. Stattdessen luden sie Code, mit dem Angreifer die Kontrolle über infizierte Computer erlangen könnten.

Die Forscher schlussfolgerten, dass es sich bei den Paketen

• bertelsmannnpm

• boschnodemodule

• stihlnodemodules

• dbschenkernpm

um Dependency Confusion Attacks auf die vier deutschen Unternehmen handelte und meldeten den Vorgang bei den NPM-Entwicklern.

Neben JFrog entdeckte und meldete auch die Sicherheitsfirma ReversingLabs die bösartigen Pakete. Beide Unternehmen fanden heraus, dass die NPM-Pakete zu derselben Malware-Familie gehörten, die das Cybersicherheitsunternehmen Snyk im Monat zuvor gefunden hatte.

?? A malicious actor targeting a still unknown company is using an internal #JS package "gxm-reference-web-auth-server". If your company uses this package, make sure to inform your #AppSec team.

More info here. ?? #npm #JavaScript https://t.co/hGWO3SQ7LT

— Snyk (@snyksec) April 29, 2022

Nur eine Übung

Dass es sich doch um keine Bedrohung handelte, zeigte sich dann am 10. Mai, als das deutsche Unternehmen Code White, das sich auf Red Teaming und Pen Tests spezialisiert hat, die Verantwortung für die Hacks auf Snyk und die deutschen Unternehmen übernahm.

To clarify your questions: we're trying to mimic realistic threat actors for dedicated clients as part of our Security Intelligence Service and we brought our "own" package manager that supports yarn and npm. Feel free to DM us if you have additional questions. (2/2)

— Code White GmbH (@codewhitesec) May 10, 2022

Code White bedankte sich bei den Sicherheitsforschern für ihre Analysen und erklärte, dass es sich bei den Hacks um simulierte Angriffe handelte, die die jeweiligen Unternehmen beauftragt hatten.

Wie David Elze, CEO von Code White mitteilte, entwickelte ein Praktikant die Malware. Erfahrenere Entwickler wären wohl in der Lage, noch gefährlichere Programme zu schreiben – ganz zu schweigen von Cyberkriminellen, die die Schadsoftware für illegale Zwecke nutzen könnten.

At @codewhitesec even interns develop "advanced malware". Now think about the seasoned team members ?? But of course always in the best interest of our clients! https://t.co/azmdv6Z4sX

— David Elze (@datenschrott) May 10, 2022

Open-Source-Ökosysteme im Auge behalten

Zwar waren die Angriffe auf die deutschen Unternehmen Fehlalarme, dennoch erfreuen sich Dependency-Confusion-Attacken und NPM-Angriffe derzeit hoher Beliebtheit bei Kriminellen. Angesichts der schwerwiegenden Folgen, die ein erfolgreicher Hack haben kann, sollten Unternehmen Ressourcen investieren, um die genutzten Open-Source-Ökosysteme auf Schwachstellen und Exploits zu überwachen.

Wie Birsan in dem Blog-Beitrag schreibt, arbeiten große Technologiefirmen bereits daran, diese Art von Schwachstellen zu beheben. Dennoch habe er das Gefühl, dass es "hier noch mehr zu entdecken gibt". Birsan ist der Ansicht, dass Hacker immer wieder neue und clevere Wege finden werden, um an interne Paketnamen heranzukommen, für die sie dann verseuchte Alternativen öffentlich bereitstellen.

Auch die vermehrte Nutzung von Open-Source-Repositories und alternativen Programmiersprachen, die mehr oder weniger offizielle Möglichkeiten bieten, Dependencies zu laden, würden die Angriffsfläche für Confusion-Attacken vergrößern. Birsans Appell an Unternehmen lautet, sich mit dieser neuen Angriffstechnik vertraut zu machen, um Schwachstellen wie im PayPal-Code zu erkennen und mögliche Risiken abzuschwächen.

Lesetipp: Log4j – Ist Open Source das Problem?