[English]Eine Analyse des Lieferkettenangriffs auf die Orion-Produktlinie des US-Sicherheitsanbieters SolarWinds legt den Schluss nahe, dass die Angreifer Zugriff auf die Quellcode-Basis hatten. Über Monate haben sie das Einschleusen des Trojaners, der als Backdoor fungierte, vorbereitet und in den Quellcode eingeschleust.
Anzeige
Der erfolgreiche Hackerangriff gegen US-Behörden und Firmen wie den Sicherheitsanbieter FireEye per SUNBURST-Backdoor hat die USA ins Mark getroffen. Denn den Hackern ist es gelungen, einen Trojaner in ein signiertes Update für die SolarWinds Orion-Produkte einzuschleusen. Damit sind potentiell 18.000 Kunden von dieser Backdoor betroffen. Details dazu finden sich in den am Beitragsende verlinkten Artikeln.
Noch liegen keine Details der internen Untersuchungen bei SolarWinds vor. Der im Artikel Schlamperei bei SolarWinds für kompromittierte Software verantwortlich? thematisierte Fehler, dass Zugangsdaten zu den SolarWinds FTP-Server in einer Konfigurationsdatei auf GitHub öffentlich abrufbar waren ist aber wohl nicht ursächlich für den letztendlich erfolgreichen Supply-Chain-Angriff.
Vielmehr haben sich die Hacker wohl Zugang zum Quellcode-System von SolarWinds verschafft und konnten dort über Monate schalten und walten, ohne bemerkt zu werden. Tomislav Peričin, Chef-Software-Architekt & Mitbegründer bei ReversingLabs hat in diesem Blog-Beitrag eine tiefergehende Analyse des Vorfalls veröffentlicht und den Beitrag vorab mit The Hacker News geteilt.
Clevere Strategie zur Manipulation
Das Ganze basiert auf Untersuchungen von ReversingLabs zur Anatomie dieses Angriffs auf die Lieferkette. Diese Untersuchungen brachten schlüssige Details ans Tageslicht, die zeigen, dass die Infrastruktur für die Erstellung und Signierung von Orion-Software kompromittiert wurde und wie die Angreifer vorgegangen sind. Der Quellcode der betroffenen Bibliothek wurde direkt modifiziert, um bösartigen Backdoor-Code zu enthalten, der kompiliert, signiert und über das bestehende Software-Patch-Release-Management-System ausgeliefert wurde.
Anzeige
Neu ist wohl die Strategie der Angreifer, um die Manipulation des Quellcodes vor den SolarWinds-Entwicklern zu verschleiern und so lange wie möglich unentdeckt zu bleiben. Die Angreifer fügten ihre 'Quellcode-Ergänzungen' in die betroffene Code-Basis ein und ahmten gleichzeitig den Codierungsstil der Entwickler nach. Dazu verwenden sie auch die Benennungsstandards der Software-Entwickler.
Dies wurde laut Tomislav Peričin konsequent durch eine beträchtliche Anzahl von Funktionen demonstriert, die die Angreifer zur Quellcode-Basis hinzufügten, um die benötigte Hintertür in die Orion-Software einzuschmuggeln. Die Anatomie des Angriffs als Außenstehender nachzuzeichnen, ist zwar schwierig. Aber die Angreifer haben Spuren hinterlassen. Bekannt ist ja, dass die Orion-Bibliothek SolarWinds.Orion.Core.BusinessLayer.dll kompromittiert war und per Update ausgeliefert wurde.
Die Datei mit dem bösartigen Backdoor-Code wurde erstmals mit dem Softwarepaket-Update SolarWinds-Core-v2019.4.5220-Hotfix5.msp für die Orion-Plattform ausgeliefert. Diese Bibliothek wurde im Blog von FireEye gründlich analysiert. Aus der Analyse der Metadaten gelang es Tomislav Peričin jedoch weitere Rückschlüsse auf die Vorgehensweise und Raffinesse der Angreifer sowie auf den Zustand des Orion-Software-Build-Systems zu ziehen.
Während die erste Version, die den bösartigen Backdoor-Code enthielt, die Build 2019.4.5200.9083 war, gab es eine frühere Version 2019.4.5200.8890 aus dem Oktober 2019, die von den Angreifern bereits manipuliert wurde. Diese Version der DLL war nur leicht modifiziert und enthielt nur eine .NET-Klasse, die später den bösartigen Code für die Backdoor aufnehmen sollte.
Diese erste Code-Änderung war eindeutig nur ein Proof of Concept, schreibt Peričin. Der Aktionsplan der Angreifer bestand aus drei Schritten: Das Build-System kompromittieren, den eigenen Code einschleusen und überprüfen, ob dieser als signierte Pakete auf der Client-Seite ausgerollt wird. Sobald diese Ziele erreicht waren und die Angreifer sich selbst bewiesen hatten, dass die Lieferkette kompromittiert werden konnte, begannen sie mit der Planung der eigentlichen Angriffs-Nutzlast.
Der Name der Klasse, OrionImprovementBusinessLayer, scheint mit Bedacht gewählt. Die Klasse musste sich nicht nur in den Rest des Quellcodes einzufügen. Sondern der Klassenname war so gewählt, um die Software-Entwickler oder jeden, der die Binärdateien überprüft, zu täuschen. Diese Klasse und viele der Methoden, die sie verwendet, sind in anderen Orion-Softwarebibliotheken zu finden und passen sogar thematisch zum Code dieser Bibliotheken. Dies deutet nicht nur auf die Absicht hin, unauffällig zu bleiben, sondern auch darauf, dass die Angreifer mit der Codebasis bestens vertraut waren (was bei mir die Frage aufwirft, ob da ein Insider mit beteiligt war).
In der Analyse zeigt Peričin, wie die Angreifer die Funktionen der Klasse und der Codebasis schrittweise modifizierten, um die Backdoor zu implementieren, ohne dass dies den regulären Entwicklern oder den Leuten vom Code-Review auffiel. Obiges Bild zeigt einen solchen eingefügten Code-Block, der die betreffende Klasse nutzt. Der rot hervorgehobene Code ist die zusätzliche Funktionalität, die die Angreifer eingebaut haben. Dieser kleine Codeblock erstellt einen neuen Thread, der die Hintertür ausführt, während die Orion-Software ihre Bestandsprüfungen ebenfalls im Hintergrund durchführt.
Peričin zeigt, dass die Angreifer es nicht nur geschafft haben, von den Entwicklern der Orion-Software unentdeckt zu bleiben und ihren modifizierten Quellcode durch das SolarWinds Build-System zu schleusen. Sie waren auch sehr erfolgreich darin, unter dem Radar der System zu bleiben, die die Builds auf genau solche Malware überwachen. Interessierte Leser finden die Details in diesem Beitrag.
Unter dem Strich war das eine ausgeklügelte und mit großem Aufwand ausgeführte Operation. Da waren Könner am Werk. Und da letztendlich bestimmte Ziele angegriffen und lediglich Daten abgefischt und Mails mitgelesen wurden, ist es klar, dass das keine simplen Cyber-Kriminellen waren, die es auf schnelles Geld abgesehen hatten. Vielmehr dürften staatliche Hacker hinter diesem Angriff stehen – und es ist nicht ausgeschlossen, dass die Fingerzeige in Richtung Fancy Bear und Moskau genau die Urheber benennen.
Ergänzende Informationen habe ich inzwischen in den Beitrag SUNBURST-Malware: Analyse-Tool SolarFlare, ein ‚Kill-Switch' und der Einstein-Überwachungsflopp herausgezogen.
Ähnliche Artikel:
FireEye: Wenn Hacker eine Sicherheitsfirma plündern
US-Finanzministerium und weitere US-Behörde gehackt
SolarWinds SUNBURST-Schwachstelle: Die Folgen und Schutzmaßnahmen
SolarWinds-Produkte mit SunBurst-Backdoor, Ursache für FireEye- und US-Behörden-Hacks
Schlamperei bei SolarWinds für kompromittierte Software verantwortlich?
Neues im Kampf gegen die SUNBURST-Infektion, Domain beschlagnahmt
SUNBURST-Malware wurde in SolarWinds Quellcode-Basis eingeschleust
SolarWinds-Hack: Auch Microsoft & Co. betroffen?
Anzeige
Diesen Artikel haben Sie bestimmt schon gesehen:
https://krebsonsecurity.com/2020/12/malicious-domain-in-solarwinds-hack-turned-into-killswitch/
Das Konzept der DGA (Domain-Generator-Algorithm) wird zwar in youtube relativ gut erklärt, aber am konkreten die ver-linkten Github-Listen zu erklären, wäre gut.
Was haben eigentlich 4000 Domains bzw. virtuelle Server bei avsvmcloud.com? Da muss auch viel Geld dahinter stecken!