{"id":22187,"date":"2022-02-25T15:02:18","date_gmt":"2022-02-25T14:02:18","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=22187"},"modified":"2023-06-18T17:48:20","modified_gmt":"2023-06-18T15:48:20","slug":"software-dependencies-die-gefahr-aus-der-tiefe","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2022\/02\/25\/software-dependencies-die-gefahr-aus-der-tiefe\/","title":{"rendered":"Software Dependencies – Die Gefahr aus der Tiefe"},"content":{"rendered":"\n

“Unbekannte infiltrieren Paketmanager npm und verseuchen Tools mit Schadcode” hei\u00dft es am 08.11.2021 auf heise online<\/a>. Die Nutzeraccounts der Maintainer von coa<\/a> und rc<\/a> wurden gehackt und neue Versionen dieser Pakete hochgeladen (inklusive Malware). Zwar denken sich bestimmt viele bei coa und rc: “Aha toll”, aber sp\u00e4testens bei React oder Angular sollte man hellh\u00f6rig werden. Schlie\u00dflich werden diese JavaScript-Frameworks Millionenfach genutzt. Und wer jetzt richtig geraten hat, ahnt schon: Beide dieser Frameworks nutzen diese Bibliotheken auf die ein oder andere Weise. Dieser Blockartikel beschreibt die Risiken von Software-Dependencies in Produktivsystemen und Wege, damit umzugehen.<\/p>\n\n\n\n

\"\"<\/a>
Karikatur eines Softwareprojekts (Quelle: GitHub<\/a>)<\/figcaption><\/figure><\/div>\n\n\n\n\n\n\n\n

Der Fall npm<\/h2>\n\n\n\n

Begriffserkl\u00e4rung:<\/strong> Dieser Artikel verwendet h\u00e4ufig die Begriffe Abh\u00e4ngigkeit\/Dependency, Bibliothek\/Library oder Paket\/Package. Diese Begriffe werden im Kontext des Artikels gleichbedeutend verwendet und bezeichnen externe Software-Bausteine, die f\u00fcr die Erstellung neuer Software verwendet werden.<\/p>\n\n\n\n

Wer schon einmal Software entwickelt hat, wei\u00df, wie undurchsichtig Software-Dependencies sind. Ich ben\u00f6tige Package A, Package A ben\u00f6tigt wiederum Package B, C und D und ehe wir uns versehen, haben wir das ganze Alphabet abgearbeitet und unser Programm kann gerade einmal “Hello World” auf der Kommandozeile ausgeben.<\/p>\n\n\n\n

Das folgende Bild zeigt die Dependencies und geschachtelten Dependencies einer neu erstellten React App und macht deutlich, dass es quasi unm\u00f6glich ist den \u00dcberblick \u00fcber alle verwendeten Pakete und deren Ersteller zu behalten (Jeder Punkt stellt eine Dependency dar; das eigentliche Projekt und seine Dependencies sind gelb bzw. wei\u00df hervorgehoben). <\/p>\n\n\n\n

\"\"<\/a>
Grafische Darstellung der Dependencies<\/a> einer neu erstellten React App<\/a>, erstellt mit npmgraph.an<\/a><\/figcaption><\/figure>\n\n\n\n

Im Fall von coa und rc war ich einer der ersten, der von diesem Problem erfahren hat. Zuf\u00e4llig habe ich in diesen ca. 2h versucht ein neues React-Projekt mit create-react-app<\/a> <\/a>anzulegen. Die Antwort von React war:<\/p>\n\n\n\n

Error: Cannot find module '\/Users\/...\/node_modules\/coa\/compile.js'<\/code><\/pre>\n\n\n\n
Begriffserkl\u00e4rung:<\/strong> Bei npm<\/a> handelt es sich um einen Paketmanager f\u00fcr JavaScript, \u00e4hnlich wie yarn<\/a>, pip<\/a> und im weiteren Sinn Maven<\/a>. Die von npm bereitgestellten Packages werden dort von den Erstellern hochgeladen, versioniert und verwaltet. Nutzer k\u00f6nnen die dort liegenden Packages mittels “npm install” in ihre eigenen Projekte einbinden. Ein in npm angebotenes Package kann wiederum andere npm-Packages ben\u00f6tigen, um zu funktionieren.<\/p>\n\n\n\n
Irgendwo in der Toolchain wurde auf das nicht existente Module compile.js im Package coa verwiesen. Im Github von create-react-app<\/a> war die Diskussion schon im vollen Gange und recht schnell wurde klar: coa wurde kompromittiert<\/a>. Genauso schnell begann die Diskussion, welche Folgen das haben k\u00f6nnte, denn bis dato wusste noch niemand, um welche Art Malware es sich handelt. Mittlerweile wissen wir, es handelt sich “nur” um den Qakbot-Trojaner, welcher beispielsweise Banking-Informationen von Privatnutzern auslesen soll. <\/p>\n\n\n\n
Bei diesem Angriff handelt es sich weder um den ersten, noch um den letzten dieser Art. Erst im Monat vorher, wurde beispielsweise ua-parser-js<\/a> mit demselben Trojaner <\/a>kompromittiert. Und im Januar 2022 machte Marak Squires<\/a> auf sich aufmerksam, als er seine eigenen, weit verbreiteten npm-Pakete faker<\/a> und colors<\/a> mit Schadcode versetzte, als Auflehnung gegen den Missbrauch von Open-Source Software.<\/p>\n\n\n\n
Im Fall von faker und colors, waren die Ausma\u00dfe bereits verheerend. Die Bibliotheken haben zusammen fast 23 Millionen Downloads in einer Woche und \u00fcber 21.000 Projekte, die auf diese Bibliotheken aufbauen. Von heute auf morgen k\u00f6nnen diese nicht mehr neu deployt werden. An dieser Stelle reden wir von einer Supply Chain Attacke. In diesen F\u00e4llen sind diese zwar nicht mit weitreichenden Folgen verbunden, sondern “nur” mit etwas Downtime. Im Vergleich dazu handelt es sich bei coa, rc und ua-parser-js um Supply Chain Attacken, die verheerende Ausma\u00dfe annehmen k\u00f6nnen.<\/p>\n\n\n\n
Auswirkungen<\/h2>\n\n\n\n
Die m\u00f6glichen Auswirkungen von solchen Attacken werden klar, wenn man sich \u00fcber den Deployment-Prozess eines Unternehmens Gedanken macht. In modernen Softwareprojekten ist das Deployment (hoffentlich) automatisiert \u00fcber sogenannte CI\/CD Pipelines. Das bedeutet:<\/p>\n\n\n\n
  1. Ich lade einen neuen Stand meines Quellcodes in die Versionsverwaltung des Projekts (Push). <\/li>
  2. Eine Pipeline wird automatisch gestartet.
    1. In einem Testsystem wird der Build des Projekts ausgef\u00fchrt (hierf\u00fcr werden wieder alle Dependencies installiert)<\/li>
    2. Tests werden ausgef\u00fchrt<\/li>
    3. Der Build wird in die Produktivumgebung geladen.<\/li><\/ol><\/li><\/ol>\n\n\n\n
      \"\"<\/a>
      CI\/CD Pipeline Beispiel von GitLab CI\/CD<\/a><\/figcaption><\/figure>\n\n\n\n
      Ist in diesem Szenario eine kompromittiert Dependency enthalten, wird unter Umst\u00e4nden das ganze System infiltriert. Das k\u00f6nnte zum Beispiel dazu f\u00fchren, dass sensible Daten mitgelesen oder geklaut werden. Sollte man so Zugriff auf Server erhalten, ist dieser anf\u00e4llig f\u00fcr Remote Code Execution (RCE) Angriffe. Also ein Angriff, in dem ein Hacker Code auf dem Zielsystem ausf\u00fchrt. Das wird normalerweise durch Konfigurationen verhindert, k\u00f6nnte aber umgangen werden, wenn der Code Aufruf von innerhalb der Serverumgebung kommt.<\/p>\n\n\n\n
      Und selbst wenn nicht dieser Fall eintritt, kann eine fehlerhafte Dependency immer noch dazu f\u00fchren, dass die konfigurierten Pipelines nicht mehr funktionieren und die Entwicklung zum Stillstand bringt (siehe Fall coa<\/a>).<\/p>\n\n\n\n
      Letzten Endes sind die Auswirkungen davon abh\u00e4ngig, auf welchen Systemen die infiltriere Software landet.<\/p>\n\n\n\n
      Der erste Schritt, um sich abzusichern und in den meisten F\u00e4llen wohl auch gegangen wird, ist die Verwendung von Docker Containern oder VMs. Dadurch wird ein Neu-Deployment vereinfacht und (wahrscheinlich) verhindert, dass Zugriff auf unterliegende Systeme erlangt wird. In automatischen Build Pipelines ist das der Standard. Sich hierbei auf bew\u00e4hrte Systeme zu st\u00fctzen, ist zwar erstmal gut, jedoch sollte man dem nicht blind vertrauen, wie der Fall von log4j 2021 gezeigt hat.<\/p>\n\n\n\n
      Das Problem mit Docker<\/h2>\n\n\n\n
      Docker ist toll und hilft uns auf so vielen Ebenen, jedoch bef\u00fcrchte ich, dass es h\u00e4ufig leichtfertig verwendet wird. Es gibt viele Dinge, die beachtet werden m\u00fcssen und Schritte, die man befolgen sollte, um sein. Ein paar Stichpunkte hierzu sind:<\/p>\n\n\n\n