Supply-Chain-Angriffe: Wenn kompromittierte Pakete Ihre Software gefährden

Ihre Software wurde nicht direkt angegriffen. Und trotzdem ist Schadcode drin.

Das ist die verstörende Wahrheit hinter Supply-Chain-Angriffen. Der Angreifer greift nicht Ihr System an. Er greift ein Paket an, das Ihre Software benutzt. Oder das Paket, das das Paket benutzt, das Ihre Software benutzt.

Supply-Chain-Angriffe auf Software sind in den letzten Jahren deutlich häufiger geworden. Und sie treffen nicht nur große Konzerne. Sie treffen jede Anwendung, die fremden Code einbindet.

Das sind heute fast alle.

Was ist ein Supply-Chain-Angriff?

Der Begriff kommt aus der Logistik. In der klassischen Lieferkette kann ein verseuchtes Zuliefererprodukt die gesamte Produktion kontaminieren, ohne dass der Hersteller selbst etwas falsch gemacht hat.

Bei Software funktioniert das genauso.

Moderne Anwendungen werden nicht komplett selbst gebaut. Entwickler nutzen Pakete, also fertige Code-Bibliotheken, die bestimmte Aufgaben übernehmen. Ein Paket für Dateiuploads. Eines für die Anmeldung. Eines für die Formatierung von Datumsangaben. In einem mittelgroßen PHP-Projekt kann es schnell 50 bis 200 solcher Abhängigkeiten geben. In einem Node.js-Projekt oft noch mehr.

Jedes dieser Pakete stammt von jemandem, dem Sie vertrauen müssen. Meistens einem unbekannten Entwickler irgendwo auf der Welt.

Ein Supply-Chain-Angriff auf Software nutzt genau dieses Vertrauen aus. Der Angreifer kompromittiert ein Paket, das weit verbreitet ist. Wer dieses Paket in seiner Anwendung nutzt, bekommt den Schadcode automatisch mitgeliefert.

Wie läuft ein solcher Angriff konkret ab?

Es gibt verschiedene Wege. Hier sind die häufigsten.

Übernahme eines bestehenden Pakets

Viele populäre Open-Source-Pakete werden von einzelnen Entwicklern gepflegt. Ehrenamtlich, in der Freizeit, oft ohne Vergütung. Wenn dieser Entwickler die Pflege aufgibt, kann das Paket von jemand anderem übernommen werden.

In einigen Fällen waren das Angreifer. Sie haben das beliebte Paket übernommen, eine neue Version mit Schadcode veröffentlicht, und alle, die automatisch auf die neueste Version upgraden, haben den Schadcode installiert.

Das klingt abstrakt. Es ist aber real. Der Angriff auf das npm-Paket „event-stream" im Jahr 2018 hat genau so funktioniert. Millionen von Projekten weltweit waren betroffen.

Typosquatting

Beliebte Pakete haben oft bekannte Namen. Ein Angreifer registriert einen Namen, der sehr ähnlich klingt: ein Buchstabe vertauscht, ein Bindestrich hinzugefügt, eine andere Schreibweise.

Entwickler tippen den falschen Namen. Oder kopieren ihn aus einem schlecht geprüften Codebeispiel. Das falsche Paket wird installiert. Es enthält Schadcode.

Das Perfide daran: Das Paket tut meistens auch das, was es soll. Sonst würde es auffallen. Im Hintergrund schickt es aber Daten nach außen oder öffnet eine Hintertür.

Kompromittierung des Build-Prozesses

Nicht nur die Pakete selbst sind Angriffsfläche. Auch der Prozess, mit dem Pakete gebaut und veröffentlicht werden, kann kompromittiert werden.

Der Angriff auf SolarWinds im Jahr 2020 ist das bekannteste Beispiel. Angreifer haben den Build-Prozess des Unternehmens infiltriert und Schadcode in offizielle Updates eingeschleust. Tausende Unternehmen, darunter US-Behörden, haben diese Updates installiert.

Warum trifft das auch alte und mittelständische Anwendungen?

Viele Entscheider denken: "Wir sind kein lohnendes Ziel. Wir sind zu klein."

Das stimmt für gezielte Angriffe. Bei Supply-Chain-Angriffen auf Software stimmt es nicht.

Wenn ein Angreifer ein viel genutztes Paket kompromittiert, interessiert ihn nicht ob Sie groß oder klein sind. Er trifft jeden, der das Paket nutzt. Automatisch. Ohne Auswahl.

Gerade Legacy-Systeme haben oft ein besonderes Problem. Sie nutzen Pakete, die seit Jahren nicht aktualisiert wurden. Manchmal seit einer Zeit, in der das Paket noch in Ordnung war. Inzwischen kann die Situation eine andere sein.

Wer seine veralteten Abhängigkeiten nicht regelmäßig prüft, hat keine Kontrolle darüber, was in der Anwendung wirklich steckt.

Das ist keine Dramatik. Das ist ein handwerkliches Problem. Und es lässt sich lösen.

Was unterscheidet npm und Composer?

Die beiden häufigsten Paketverwaltungssysteme in Webanwendungen sind npm (für JavaScript und Node.js) und Composer (für PHP). Beide haben ähnliche Schwachstellen.

npm ist besonders anfällig, weil das Ökosystem extrem groß ist. Millionen von Paketen, viele davon von Einzelpersonen gepflegt. Die Qualitätskontrolle ist minimal. Pakete können von jedem veröffentlicht werden, der ein Konto hat.

Composer (für PHP-Anwendungen) hat ein kleineres Ökosystem, ist aber strukturell ähnlich aufgestellt. Pakete werden auf Packagist veröffentlicht, einer zentralen Plattform, die keine inhaltliche Prüfung vornimmt.

Bei beiden gilt: Wer nicht weiß, welche Pakete er in welcher Version nutzt, hat keinen Überblick über seine Angriffsfläche. Das ist die Ausgangslage bei vielen Altsystemen.

Was können Sie konkret tun?

Vollständigen Schutz gibt es nicht. Aber es gibt klare Maßnahmen, die das Risiko erheblich senken.

Abhängigkeiten dokumentieren und inventarisieren

Der erste Schritt ist zu wissen, was Sie einsetzen. Bei PHP-Projekten steht das in der composer.json und composer.lock. Bei JavaScript in package.json und package-lock.json.

Wer keine solche Datei hat, hat keine Übersicht. Das kommt bei Altprojekten ohne Software-Wartung häufig vor. Dann ist der erste Schritt, diese Übersicht herzustellen.

Abhängigkeiten auf Sicherheitslücken prüfen

Composer bietet mit composer audit eine eingebaute Prüfung. npm hat npm audit. Beide gleichen die installierten Pakete mit öffentlichen Sicherheitsdatenbanken ab und zeigen bekannte Probleme an.

Das dauert Minuten. Es sollte regelmäßig passieren, mindestens einmal pro Monat.

Zusätzlich gibt es spezialisierte Werkzeuge wie Snyk, Dependabot oder OWASP Dependency-Check, die tiefer prüfen und auch transitive Abhängigkeiten erfassen. Das sind Pakete, die Ihre direkten Pakete einbinden, die aber nicht direkt in Ihrer Liste stehen.

Versionen fixieren

Eine lock-Datei sorgt dafür, dass immer genau die geprüfte Version eines Pakets installiert wird. Kein automatisches Update auf eine neue Version, die vielleicht Schadcode enthält.

Viele Altprojekte haben keine solche Datei. Wenn Pakete dann neu installiert werden, etwa nach einem Serverumzug, kann eine völlig andere Version landen als die ursprünglich getestete.

Updates kontrolliert durchführen

Automatische Updates klingen gut. Aber bei Paketen, deren Herkunft und Integrität unklar ist, können sie das Einfallstor für Supply-Chain-Angriffe auf Software sein.

Besser: Updates zeitgesteuert und nach Prüfung einspielen. Nicht sofort nach Veröffentlichung, sondern mit kurzem Abstand, damit die Community Probleme melden kann.

Für kritische Pakete: Prüfung der Herkunft

Wer ein Paket einbindet, sollte wissen, wer dahintersteckt. Ist das Paket aktiv gepflegt? Hat es eine erkennbare Community? Gibt es eine Organisation dahinter oder ist es eine Einzelperson?

Das schützt nicht vollständig, ist aber ein erster Filter gegen offensichtlich riskante Quellen.

Was ein Vorfall kostet

Die direkten Schäden durch einen erfolgreichen Supply-Chain-Angriff sind schwer zu begrenzen.

Schadcode, der über ein Paket eingeschleust wurde, kann Zugangsdaten abgreifen, Kundendaten exfiltrieren oder als Eintrittspunkt für weitere Angriffe dienen. Wann genau er aktiv war, lässt sich oft nicht mit Sicherheit rekonstruieren.

Das bedeutet: Im schlimmsten Fall müssen Sie alle gespeicherten Zugangsdaten als kompromittiert betrachten, alle Kunden informieren und den gesamten Vorfall unter DSGVO-Anforderungen dokumentieren und melden.

Das ist teuer. Nicht nur finanziell, sondern auch in Bezug auf Vertrauen.

Verglichen damit ist der Aufwand für regelmäßige Abhängigkeitsprüfungen gering.

Fazit

Supply-Chain-Angriffe auf Software sind kein Szenario aus der Zukunft. Sie passieren heute, regelmäßig, und sie treffen auch Unternehmen, die sich für zu klein oder uninteressant halten.

Die gute Nachricht: Die wichtigsten Schutzmaßnahmen sind kein Hexenwerk. Sie erfordern Disziplin, nicht unbedingt große Budgets. Wer weiß, welche Pakete er nutzt, wer sie regelmäßig prüft und wer Updates kontrolliert einspielt, hat einen deutlich besseren Stand als der Durchschnitt.

Wenn Sie nicht wissen, ob Ihre Anwendung in dieser Hinsicht abgesichert ist, ist das der Ausgangspunkt. Sprechen Sie uns an. Das Erstgespräch ist kostenlos. Wir schauen uns Ihre Abhängigkeiten an und sagen Ihnen, wo Handlungsbedarf besteht.