Thought Leadership
Immer häufiger werden Software-Lieferketten angegriffen. Dies stellt eine große Gefahr dar, weil dann auf einen Schlag viele Unternehmen weltweit betroffen sein können. Wie können Unternehmen sich gegen solche Angriffe schützen?
Eine Kette ist nur so stark wie ihr schwächstes Glied – das gilt auch für Software. Die umfassende Vernetzung und fortwährende Aktualisierung moderner Software führt zu größeren Software-Lieferketten und damit auch zu mehr potenziellen Sicherheitsrisiken. Ein aktuelles Beispiel ist etwa der Sunburst-Angriff, bei dem Hacker schädlichen Code in ein Software-Update eingeschleust haben. Dies zeigt, wie gefährlich ein Angriff auf Softwareanbieter ist und welche Auswirkungen dies auch für große und gut gesicherte Unternehmen hat. Ein weiteres aktuelles Beispiel ist der massive Cyberangriff auf fünfhundert Coop-Supermärkte in Schweden: Diese mussten aufgrund des Angriffs sogar für eine gewisse Zeit schließen, und auch weitere Unternehmen waren weltweit betroffen.
Und das sind bei weitem nicht die ersten Cyberangriffe dieser Art, schon vor einigen Jahren wurden ähnliche Fälle bekannt. 2017 wurde der bösartige NotPetya-Code in ein ukrainisches Softwarepaket für Buchhaltung eingeschleust. Dieser Angriff verursachte einen Schaden von über 10 Milliarden US-Dollar und hatte massive Beeinträchtigungen für multinationale Konzerne wie FedEX, Maersk und Merck zur Folge. Bereits 2013 gelang Hackern ein Angriff auf das US-Handelsunternehmen Target über dessen Heizungs- und Lüftungslieferanten. Dabei wurden die Zugangsdaten von 40 Millionen Debit- und Kreditkartenkonten gestohlen.
Verschiedene Angriffsmethoden – aber immer mit großem Risiko
Software-Lieferketten können auf viele verschiedene Arten angegriffen werden. Bei einer Art des Angriffs haben es Täter auf die Softwarekomponenten von Drittanbietern abgesehen, die nicht vom primären Softwareentwickler erstellt und gewartet werden und in der Regel in einem zentralen Register gespeichert sind. Die Hacker suchen dort dann Programmfehler und Schwachstellen und schleusen den bösartigen Code entweder direkt in die Quelle oder über eine Abhängigkeitsbeschränkung ein. Dadurch wird ein Zugang zu internen Systemen und Endbenutzern ermöglicht. Nicht nur zentrale Register bieten mögliche Angriffsflächen, sondern auch dezentrale Komponenten von Drittanbietern. Auf diese Weise konnten Hacker bereits Wallets für Kryptowährung angreifen.
Angriffe auf die Software-Lieferkette sind sowohl hochgradig effektiv als auch sehr gefährlich. Denn ähnlich wie bei einem Angriff auf eine öffentliche Cloud sind auch bei einer Attacke auf eine Lieferkette viele Unternehmen gleichzeitig betroffen.
Zwar sind solche Überfälle keine neuartige Erscheinung – aber das Risiko wird immer größer. Das liegt vor allem am hohen Tempo in der heutigen Softwareentwicklung. Dadurch können Entwickler nicht mehr den kompletten Code selbst entwickeln, sondern sie verwenden zunehmend proprietären und Open-Source-Code, um Anwendungen zu entwickeln. Moderne Code-Repositories sehen mittlerweile ganz anders aus als noch vor einigen Jahren. Sie enthalten neben proprietärem Code auch Open-Source-Pakete, Container, Infrastruktur als Code und sogar Build-Konfigurationen. Und jeder dieser Inhalte stellt ein potenzielles Angriffsziel dar.
Wie Entwickler die Sicherheit von Software-Lieferketten erhöhen können
Das Risiko eines Lieferketten-Angriffs steigt – aber Entwickler können Gegenmaßnahmen ergreifen. Im ersten Schritt sollten Angriffe abgewehrt werden, bei denen Abhängigkeiten missbraucht werden. Bei diesen Angriffen werden privat genutzte Pakete durch schädliche, öffentliche Pakete überschrieben, die denselben Namen haben. Als Teil der Software-Lieferkette werden Open-Source-Pakete automatisch von Entwicklern mit Hilfe von Paket-Managern und Build-Tools abgerufen. Wenn diese nicht nur Pakete aus privaten Registern, sondern auch aus öffentlichen Code-Registern abrufen, können Pakete mit demselben Namen verwechselt werden. Ein Hacker kann diese Sicherheitslücke also nutzen, indem er das öffentliche Repository einer Organisation nach privaten Paketnamen durchsucht und ein schädliches Paket mit identischem Namen hochlädt. Ein automatisierter Build-Prozess erledigt den Rest und zieht das bösartige Paket anstelle des beabsichtigten, intern erstellten Pakets ein.
Um das zu vermeiden, sollten Entwickler sogenannte „Scoped Namescapes“ verwenden. Diese Scoped-Pakete fixieren den Namen des Pakets und ordnen ihn einem bestimmten Benutzer oder Organisation zu. Dies verhindert das Auswechseln des Pakets. Eine weitere Maßnahme ist eine repo-spezifische Konfiguration, die das Upstream-Registry eindeutig definiert und Paket-Managern wie pip und npm explizite Anweisungen gibt. Dadurch wird eine Suche nach einer neueren Version des Pakets in der öffentlichen Bibliothek und somit auch eine versehentliche Einbindung eines bösartigen Pakets verhindert.
Entwickler sollten zudem Installationsbefehle durch Open-Source-Pakete deaktivieren. Standardmäßig erlauben einige Paket-Manager wie npm jedem Paket, das installiert oder deinstalliert wird, beliebige Befehle auszuführen. Das öffnet die Tür für sogenannte Typosquatting-Angriffe oder versteckte Backdoor-Mechanismen. Deshalb muss dringend sichergestellt werden, dass die Pakete vor der Installation streng geprüft werden und nicht blind oder willkürlich kopiert und eingefügt werden. Entwickler sollten dann das –ignore-scripts-Parameter in der Kommandozeile des Befehls npm install hinzufügen, um die Ausführung beliebiger Befehle durch Pakete zu unterbinden. Es ist auch eine Überlegung wert, ignore-scripts zu einer .npmrc-Konfigurationsdatei hinzuzufügen, um auch dort arbiträre Befehle in Team-Projekten zu blockieren.
Zwei-Faktoren-Authentifizierung einführen
Unerlässlich ist außerdem eine Zwei-Faktoren-Authentifizierung. 2FA ist ein einfacher, aber durchaus relevanter Schutz für Konten, die auf Verzeichnisse und Ökosysteme zugreifen. Dennoch wurde im Januar 2020 berichtet, dass weniger als 10 % der Entwickler auf npmjs diese aktiviert hatten – obwohl diese Funktion seit Ende 2017 verfügbar ist. Es ist essentiell, dass alle Entwickler diese Funktion aktivieren, da in der Open-Source-Community die Sicherheit nicht nur einzelne Personen betrifft, sondern auch Auswirkungen auf andere hat.
Kollektive Sicherheitsbedenken sind generell ein wichtiges Thema, wenn man mit Open-Source-Software arbeitet. Jede Aktion erhöht das Risiko, dass vertrauliche Informationen versehentlich weitergegeben und somit öffentlich zugänglich gemacht werden. Vermeiden lassen sich Datenpreisgabe, indem Entwickler keine vertraulichen Informationen in einem Repository, in der Konfiguration oder im Code speichern. Auch sollten sie keine Pakete oder Docker-Images mit vertraulichen Informationen veröffentlichen, die in öffentlichen Registern landen könnten.
Software-Lieferketten machen das heutige Entwicklungstempo erst möglich – jedoch zu einem hohen Preis. Softwarekomponenten von Drittanbietern sind beliebte Angriffsziele für Hacker. Deshalb sollten Entwickler umfassende Sicherheitsmechanismen einsetzen, um ihre Unternehmen zu schützen. Entwickler können zwar nicht verhindern, dass Angreifer ihre Systeme hacken. Durch das Erkennen und Beheben von Schwachstellen in der Lieferkette und umfassende Sicherheitsrichtlinien können Entwickler aber verhindern, dass die Angreifer Erfolg haben.
