Akteure, Taktiken und Abwehr von Supply Chain Attacks – Teil 1 Angriffe auf die Softwarelieferkette

Über die Supply Chain lassen sich selbst IT-Systeme angreifen, die bislang als bestens geschützt und schwer zu knacken galten. Im ersten Teil unserer Miniserie erläutert Asaf Karas, wie Angreifer Schwachstellen in Software-Bibliotheken und Repositorys injizieren. Zudem verrät der CTO und Mitgründer von Vdoo, welche Akteure hinter den Attacken stecken und warum das Thema künftig noch an Brisanz gewinnen wird.

Unsere Welt funktioniert über Software. Code steuert so ziemlich alles, was wir benutzen: Apps, vernetzte Geräte bis hin zu industriellen Systemen in kritischen Infrastrukturen. Sämtliche Produkte basieren auf riesigen Mengen von Code. Der größte Teil stammt allerdings nicht von den Unternehmen selbst und entzieht sich der direkten Kontrolle. Zudem haben sich die Entwicklungszyklen inzwischen extrem verkürzt. Um mit diesem Tempo Schritt zu halten, nutzen viele Firmen Open Source Software und kommerzielle Komponenten. Schätzungen zufolge enthalten 99 Prozent aller Softwareprodukte Open Source Software und 85 bis 97 Prozent der gesamten Codebasis beruht auf Open Source-Komponenten. Gut für die Produktivität, aber nicht ohne Probleme. Software-Entwickler, Hersteller und die Nutzer der Systeme sind für sichere Lieferketten verantwortlich. Nachweislich keine ganz geringe Herausforderung.

Risiken abgrenzen

Software wird heute nicht mehr zusammengesetzt, sie wird aggregiert. Die moderne Softwareentwicklung basiert zu einem großen Teil auf Komponenten, die aus Quellen Dritter stammen und die Grundlage der Codebasis bilden. Sie stammen aus Open-Source-Softwareprojekten (wie Apache oder Linux) oder kommerziellen Produkten (beispielsweise Windows und Oracle). Unternehmen, die solche Komponenten verwenden, sind für die Herkunft und Sicherheit des Codes verantwortlich.

Ende 2020 hat sich eindringlich gezeigt, welchen Risiken die Softwarelieferkette ausgesetzt ist. Staatliche Angreifer kompromittierten den Update-Server der Orion-Plattform, die skalierbare Überwachungs- und Verwaltungsplattform von SolarWinds, und verteilten so Schadcode über einen ansonsten vertrauenswürdigen Pfad an die Kunden des Unternehmens. Aufgrund dieser Vorgehensweise blieb der Angriff lange unentdeckt. Zu den Opfern gehörten Microsoft, die US-Regierung und viele andere hochrangige Ziele, die ansonsten gut vor externen Bedrohungen geschützt sind.

Cybersicherheitsrisiken in der Lieferkette sind die Folge von Schwachstellen oder Sicherheitslücken, die absichtlich (bei einem Supply-Chain-Angriff) oder auch unbeabsichtigt über den Erwerb von Software und Hardware in ein Unternehmen gelangen. Der Angriff erfolgt mittels einer Schadkomponente, die über eine legitim erscheinende Software oder über ein Gerät eingeschleust wird. Der Code wird dann beispielsweise von einem nichts ahnenden Administrator im Netzwerk des Unternehmens installiert. So gelingt es, Abwehrmechanismen am Perimeter und auch die meisten netzwerkbasierten Überwachungssysteme zu umgehen. Die Angriffe sind folglich schwer zu erkennen und deshalb für Hacker eine verlockende Alternative zu herkömmlichen Perimeter-Angriffen.

Supply-Chain-Risiken und warum sie so schwer in den Griff zu bekommen sind

Die Herausforderungen bei Supply-Chain-Angriffen liegen in den schwerwiegenden Auswirkungen und der Tatsache, dass sie meist lange Zeit unentdeckt bleiben. Das Ausmaß betrifft in aller Regel nicht nur ein Unternehmen, sondern eine Vielzahl von ihnen, wenn zum Beispiel eine populäre Open Source-Komponente kompromittiert wurde. Unternehmen haben oft keine Möglichkeit, Fremdcode zu überprüfen und nicht die nötige Transparenz, um sich vor Schadcode zu schützen, der sich in einem Paket verbirgt. Ein wesentliches Problem besteht darin, dass ein großer Teil des von Unternehmen installierten Codes „Closed Source“ ist. Das heißt, der Quellcode der Anwendungen kann nicht von jedermann eingesehen werden und liegt nur in Form von Binärdateien vor. Dieser Code ist wie eine Black Box, und schwerlich zu überprüfen. Reverse Engineering wiederum ist aufwändig, teuer und kommt in den meisten Fällen nicht in Frage.

Zwar haben sich viele Prozesse innerhalb der Softwareentwicklung inzwischen verbessert, aber bis zu einer umfassenden Software Bill of Materials (SBOM), die alle Komponenten erfasst, ist es vielerorts noch ein weiter Weg. Ein anderes Problem bei Open Source-Komponenten besteht in den Abhängigkeiten, die unter der Oberfläche des Codes stecken. Eine einzelne Bibliothek baut unter Umständen auf Dutzenden von Abhängigkeiten auf, direkten und transitiven. Wenn der verwendete Code eine Funktion in einer dieser zugrunde liegenden Abhängigkeiten aufruft, und die zufällig eine Schwachstelle aufweist, gefährdet sie möglicherweise auch das Produkt.

Auch Paketmanager werden von vielen Unternehmen gern übersehen, aber von Angreifern aktiv ausgenutzt. Sie sind ein nicht zu unterschätzender Vektor für die ungewollte Installation von Schadcode. Paketmanager abstrahieren viele der Aktionen, die bei der Installation von Fremdsoftware im Hintergrund ablaufen. Dazu gehört die Entscheidung, ein lokales Paket aus dem internen Repository des Unternehmens oder ein gleichnamiges Paket aus einer öffentlichen (und potenziell bösartigen) Quelle zu verwenden. Dies kann zu einem automatischen und rekursiven Import von Abhängigkeiten führen. Und jede von ihnen kann kompromittiert sein.

Zu viele Schwachstellen, zu viele False Positives

Unternehmen spalten Open Source-Projekte üblicherweise auf, fügen je nach Anforderungsprofil eigenen Code ein und rückportieren Patches aller Schwachstellen, die sie identifizieren. Dabei wird aber gerne versäumt, die angegebene Paketversion zu ändern. So kann man nur schwer erkennen, ob das Paket tatsächlich anfällig ist. Besonders schwierig ist es, wenn sich die Schwachstellenerkennung nur auf diese Version des Softwarepakets bezieht.

Ein zweites Problem betrifft die Frage, mit welcher Art von Schwachstellen man es zu tun hat. Wir verwenden heute eine Fülle von Komponenten von Drittanbietern, die ihrerseits auf anderen Komponenten aufbauen. Es besteht also eine hohe Wahrscheinlichkeit, dass mehr als nur ein paar veritable Schwachstellen in einem AST-Scans (AST = Application Security Testing) auftauchen. Wenn Produkte Schwachstellen aufweisen, müssen die aber nicht zwangsläufig ein hohes Risiko bedeuten und auch tatsächlich ausgenutzt werden. In vielen Fällen schreibt ein Entwickler eine API, die nur bestimmte Funktionen innerhalb einer Fremdkomponente (höchstwahrscheinlich Open Source) aufruft. Die aufgerufenen Funktionen sind effektiv notwendig. Alle anderen bekommen keinen Zugriff auf das Produkt und bleiben im Wesentlichen als ineffektive Funktionen im Hintergrund. Sie stellen keine direkte Bedrohung dar, können vergleichsweise einfach entschärft oder bei der Behebung zurückgestellt werden.

Der „Shift Left“-Angriff

„Shift Left“-Angriffe passieren im Lebenszyklus der Softwareentwicklung (SDLC) bevor Sicherheitsmaßnahmen wie Hashing, Verschlüsselung und viele AST-Tools die Möglichkeit haben, sie zu erkennen. Da immer mehr Sicherheitsmaßnahmen in frühere Entwicklungsstadien verlegt werden, suchen gewiefte Angreifer nach Möglichkeiten, diesem Trend einen Schritt voraus zu sein.

Wer sind die Angreifer?

Die Angreifer rekrutieren sich aus dem kompletten Spektrum - vom böswilligen Entwickler bis hin zu Elite-Hacking-Teams mit staatlicher Unterstützung und allem, was dazwischen liegt.

Bei einem erfolgreichen Angriff gelingt es einem Einzelnen möglicherweise, den Projektverantwortlichen eines Open-Source-Projekts davon zu überzeugen, ihm Commit-Rechte zu erteilen. So lässt sich bösartiger Code einschleusen, der seinen Weg in das Produkt eines lukrativen Ziels irgendwo im Downstream findet. Möglicherweise fügt ein Innentäter, ein Entwickler, schädlichen Code in einen Update-Server ein und der wird dann weitergeleitet. In den meisten Fällen drehen sich diese kriminellen Handlungen um Krypto-Mining oder Malvertising.

Aber auch die organisierte Kriminalität interessiert sich nicht ohne Grund für anfällige Lieferketten. Solche Gruppen sind in aller Regel finanziell und technisch gut ausgestattet. So kommen hier eher Trojaner zum Einsatz, die eine Ransomware-Infektion in Gang setzen. Das Hacken eines Update-Servers ist eine ideale Taktik für Aktivitäten größeren Ausmaßes, etwa den Aufbau von Botnetzen für DDoS-Angriffe oder den Spam-Versand. Für staatliche Akteure können Angriffe auf die Lieferkette derweil attraktiv sein, um in gegnerische Regierungsnetzwerke einzudringen oder Industriespionage zu betreiben – insbesondere weil solche Ziele ansonsten gut geschützt sind.

Der SolarWinds-Vorfall ist ein Musterbeispiel für einen weitreichenden Supply-Chain-Angriff. Der Erfolg der Operation hat inzwischen schon andere inspiriert, und in den kommenden Monaten und Jahren ist fraglos mit ähnlich gearteten Angriffen zu rechnen. Taktiken und Methoden, die von gut ausgestatteten Geheimdiensten entwickelt wurden, sickern allmählich auch zu Angreifern mit weniger Expertise und Ressourcen durch. Ein Beispiel ist die Eternal Blue-Schwachstelle, die als Initialzündung für Generationen von Ransomware-Angriffen diente.

Informationssicherheit im Mittelstand

WannaCry – Anatomie eines (erfolgreichen) Angriffs

Über den Autor: Asaf Karas ist CTO und Mitgründer von Vdoo.

(ID:47473041)