Software Supply Chain Angriffe: Wie kompromittierte npm- und PHP-Pakete Ihr System gefährden
Ein Software supply chain Angriff zielt nicht auf Ihre Anwendung direkt. Er zielt auf die Pakete und Bibliotheken, die Ihre Anwendung verwendet. Das macht ihn besonders gefährlich: Sie haben alles richtig gemacht, und trotzdem ist Ihr System kompromittiert.
Log4Shell war das bekannteste Beispiel. Eine Sicherheitslücke in einer weit verbreiteten Java-Bibliothek. Millionen von Systemen weltweit waren betroffen, auch solche die niemand für angreifbar gehalten hatte. Legacy-Systeme mit ungepatchten technischen Schulden traf es besonders hart.
Das Prinzip gilt bis heute. Und es wird häufiger genutzt.
Was ist ein Software Supply Chain Angriff?
Moderne Software besteht selten aus einer einzigen Datei. Sie besteht aus Ihrer Anwendung plus dutzenden oder hunderten externer Bibliotheken, die anderen Code verwenden, der wiederum anderen Code verwendet.
Diese Abhängigkeitskette nennt man Supply Chain. Wer sie angreift, trifft nicht nur ein Opfer. Er trifft alle, die das kompromittierte Paket verwenden.
Es gibt drei typische Angriffsmuster.
Kompromittierung eines bestehenden Pakets: Ein Angreifer übernimmt ein legitimes Open-Source-Projekt und fügt Schadcode ein. Das ist möglich, wenn ein Maintainer sein Passwort verliert, seinen Account übergibt oder das Projekt aufgibt.
Typosquatting: Ein Paket mit ähnlichem Namen wie ein bekanntes Paket wird veröffentlicht. Wer sich bei der Eingabe vertippt, installiert das falsche Paket. "colourama" statt "colorama" ist ein reales Beispiel.
Dependency Confusion: Interne Paketnamen werden im öffentlichen Repository mit höheren Versionsnummern veröffentlicht. Paketmanager bevorzugen dann fälschlicherweise die öffentliche, schadhafte Version.
Warum Legacy-Systeme besonders gefährdet sind
Bei einem gut gewarteten System werden Dependencies regelmäßig aktualisiert. Sicherheitswarnungen werden geprüft. Bekannte Schwachstellen werden gepatcht.
Bei Legacy-Systemen sieht es oft anders aus. Die package.json oder composer.json wurde seit Jahren nicht angefasst. Niemand weiß mehr genau, was alles drin ist. Die Abhängigkeiten haben Abhängigkeiten, die weitere Abhängigkeiten haben.
Jedes dieser Pakete ist ein potenzieller Eintrittspunkt.
Das ist kein theoretisches Risiko. CVE-Datenbanken (Common Vulnerabilities and Exposures, also öffentlich dokumentierte Sicherheitslücken) listen täglich neue Schwachstellen in verbreiteten npm-Paketen und Composer-Bibliotheken auf. Für aktuelle, gepflegte Projekte werden diese schnell gepatcht. Für veraltete Systeme bleiben sie offen.
Besondere Gefährdung durch ungepatchte npm-Pakete
JavaScript-Projekte mit vielen npm-Abhängigkeiten sind ein häufiges Ziel. Das npm-Ökosystem ist riesig. Es umfasst Millionen von Paketen, viele davon von einzelnen Entwicklern gepflegt, manche gar nicht mehr.
Ein reales Beispiel: Das Paket "event-stream" wurde kompromittiert, nachdem ein Angreifer als Maintainer aufgenommen wurde. Das Paket hatte damals über zwei Millionen Downloads pro Woche. Betroffen waren alle Projekte, die es direkt oder indirekt verwendeten.
Wenn Ihre Anwendung npm-Pakete aus 2018 oder 2019 verwendet, ist die Wahrscheinlichkeit hoch, dass bekannte Sicherheitslücken vorhanden sind und nicht gepatcht wurden.
Composer und PHP: Das gleiche Problem auf anderer Ebene
PHP-Projekte mit Composer haben dieselben Risiken. Eine veraltete composer.lock bedeutet fixierte Versionen, kein automatisches Update, keine automatische Sicherheitsbenachrichtigung.
Viele Legacy-PHP-Projekte wurden ohne Composer gebaut. Bibliotheken wurden manuell heruntergeladen und ins Projekt eingecheckt. Das ist noch problematischer: Es gibt keine zentrale Übersicht, welche Bibliotheken in welcher Version vorhanden sind. Eine automatische Prüfung auf Sicherheitslücken ist damit kaum möglich.
Wie ein Software supply chain Angriff abläuft
Ein Angriff folgt in der Regel einem ähnlichen Muster.
Erkennung: Automatisierte Scans finden Systeme mit bekannten verwundbaren Abhängigkeiten. Angreifer wissen oft besser als die Betreiber, welche Pakete in welcher Version kritisch sind.
Ausnutzung: Über die Sicherheitslücke im kompromittierten Paket wird Schadcode eingeschleust. Das kann Datendiebstahl sein, das Nachladen weiterer Schadsoftware oder die stille Kontrolle des Systems.
Persistenz: Gut eingebetteter Schadcode hinterlässt Hintertüren. Er sorgt dafür, dass er auch nach einem Neustart oder einem Patch aktiv bleibt. Das macht die Bereinigung aufwändig.
Was die Erkennung schwer macht: Kompromittierter Code in einer Abhängigkeit sieht für das Betriebssystem wie normaler Code aus. Er läuft mit denselben Rechten wie die Anwendung. Herkömmliche Virenscanner erkennen ihn oft nicht.
Was Sie jetzt prüfen sollten
Die gute Nachricht: Es gibt praktische Schritte, die den Überblick zurückbringen.
Bestandsaufnahme Ihrer Abhängigkeiten
Der erste Schritt ist zu wissen, was überhaupt vorhanden ist. Für JavaScript-Projekte gibt es npm audit. Es prüft alle installierten Pakete gegen bekannte Schwachstellen und gibt eine Übersicht über kritische Funde.
Für PHP-Projekte gibt es den Symfony Security Checker oder das Tool composer audit. Beide prüfen die composer.lock gegen die PHP-Security-Advisories-Datenbank.
Der Befehl ist einfach. Das Ergebnis kann überraschend sein.
Einfrieren vs. Aktualisieren
Nicht jede veraltete Abhängigkeit ist sofort ein Problem. Aber nicht zu wissen, welche kritisch sind, ist eines.
Nach der Bestandsaufnahme gibt es zwei Gruppen: Abhängigkeiten mit bekannten Sicherheitslücken und solche ohne. Erstere brauchen Priorität. Nicht alle Updates müssen sofort passieren, aber bekannte kritische Lücken sollten gepatcht werden, bevor sie ausgenutzt werden.
Automatisches Monitoring einrichten
Einmalig prüfen reicht nicht. Sicherheitslücken werden täglich neu entdeckt. Ein System, das heute sauber ist, kann morgen eine bekannte Lücke haben, wenn ein neues CVE für ein verwendetes Paket veröffentlicht wird.
GitHub Dependabot, Snyk oder ähnliche Dienste können Dependencies automatisch überwachen und bei neu entdeckten Lücken benachrichtigen. Das ist kein großer Aufwand, bringt aber einen entscheidenden Vorteil: proaktives statt reaktives Handeln.
Was wir bei Legacy-Projekten konkret tun
Bei uns beginnt jede Übernahme eines Legacy-Systems mit einer Abhängigkeitsanalyse. Wir erfassen, welche Bibliotheken in welchen Versionen vorhanden sind. Wir prüfen, ob bekannte CVEs vorliegen. Wir klassifizieren nach Kritikalität.
Das ist oft ernüchternd. Aber es ist die Grundlage für alles Weitere. Wer nicht weiß, was er hat, kann es nicht schützen.
Anschließend priorisieren wir: Was muss sofort gepatcht werden? Was kann warten? Was erfordert eine größere Modernisierung? Diesen Prozess begleiten wir strukturiert, damit nichts übersehen wird und der laufende Betrieb nicht gestört wird.
Häufige Missverständnisse
"Wir nutzen kein Open Source, also haben wir das Problem nicht." Das stimmt kaum noch. Selbst proprietäre Software verwendet intern Open-Source-Komponenten. Webanwendungen, die einen Browser nutzen, verwenden JavaScript-Bibliotheken fast immer.
"Unser System ist zu alt, um interessant für Angreifer zu sein." Das ist falsch. Alte Systeme sind interessant, weil sie bekannte, ungepatchte Lücken haben. Das macht sie zu leichten Zielen.
"Wir haben eine Firewall." Eine Firewall schützt vor Netzwerkzugriffen von außen. Schadcode, der über eine kompromittierte Abhängigkeit eingeschleust wird, läuft bereits innerhalb der Firewall. Er ist dann ein legitimer Prozess aus Sicht des Systems.
Was ein Supply-Chain-Angriff in der Praxis kostet
Der direkte Schaden ist schwer zu quantifizieren. Typische Folgen sind Datenverlust oder Datendiebstahl, Systemausfall und Wiederherstellungsaufwand, DSGVO-Meldepflichten bei Datenpannen sowie Vertrauensverlust bei Kunden und Partnern.
Die Bereinigung nach einem Angriff dauert oft länger als gedacht. Kompromittierter Code hat oft Hintertüren hinterlassen, die man erst findet, wenn man gezielt sucht. Das ist aufwändig und teuer.
Prävention ist in fast allen Fällen günstiger.
Zum Vergleich: Ein strukturierter Dependency-Check und die Einrichtung eines Monitoring-Prozesses kosten einen Bruchteil der Reaktionskosten nach einem erfolgreichen Angriff. Die Versicherungsgesellschaften, die Cyberversicherungen anbieten, berechnen das sehr genau.
Fazit
Software supply chain Angriffe sind keine Spezialität von Geheimdiensten. Sie sind ein verbreitetes, gut dokumentiertes Angriffsmuster, das Systeme mit veralteten oder ungepatchten Abhängigkeiten trifft.
Legacy-Systeme sind durch ihre Natur besonders gefährdet: viele Abhängigkeiten, selten überprüft, kein automatisches Monitoring. Das ist kein Vorwurf, das ist eine Beschreibung der Realität in vielen mittelständischen Unternehmen.
Die Konsequenz ist klar: Wer ein altes System betreibt, sollte wissen, was drin ist. Und wer nicht weiß, wie er das herausfindet, kann Unterstützung holen.
Sprechen Sie uns an. Das Erstgespräch ist kostenlos. Wir schauen uns Ihr System an und sagen Ihnen, wo bekannte Lücken vorhanden sind und welche davon dringend geschlossen werden müssen.
