Supply-Chain-Hack bricht 35 Unternehmen, darunter PayPal, Microsoft, Apple

  • Der ethische Hacker Alex Birsan entwickelte eine Möglichkeit, Schadcode in Open-Source-Entwickler-Tools zu injizieren, um Abhängigkeiten in organisationsinternen Anwendungen auszunutzen.

    Ein ethischer Hacker hat einen neuartigen Supply-Chain-Angriff demonstriert, der die Systeme von mehr als 35 Technologieunternehmen, darunter Microsoft, Apple, PayPal, Shopify, Netflix, Tesla und Uber, durch Ausnutzung von öffentlichen, quelloffenen Entwickler-Tools ausnutzte.

    Der vom Sicherheitsforscher Alex Birsan konzipierte Angriff injiziert Schadcode in gängige Tools zur Installation von Abhängigkeiten in Entwicklerprojekten, die typischerweise öffentliche Depots von Websites wie GitHub nutzen. Der Schadcode nutzt dann diese Abhängigkeiten, um die Malware über die internen Anwendungen und Systeme des Zielunternehmens zu verbreiten.

    Sobald er begann, Unternehmen mit seinem Angriff ins Visier zu nehmen, “war die Erfolgsquote einfach erstaunlich”, sagte Birsan in einem Beitrag auf Medium, der den Angriff ausführlich beschreibt.

    Alles in allem wurde die von ihm ausgenutzte Schwachstelle, die er “Dependency Confusion” nennt, bis heute in mehr als 35 Unternehmen entdeckt, und zwar in drei getesteten Programmiersprachen – Python, Ruby und Java.

    “Die überwiegende Mehrheit der betroffenen Unternehmen fällt in die Kategorie 1000+ Mitarbeiter, was höchstwahrscheinlich die höhere Prävalenz der internen Bibliotheksnutzung in größeren Organisationen widerspiegelt”, so Birsan.

    Der Forscher erhielt mehr als $130.000 in beiden Bug Bounties und vorab genehmigten finanziellen Vereinbarungen mit den betroffenen Unternehmen, die alle zustimmten, getestet zu werden. Das ursprüngliche Ziel des Hacks, PayPal, sowie Apple und das kanadische Unternehmen Shopify, trugen jeweils 30.000 $ zu diesem Betrag bei.

    Birsan sagte, dass er auf die Idee kam, das Vertrauen zu erforschen, das Entwickler in einen “einfachen Befehl” setzen, “pip install package_name”, den sie üblicherweise mit Programmiersprachen wie Python, Node, Ruby und anderen verwenden, um Abhängigkeiten zu installieren, oder Codeblöcke, die zwischen Projekten geteilt werden,.

    Diese Installationsprogramme – wie Python Package Index für Python oder npm und die npm-Registry für Node – sind in der Regel an öffentliche Code-Repositories gebunden, in die jeder frei Code-Pakete hochladen kann, die andere nutzen können, so Birsan.

    Die Verwendung dieser Pakete ist jedoch mit einem gewissen Maß an Vertrauen verbunden, dass der Code authentisch und nicht bösartig ist, bemerkte er.

    “Wenn Sie ein Paket aus einer dieser Quellen herunterladen und verwenden, vertrauen Sie im Wesentlichen dem Herausgeber, dass der Code auf Ihrem Rechner ausgeführt wird”, schrieb Birsan. “Kann dieses blinde Vertrauen also von böswilligen Akteuren ausgenutzt werden?”

    Code-Inspirierte Idee

    Birsan beschloss, diese Frage im letzten Sommer zu beantworten, während er versuchte, PayPal mit einem anderen ethischen Hacker, Justin Gardner, zu hacken, der ihm “ein interessantes Stück Node.js-Quellcode, das er auf GitHub gefunden hatte, mitteilte”, so Birsan.

    Der Code, der für den internen Gebrauch von PayPal gedacht war, hatte in seiner package.json-Datei eine Mischung aus öffentlichen und privaten Abhängigkeiten, darunter öffentliche Pakete von npm sowie nicht-öffentliche Paketnamen, die höchstwahrscheinlich intern von PayPal gehostet wurden und zu diesem Zeitpunkt nicht in der öffentlichen npm-Registry existierten.

    “Was passiert, wenn bösartiger Code unter diesen Namen auf npm hochgeladen wird?” fragte sich Birsan laut dem Posting. “Ist es möglich, dass einige der internen Projekte von PayPal beginnen, die neuen öffentlichen Pakete statt der privaten zu verwenden?”

    Die kurze Antwort lautet: “Ja”, fand er heraus. Birsan wendete seine Idee an, um seine eigenen “bösartigen” Node-Pakete in die npm-Registry unter all den nicht beanspruchten Namen hochzuladen, die von jedem Computer, auf dem sie installiert waren, “nach Hause telefonieren” würden, erklärte er. Der Code würde ihn benachrichtigen, wenn er auf einem der PayPal-eigenen Server installiert würde.

    Er erstellte ein Node-Paket, das durch sein Preinstall-Skript grundlegende Informationen über jeden Rechner sammelt, auf dem es installiert wird. Um dann ein Gleichgewicht zwischen der Möglichkeit, eine Organisation anhand der Daten zu identifizieren, zu finden, protokollierte er den Benutzernamen, den Hostnamen und den aktuellen Pfad jeder einzelnen Installation.

    “Zusammen mit den externen IPs waren das gerade genug Daten, um Sicherheitsteams dabei zu helfen, möglicherweise verwundbare Systeme auf der Grundlage meiner Berichte zu identifizieren, ohne dass meine Tests mit einem tatsächlichen Angriff verwechselt werden”, sagte er.

    DNS für Datenexfiltration

    Nachdem er sich einen Weg nach drinnen gebahnt hatte, entschied sich Birsan, DNS-Exfiltration zu nutzen, um Daten von Organisationen zu ihm zurückzuschicken, “da er wusste, dass die meisten der möglichen Ziele tief in gut geschützten Unternehmensnetzwerken liegen würden”, sagte er. Birsan vermutete außerdem, dass die Wahrscheinlichkeit, dass die Daten auf dem Weg nach draußen blockiert oder entdeckt werden, dadurch geringer sein würde, und

    Um dies zu erreichen, hexcodierte er die Daten und verwendete sie als Teil einer DNS-Anfrage, die seinen benutzerdefinierten autoritativen Namensserver entweder direkt oder über zwischengeschaltete Resolver erreichte. Er konfigurierte den Server so, dass er jede empfangene Abfrage protokollierte und im Wesentlichen eine Aufzeichnung jedes Rechners führte, von dem die Pakete heruntergeladen wurden, erklärte Birsan.

    Nachdem er die grundlegende Angriffsmethode entwickelt hatte, untersuchte Birsan, wie er ein möglichst breites Netz an Zielorganisationen auswerfen und die Anzahl der Ökosysteme, die er angreifen konnte, erweitern konnte. Er portierte den Code sowohl auf Python als auch auf Ruby, damit er ähnliche Pakete in PyPI (Python Package Index) bzw. RubyGems hochladen konnte.

    Wichtiger noch: Er durchkämmte private Paketnamen von Zielfirmen, um möglichst viele relevante Abhängigkeitsnamen zu finden. Seine Suche ergab, dass viele andere Namen auf GitHub, sowie auf den großen Paket-Hosting-Diensten zu finden waren – in internen Paketen, die versehentlich veröffentlicht worden waren – und sogar in Beiträgen in verschiedenen Internetforen.

    Bei seinen Bemühungen stellte sich heraus, dass der beste Ort, um private Paketnamen zu finden, Javascript-Dateien waren. Das liegt daran, dass es üblich ist, dass package.json-Dateien, die die Namen der Abhängigkeiten eines Javascript-Projekts enthalten, während des Build-Prozesses in öffentliche Skriptdateien eingebettet werden, wodurch interne Paketnamen offengelegt werden, so Birsan.

    In ähnlicher Weise können durchgesickerte interne Pfade oder require()-Aufrufe innerhalb dieser Dateien auch Namen von Abhängigkeiten enthalten, Szenarien, die er bei Apple, Yelp und Tesla entdeckt hat, fügte er hinzu.

    Allerdings bedeutet die Anfälligkeit von Javascript für den Angriff nicht unbedingt, dass Python und Ruby weniger anfällig sind, merkte Birsan an. Obwohl er bei seinen Recherchen nur interne Ruby-Gem-Namen von acht Unternehmen identifizierte, erwiesen sich vier dieser Unternehmen – darunter Shopify – als anfällig für Abhängigkeitsverwirrungen durch RubyGems, sagte er.

    Einige Teile dieses Artikels stammen aus:
    threatpost.com