Software Supply Chain Security Wenn Open-Source-Pakete zur Hintertür werden

Anbieter zum Thema

Checkmarx GmbH

cidaas by Widas ID GmbH

FAST LTA GmbH

FTAPI Software GmbH

Die Kampagne „Operation Navy Ghost“ verbreitet Schadcode über Python-Pakete, der sich Prüf- und Überwachungsmechanismen entzieht. Sie zeigt, warum Unternehmen Software-Lieferketten so konsequent absichern müssen wie Netzwerke und Endpunkte.

Supply-Chain-Angriffe müssen nicht mit einer Zero-Day-Schwachstelle beginnen. Mitunter genügt die Annahme, dass ein Paket aus einem etablierten Repository vertrauenswürdig ist. Genau dieses Vertrauen machten sich die Angreifer hinter der vom Checkmarx-Zero-Research-Team um Application Security Analyst Pavan Gudimalla analysierten Kampagne „Operation Navy Ghost“ zunutze.

Über einen Zeitraum von mehreren Monaten veröffentlichten sie mindestens acht manipulierte Python-Pakete auf dem Python Package Index (PyPI), die sich gezielt an Entwickler von Telegram-Bots richteten. Äußerlich wirkten die Bibliotheken legitim. Sie basierten auf dem Quellcode der bekannten Bibliothek „pyrogram“, übernahmen deren Funktionalität weitgehend unverändert und erfüllten zunächst genau den Zweck, den Entwickler von ihnen erwarteten. Gleichzeitig enthielten sie jedoch eine versteckte Backdoor, die den Angreifern eine umfassende Fernsteuerung infizierter Systeme ermöglichte. Insgesamt wurden die Schadpakete rund 25.500-mal heruntergeladen, bevor die meisten von ihnen von PyPI entfernt wurden.

Open Source im Visier von Supply-Chain-Angriffen

Software-Lieferketten sind der blinde Fleck der IT-Sicherheit

Bemerkenswert ist dabei weniger die technische Raffinesse einzelner Schadcode-Komponenten als vielmehr die strategische Vorgehensweise. Anstatt wahllos möglichst viele Systeme ins Visier zu nehmen, konzentrierten sich die Angreifer auf eine klar definierte Zielgruppe: Entwickler, die Telegram-Bots betreiben oder Anwendungen auf Basis der Plattform erstellen. Wer eines der präparierten Pakete in seinem Bot einsetzte, aktivierte zugleich die versteckte Backdoor. Der Schadcode gelangte so in die jeweilige lokale, Cloud- oder Serverumgebung, ohne dass dafür zunächst eine Schwachstelle in der Infrastruktur ausgenutzt werden musste.

Damit verdeutlicht Navy Ghost ein grundlegendes Risiko moderner Software-Lieferketten: Angreifer müssen ein Unternehmensnetzwerk nicht immer unmittelbar kompromittieren. Sie können stattdessen eine vermeintlich legitime Abhängigkeit manipulieren und darauf setzen, dass Entwickler sie selbst in ihre Projekte integrieren.

Security-Insider Podcast – Folge 120

Die Zeit der Lieferketten-Angriffe beginnt

Warum die Kampagne so erfolgreich war

Der Erfolg der Operation beruhte nicht auf einer einzelnen neuen Angriffstechnik. Vielmehr kombinierten die Angreifer mehrere bekannte Methoden zu einer besonders glaubwürdigen Angriffskette. Im Zentrum stand die bewusste Orientierung an der etablierten Python-Bibliothek pyrogram, die von zahlreichen Entwicklern für Telegram-Bots genutzt wird. Die Angreifer übernahmen große Teile ihres Quellcodes und ergänzten ihn gezielt um versteckte Schadfunktionen. Für Entwickler ergab sich dadurch zunächst kaum ein Anlass zur Skepsis. Denn die Bibliotheken ließen sich wie erwartet installieren und erfüllten ihren eigentlichen Zweck. Genau diese Tarnung machte den Angriff so wirkungsvoll.

Hinzu kam die gezielte Auswahl der Opfer. Die präparierten Pakete richteten sich nicht an eine breite Masse von Anwendern, sondern an eine vergleichsweise kleine, klar definierte Entwickler-Community. Ebenso bemerkenswert ist die Art und Weise, wie die Backdoor nach erfolgreicher Installation mit den Angreifern kommunizierte. Anstelle einer klassischen Command-and-Control-Infrastruktur lief die Kommunikation über Telegram. Da der Datenaustausch über einen legitimen Cloud-Dienst erfolgte, hob er sich deutlich weniger von regulärem Netzwerkverkehr ab und konnte dadurch sowohl die Erkennung als auch die Analyse erschweren.

Nach den Erkenntnissen von Checkmarx Zero ermöglichte die Backdoor den Angreifern eine weitreichende Kontrolle über kompromittierte Systeme. Sie konnte Befehle empfangen und Informationen vom betroffenen System sammeln, wodurch aus einer zunächst unscheinbaren Paketinstallation eine umfassende Kompromittierung des betroffenen Hosts entstehen konnte. Entscheidend ist jedoch weniger der konkrete Funktionsumfang der Backdoor als die Erkenntnis, dass der eigentliche Angriff bereits lange vor ihrer Aktivierung erfolgreich war, und zwar in dem Moment, in dem Entwickler das manipulierte Paket als vermeintlich vertrauenswürdige Abhängigkeit in ihr Projekt einbanden.

Studie von Kaspersky

Jedes dritte Unternehmen von Supply-Chain-Angriff betroffen

Mehr als ein Einzelfall

Operation Navy Ghost ist kein isolierter Vorfall. Die Kampagne steht exemplarisch für einen Wandel, der sich seit einigen Jahren in der Bedrohungslandschaft beobachten lässt. Anstatt ausschließlich Schwachstellen in Anwendungen oder Netzwerken ins Visier zu nehmen, verlagern Angreifer ihren Fokus zunehmend auf die Software-Lieferkette. Öffentliche Paket-Repositories, Build-Prozesse und externe Abhängigkeiten werden dabei zu attraktiven Angriffszielen, weil sich manipulierte Pakete auf diesem Weg in zahlreiche Softwareprojekte einschleusen lassen. Damit rückt für Unternehmen eine zentrale Frage in den Fokus: Welche externen Komponenten werden überhaupt eingesetzt und woher stammen sie?

Update: Neue Variante des Shai-Hulud Worm

Supply-Chain-Angriff trifft über 1.000 npm-Pakete

Sicherheit beginnt in der Software-Lieferkette

Der Vorfall macht deutlich, dass sich Software-Lieferketten heute nicht mehr ausschließlich unter dem Aspekt der Effizienz betrachten lassen. Jede externe Bibliothek erweitert zugleich die potenzielle Angriffsfläche einer Anwendung. Je größer die Zahl eingesetzter Abhängigkeiten ist, desto schwieriger wird es, deren Herkunft, Integrität und Sicherheitsstatus dauerhaft im Blick zu behalten.

Für Unternehmen bedeutet das zunächst, Transparenz über die eigene Software-Lieferkette zu schaffen. Viele wissen zwar, welche Anwendungen sie einsetzen, verfügen jedoch nur über eine unvollständige Übersicht darüber, aus welchen Open-Source-Komponenten diese tatsächlich bestehen. Ohne dieses Wissen lassen sich Risiken weder zuverlässig bewerten noch schnell eingrenzen, wenn kompromittierte Pakete bekannt werden.

Ebenso wichtig ist ein kontrollierter Umgang mit neuen Abhängigkeiten. Entwickler sollten Bibliotheken nicht allein aufgrund ihrer Funktionalität oder eines vertraut wirkenden Namens übernehmen. Gerade bei Forks oder Paketen mit ähnlichen Bezeichnungen empfiehlt es sich, proaktiv deren Herkunft nachzuvollziehen, die Entwicklungshistorie zu prüfen und sie mit dem ursprünglichen Projekt zu vergleichen.

Darüber hinaus reicht eine einmalige Prüfung nicht aus. Auch zunächst unauffällige Abhängigkeiten können sich im Laufe der Zeit verändern oder nachträglich zum Risiko werden. Unternehmen benötigen deshalb Prozesse, die Veränderungen fortlaufend überwachen und ungewöhnliche Entwicklungen sichtbar machen. So lassen sich Manipulationen frühzeitig erkennen, bevor sie sich in Entwicklungs- oder Produktionsumgebungen ausbreiten.

Nicht zuletzt kommt es auf eine enge Zusammenarbeit zwischen Entwicklungs- und Sicherheitsteams an. Die Verantwortung für die Sicherheit der Software-Lieferkette darf weder ausschließlich bei den Entwicklern noch allein bei der IT-Sicherheit liegen. Erst wenn beide Bereiche gemeinsame Prozesse für die Auswahl, Prüfung und kontinuierliche Überwachung von Softwarekomponenten etablieren, lässt sich das Risiko wirksam reduzieren.

Klassische Sicherheitsmaßnahmen bleiben wichtige Bausteine einer Sicherheitsstrategie. Sie greifen jedoch häufig erst dann, wenn sich Schadcode bereits innerhalb der eigenen Umgebung befindet. Angriffe auf die Software-Lieferkette setzen deutlich früher an, nämlich dort, wo externe Softwarekomponenten ausgewählt und in Projekte eingebunden werden. Entsprechend muss auch die Verteidigung früher beginnen.

Über den Autor: Darren Meyer ist Director of Security Research bei Checkmarx Zero. Er verfügt über mehr als 20 Jahre Erfahrung im Bereich Application Security und kennt die Perspektive von Sicherheitsexperten, Forschern und Softwareentwicklern gleichermaßen. Aktuell beschäftigt sich Meyer vor allem mit neuen Bedrohungen in den Bereichen KI, DevSecOps und Software Security.

Nur wer seine Supply Chain kennt, kann sie auch schützen

CVE-Flut täuscht über reale Gefahren in der Software-Lieferkette hinweg

(ID:50951498)