Was ist eigentlich eine Supply-Chain-Attacke?
Öffnet keine Anhänge in E-Mails von Absendern, die ihr nicht kennt; tragt keine Zugangsdaten in Formulare auf Websites ein, die irgendwie sketchy wirken; verwendet einen Passwortmanager; aktiviert überall Zwei-Faktor-Authentifizierung; dies das Ananas. Wer diese Punkte befolgt, hat bereits eine ganz solide Basis, um sich zumindest hinreichend sicher im Netz zu bewegen. Aber was, wenn die Soft- oder Hardware eines Netzwerkes von Grund auf kompromittiert wurde?
Diese besonders perfide Art des Hackings wird auch Supply-Chain-Attacke genannt. Dabei wird bösartiger Code in eine eigentlich vertrauenswürdige Software, oder eine bösartige Komponente in eigentlich vertrauenswürdige Hardware eingeschleust. Gelingt es Hackern, dessen Verteilsysteme zu übernehmen, können sie von dort aus jede App, jedes Software-Update und sogar physisches Equipment, das an Kunden ausgeliefert wird, in ein Trojanisches Pferd verwandeln. Eine einzelne, gut platzierte Intrusion kann so zum Ausgangspunkt für ein Virus werden, das sich so auf Hunderte Netzwerke ausbreiten kann.
Wer Software nutzt, muss Vertrauen haben
Supply-Chain-Attacken sind auch deshalb so gefährlich, weil sie so schwierig zu beherrschen sind – und weil sie auf brutale Art offenlegen, wie sehr sich Informationstechnologie auf Vertrauen stützt. Als Software-Nutzer vertrauen wir deren Hersteller; und Software-Herstellern, die der Hersteller der von uns verwendeten Software nutzt – also quasi einem ganzen Ökosystem.
Eindrucksvoll demonstriert hat das eine Supply-Chain-Attacke auf ein Software-Unternehmen namens Solarwinds. Russische Spione hatten bösartigen Code in deren Produkt eingeschleust. Die kompromittierte IT-Managementsoftware ermöglichte den Zugriff auf weltweit über 18.000 Netzwerke auf der ganzen Welt, in denen die Software verwendet wurde. Der russische Geheimdienst nutzte die Gelegenheit, um sich tief in die Netzwerke von mindestens sechzehn Bundesämter und Ministerien und mindestens neun US-amerikanischen Bundesbehörden einzuhacken, darunter die Nasa, das Außenministerium, das Verteidigungsministerium und das Justizministerium.
„Traue keinem Code, den du nicht selbst geschrieben hast“
Solarwinds war kein Einzelfall. Erst kürzlich wurde bekannt, dass ein Entwickler-Tool namens CodeCov kompromittiert worden war. Mindestens sechs Supply-Chain-Attacken der letzten fünf Jahren werden einer Hackergruppe namens Barium zugeschrieben. Unter den Zielen: Der Computerhersteller Asus und das Festplattenreinigungstool CCleaner.
2017 kam es zur teuersten Supply-Chain-Attacke der Geschichte. Eine Gruppe russischer Hacker, die unter dem Namen Sandworm bekannt wurde und dem militärischen Geheimdienst GRU zugeordnet wird, schleuste über eine ukrainische Buchhaltungs-Software sich selbst ausbreitenden Schadcode in die Systeme tausender Nutzer ein. Notpetya, der Schadcode, verursachte weltweit Schäden von zehn Milliarden US-Dollar.
Tatsächlich wurden Supply-Chain-Angriffe zum ersten Mal vor etwa vier Jahrzehnten demonstriert. Ken Thompson, einer der Unix-Schöpfer, testete, ob sich eine Hintertür in der Anmeldefunktion des Betriebssystems verstecken ließe. Dabei beschränkte er sich aber nicht auf bösartigen Code, der eben eine solche Tür offenlässt. Er entwickelte einen Compiler, der die Hintertür erst während der Kompilierung des Anmeldeprozess einbaute. In einem weiteren Schritt beschädigte er den Compiler, der seinen Hintertür-Compiler kompilierte, sodass sich auf Anwenderseite keine Spuren von Manipulation entdecken ließen. „Die Moral der Geschichte? Traue keinem Code, den du nicht selbst geschrieben hast“ schrieb er 1984 in einem Vortrag über sein Vorhaben.
Der von Thompson demonstrierte Trick – eine Art doppelte Supply-Chain-Attacke – kam bereits mehrfach zur Anwendung. 2015 verbreiteten Hacker eine Fake-Version des Apple-Entwicklerwerkzeugs Xcode und schleusten so Schadcode in mehrere chinesische iPhone-Apps. Die Methode kam 2019 erneut zum Einsatz, als die Barium-Gruppierung eine Version von Microsofts Visual Studio Compiler korrumpierte und Malware in einer Reihe von Videospielen versteckte.
Angriffe auf die Lieferkette nehmen aus einer Reihe von Gründen zu: Die Verteidigungsmechanismen gegen rudimentäre Angriffsversuche werden besser. Sie zwingen Angreifer dazu, auf weniger gut geschützte Software auszuweichen. Wenn die eigentlichen Ziele eines Angriffs unerreichbar sind, können Supply-Chain-Attacken ein Umweg sein, um trotzdem Zugriff auf deren Netzwerk – und gleichzeitig potenziell Hunderte weitere – zu erlangen.
Korrumpierte Hardware ist besonders schwierig zu ermitteln
Supply-Chain-Attacken zu verhindern, wird auch in Zukunft nicht einfacher werden – es gibt keinen einfachen Weg, um zu verifizieren, dass gekaufte Software oder Hardware nicht korrumpiert ist. Vor allem Hardware-Supply-Chain-Attacken, bei denen Schadcode oder schädliche Komponenten in Hardware eingebracht wird, können schwierig zu ermitteln sein. 2018 wurde in einer Bloomberg-Reportage behauptet, dass in den Supermicro-Motherboards in Apples und Amazons Datenzentren winzige Spyware verbaut sei. Die NSA und die involvierten Firmen leugneten das vehement. Laut klassifizierter Snowden-Leaks hat die NSA allerdings sehr wohl Lieferungen von Cisco-Routern abgefangen und mit einer Hintertür versehen – zu Spionagezwecken.
Die Lösung für das Problem ist womöglich weniger technisch als vielmehr organisatorischer Art. Unternehmen und Regierungsbehörden müssen ein Auge auf die Lieferkette von Soft- und Hardware haben, ihre Lieferanten kennen und sicherstellen, dass deren Produkte gewissen Standards genügen. Per Executive Order hat die Biden-Administration Anfang Mai 2021 verfügt, dass Software, die in Regierungsbehörden zum Einsatz kommt, gewissen Sicherheitsstandards gerecht werden muss. In der EU haben sich das Europäische Parlament, der Europäische Rat und die Europäische Kommission bereits 2018 auf einen Rechtsakt zur Cybersicherheit geeinigt. Dieser sieht eine Cybersicherheitszertifizierung von Produkten, Verfahren und Diensten vor. Thompsons Leitspruch „Traue keiner Software, die du nicht selbst geschrieben hast“ war 1984 bereits nicht mehr praktikabel – Software zu trauen, die gewissen Standards genügt, ist dann wohl zumindest die nächstbeste Lösung.
via www.wired.com