CSO
Alternatives Drucklayout:
› reiner Text
Link: https://www.csoonline.com/de/a/dependency-confusion-angriffe-taeuschen-entwickler,3673926

Neuartiger Supply-Chain-Angriff

Dependency-Confusion-Angriffe täuschen Entwickler

Datum:13.05.2022
Autor(en):Melanie Staudacher
Dependency-Confusion-Attacken, in deren Rahmen Entwickler unbeabsichtigt schädlichen Code in Unternehmensanwendungen integrieren, nehmen zu. Eine deutsche Sicherheitsfirma hat in einer Simulation die Risiken aufgezeigt.

Über Code aus öffentlichen Repositories schleusen Hacker Malware in Unternehmen – ohne, dass die Entwickler es bemerken.
Foto: New Africa - shutterstock.com

130.000 Dollar erhielt der Penetrationstester1 Alex Birsan im vergangenen Jahr im Rahmen verschiedener Bug-Bounty-Programme2. 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-Pakete3 gemeldet hat, scheint es, als hätten Cyberkriminelle Birsans Angriffstechnik4 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-Angriffs5. 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 Beispiel6 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-Code7 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-Registry8 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 JFrog9 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 ReversingLabs10 die bösartigen Pakete. Beide Unternehmen fanden heraus, dass die NPM-Pakete zu derselben Malware-Familie gehörten, die das Cybersicherheitsunternehmen Snyk11 im Monat zuvor gefunden hatte.

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 Teaming12 und Pen Tests spezialisiert hat, die Verantwortung für die Hacks auf Snyk und die deutschen Unternehmen übernahm.

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.

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-Beitrag13 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?14

Links im Artikel:

1 https://www.csoonline.com/de/a/was-ethical-hacker-koennen-muessen,3671931
2 https://www.csoonline.com/de/a/zoom-zahlt-millionen-an-hacker,3673861
3 https://jfrog.com/blog/large-scale-npm-attack-targets-azure-developers-with-malicious-packages/
4 https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610
5 https://www.csoonline.com/de/a/so-wird-ihre-lieferkette-resilient,3673800
6 https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610
7 https://www.computerwoche.de/a/open-source-zwischen-mythos-und-realitaet,3548830
8 https://www.npmjs.com/
9 https://jfrog.com/blog/npm-supply-chain-attack-targets-german-based-companies/
10 https://blog.reversinglabs.com/blog/npm-dependency-confusion-hacks-target-german-firms
11 https://snyk.io/blog/npm-dependency-confusion-attack-gxm-reference/
12 https://www.csoonline.com/de/a/so-trainieren-sie-effektiv-den-ernstfall,3673742
13 https://medium.com/@alex.birsan/dependency-confusion-4a5d60fec610
14 https://www.csoonline.com/de/a/log4j-ist-open-source-das-problem,3673763

IDG Tech Media GmbH
Alle Rechte vorbehalten. Jegliche Vervielfältigung oder Weiterverbreitung in jedem Medium in Teilen oder als Ganzes bedarf der schriftlichen Zustimmung der IDG Tech Media GmbH. dpa-Texte und Bilder sind urheberrechtlich geschützt und dürfen weder reproduziert noch wiederverwendet oder für gewerbliche Zwecke verwendet werden. Für den Fall, dass auf dieser Webseite unzutreffende Informationen veröffentlicht oder in Programmen oder Datenbanken Fehler enthalten sein sollten, kommt eine Haftung nur bei grober Fahrlässigkeit des Verlages oder seiner Mitarbeiter in Betracht. Die Redaktion übernimmt keine Haftung für unverlangt eingesandte Manuskripte, Fotos und Illustrationen. Für Inhalte externer Seiten, auf die von dieser Webseite aus gelinkt wird, übernimmt die IDG Tech Media GmbH keine Verantwortung.