In dieser Folge dreht sich alles um Sunspot — die bislang wenig beachtete Malware, die das Build‑System von SolarWinds heimlich infiltrierte und damit den Weg für die berüchtigte Sunburst‑Schadsoftware ebnete. Die Folge: Vermutlich einer der heikelsten Datenabflüsse aus US-Regierungsinstitutionen überhaupt. Während Sunburst häufig als das eigentliche „Böse“ im Fokus steht, zeigen wir, wie Sunspot zunächst das Build-System der Orion‑Plattform manipulierte und dort unbemerkt Code einschleuste. Wir gehen darauf ein, warum die Verteilung von Sunspot so wichtig ist und beleuchten in guter Armchair-Investigators-Manier die Attribution. Begleitet uns auf einer Reise zu dem entscheidenden ersten Schritt des Angriffs, der einen der signifikantesten Supply-Chain-Angriffe erst möglich machte.
- Senate committee hears testimony on SolarWinds hack, PBS NewsHour
- Highly Evasive Attacker Leverages SolarWinds Supply Chain to Compromise Multiple Global Victims With SUNBURST Backdoor, FireEye (now part of Google Cloud), 13.12.2020
- SUNSPOT: An Implant in the Build Process, CrowdStrike, 11.01.2021
- 2020 United States federal government data breach, Wikipedia
- ARD Tagesschau 16.04.2021 20:00 Uhr, Reaktion auf neue Sanktionen, Russland weist US-Diplomaten aus
- Sunburst backdoor – code overlaps with Kazuar, Kaspersky Securelist, 11.01.2021
- MAR-10320115-1.v1 – TEARDROP, CISA Cybersecurity Advisory Analysis Report, 15.04.2021
- Deep dive into the Solorigate second-stage activation: From SUNBURST to TEARDROP and Raindrop, Microsoft, 20.01.2021
- SUNBURST Additional Technical Details, Mandiant (now part of Google Cloud), 24.12.2020
- An Investigative Update of the Cyberattack, SolarWinds, 07.05.2021
Der größte Datenabfluss in den USA?
0:04: Armchair Investigators. Ein Dialog über Malware, Cybercrime und Cyberspionage. Mit Lars Wallenborn und Christian Dietrich. Hallo liebe Cyberfreunde, mein Name ist Chris und ich bin Professor für Cybersicherheit an der Westfälischen Hochschule.
0:26: Und mein Name ist Lars, ich arbeite als Softwareentwickler und Analyst bei CrowdStrike.
0:32: Und heute zum Einstieg haben wir für euch einen kleinen Ausschnitt aus der Tagesschau, 20 Uhr, Primetime, aus dem Jahr 2021. Den spielen wir jetzt als erstes erstmal kurz ab.
0:42: Als Reaktion auf die gestrigen US-Sanktionen will auch Russland zehn US-Diplomaten ausweisen. Außenminister Lavrov kündigte außerdem eine Reihe weiterer Strafmaßnahmen an, unter anderem Einreiseverbote für hochrangige US-Staatsbedienstete. Washington hatte gestern zehn russische Diplomaten ausgewiesen und zusätzliche Sanktionen verhängt. Die Regierung beschuldigt Russland eines Hackerangriffs und der Einmischung in die US-Wahlen. Die Präsidenten Biden und Putin betonten zuletzt allerdings ihre Bereitschaft zum Dialog.
1:16: Also was wir hier gehört haben, die USA haben neue Sanktionen gegen Russland verhängt, diese richteten sich eben unter anderem gegen mutmaßliche Wahleinmischung, aber auch gegen insbesondere eine Cyberattacke, die zuvor passiert war. Und das ist etwas, was heute so ein bisschen im Fokus stehen soll. Um diesen kurzen Ausschnitt abzuschließen, Russland antwortete dann eben quasi spiegelbildlich auf diese US-Sanktionen mit dem Ausweisen von zehn US-Diplomaten aus Russland.
1:45: Genau, also so zwischenstaatlich schon eher, also da ist viel passiert, würde ich sagen. Also es ist jetzt nicht so, so zwischen Freunden macht man das nicht, würde ich sagen. Das war eine Phase der Eskalation, kann man sagen, aber uns geht es gar nicht so sehr um diese Eskalation, sondern was war denn eigentlich diese Cyberattacke, die da angeblich auch im Fokus stand, die zuvor passiert war.
2:06: Diese Cyberattacke, die hat es in Deutschland zu dem akuten Zeitpunkt noch nicht mal in die Tagesschau geschafft.
2:13: Aber in den USA war das ein Riesending. Also das gibt auch einen Wikipedia-Artikel allein zu dieser Cyberattacke. Die war all over the news. Da gab es ganz offizielle Anhörungen. Ja, das passiert wirklich nicht oft. Also zumindest nicht so in dem Ausmaß, würde ich sagen. Und man könnte sagen, es ist eine der größten Data Breaches, vielleicht aller Zeit auf jeden Fall des Jahres 2020 gewesen. So, und solche Data Breaches, die sind normalerweise relativ lame. Also man redet dann manchmal oder die Medien reden dann manchmal von Hackerangriffen oder von Cyberspionage oder so, aber sehr häufig sind solche Leaks, nur jemand hat seine Datenbank falsch konfiguriert, sodass sie für jeden erreichbar ist oder irgendwelche Standardpasswörter gelassen oder schwache Passwörter gelassen wie 1234 und dann irgendwelche Daten öffentlich zugänglich gelassen, die eigentlich nicht öffentlich sein sollten und das hat dann halt irgendein Akteur herausgefunden und dann die Daten abgezogen und dann geleakt. Das wird dann manchmal hochgespielt als Hackerangriff. Das hier ist aber explizit nicht sowas gewesen.
3:17: Diese Story ist nämlich aus zwei Gründen besonders interessant. Erstens, die Ziele waren absolut high profile. Also insbesondere war hier die US-Regierung betroffen. Und zweitens, technisch ist dieser Angriff viel fortgeschrittener. Und auch nicht nur die US-Regierung betroffen, sondern also irgendwie fast alle. Genau, auf der US-Bundesebene waren zwölf Ministerien betroffen, bei denen es zu einem Datenabfluss kam. Und darunter halt auch so Schwergewichte wie eben das Verteidigungsministerium, also Department of Defense oder das Energieministerium, Department of Energy.
3:55: Die sind übrigens so high profile wegen diesen Atombomben. Also ich muss mir immer klar machen, ach so ja Energie, warum ist das eigentlich so high profile? Ach ja.
4:03: Also die ganz großen Fische waren dabei und darüber hinaus auch wirklich signifikante Unternehmen, also Microsoft, Nvidia, VMware, Cisco, Palo Alto und so weiter.
4:19: Und in dem Umfang haben wir sowas in Deutschland zumindest öffentlich noch nicht gesehen. Also ich wüsste nichts davon irgendwie. So ein ganz krasser Angriff, der großen Prozentsatz der Regierung betrifft oder einen großen Prozentsatz der Privatwirtschaft und da auch nur große Firmen und so. Ja, das war ein Novum, sage ich mal.
4:39: Wir hören jetzt mal als O-Ton einen Ausschnitt aus einer Anhörung des US-Senats. Und das spiegelt so ein bisschen wider, was im Nachgang dieses Angriffs alles passiert ist.
4:52: Bevor wir das machen, eine Sache, die mir einfach sehr ins Auge gefallen ist, als ich das Video von dieser Senatsanhörung das erste Mal angeguckt habe, war, wow, da tragen ja alle Masken. Und dann, ja stimmt, das war 2020, da haben alle Masken getragen. Also vielleicht so, um das jetzt zeitlich auch so einzuordnen, ist jetzt auch schon eine Weile her. Gut, also Play.
5:29: Hier haben wir Kevin Mandia gehört. Das ist der Chef des Unternehmens Mandiant, ein Unternehmen, das so insbesondere auch Threat Intelligence liefert und die eben hier selbst auch betroffen waren von diesem Vorfall.
5:43: Und was er da kurz zusammengefasst in etwa sagt, ist, sie, und damit meint er eben die Angreifer, haben einen Testlauf gemacht im Oktober des Jahres 2019, wo sie harmlosen Code in das SolarWinds-Kompilat gepackt haben, nur um sicherzugehen, dass ihr Kompilat oder dass das resultierende Kompilat auch wirklich funktioniert.
6:09: Genau, wir werden später auch noch das zeitlich so ein bisschen einsortieren, aber vielleicht jetzt schon mal High Level. Er hat davon gesprochen, Oktober 2019 gab es diesen Testlauf von den Akteuren, und dieses Senate Hearing ist 2020. Also naja, wie immer waren die anscheinend schon weit vorher drin und haben da Stuff gemacht.
6:39: Ja, hier geht er nochmal auf dieses Vorgehen ein, dass diese Akteure hier anscheinend sehr vorsichtig vorgehen oder sehr besonnen sich durch das Netzwerk bewegen und dann nicht irgendwie Lärm machen und Türen eintreten, metaphorisch gesprochen.
6:53: Also er sagt, sie wollten sicher gehen, dass sie hier Code im Bildprozess einschleusen konnten oder injizieren konnten. Gemeint ist damit eben sozusagen das Kompilieren der Software, das Herstellen der Software. Da gehen wir im Detail nochmal später drauf ein. Und erst vier bis fünf Monate später wird ein tatsächliches Implant, also eine Malware, die dann auch eine Schadfunktion hat, dort über diesen Injektionsmechanismus quasi eingebaut werden.
7:33: Ja, ihr kennt das. Es gibt keine Armchair-Investigators-Folge ohne Attribution. Und das ist in diesem Fall auch wieder besonders interessant. Kevin Mandia formuliert sich hier so ein bisschen nach dem Ausschlussprinzip. Er sagt hier, dass es nicht sehr nach China, Nordkorea oder Iran aussieht. Und dass es, wenn, am ehesten Ähnlichkeit mit dem aufweist, was er bisher an Spionage und Verhalten mit Russland in Verbindung gebracht hat.
8:02: Also was Attribution angeht, finde ich, dass diese Formulierung, die er da leistet, wahrscheinlich auch aufgrund des Kontextes, sehr um den heißen Brei rumtanzen. Also sehr vorsichtig formuliert zu sagen, ja, die waren es nicht, die waren es nicht, die waren es nicht. Und das, was wir sehen, ist konsistent mit. Also es ist schon sehr theoretisch gehalten, sage ich mal. Aber TLDR ist die Russen waren’s.
8:22: Wir haben uns das natürlich auch ein bisschen angeguckt und wir werden später so ein paar Gründe sehen, warum das hier wahrscheinlich so vorsichtig formuliert wurde. Jetzt haben wir schon mal drei Fixpunkte aus dem aktuellen Fall. Also es geht um Malware, die tricky eingebracht wurde, die also irgendwie auf eine ganz besondere, trickreiche Art eingebracht wurde. Wir haben eine zeitliche Einordnung, es geht also irgendwie um 2019 etwa und wir haben einen staatlich attribuierten Akteur, nämlich Russland.
8:52: So, aber bevor wir da jetzt tief einsteigen, und wir werden tief einsteigen versprochen, erstmal vielleicht, was sind überhaupt all diese Namen, die wir bisher gehört haben und diese Firmen und dieser Bildprozess und diese Software und sowas alles. Es geht um eine Firma und die heißt SolarWinds und auf deren Webseite wurden irgendwann Updates gehostet für deren Software oder für eine deren Softwarelösung und die heißt Orion. Also die Webseite von SolarWinds hat Updates für die Orion-Software verteilt und da stellte sich dann raus, dass eine dieser Dateien eine DLL-Datei enthält. Das ist so eine Windows-Library-Datei, die von der Software verwendet wird und auch notwendig ist und die heißt orion.core.businesslayer.dll und um die wird es heute primär gehen.
9:41: Und dieses Update enthielt Malware, dessen Name Sunburst ist.
9:47: So, und wenn wir mal ehrlich sind, Sunburst, das ist einfach Malware. Also das ist so ein Implant und das kann so was, so ein Implant so alles können muss, um überhaupt als Implant gezählt zu werden.
9:59: Also das kommuniziert mit so einem Command & Control Server, das sammelt Systeminformationen von dem identifizierten System und das lädt die hoch. Das kann bestimmte Aufgaben ausführen, das kann Prozesse terminieren. Sachen runterladen, lesen, schreiben, löschen und so weiter und sofort, den Rechner rebooten und so weiter. Also das sind typische Funktionsweisen von Implants.
10:23: Also schon gefährlich und so, aber für uns halt jetzt hier super langweilig und uninteressant. Also das ist nicht der spannende Teil in diesem Case. Viel spannender ist, wie ist diese Malware da reingekommen? Und direkt vielleicht eine kleine Feinheit. Wir haben gesagt, die Malware heißt Sunburst. Aber das, worüber wir heute reden werden, das ist Sunspot. Das ist quasi der Auslieferungsmechanismus für die Sunburst-Malware. Und wir schließen die Sunburst-Malware heute einfach aus, weil es dauert schon lange genug, Folgen vorzubereiten. Das heißt, das machen wir nicht. Wenn ihr mehr dazu hören wollt, dann reagiert auf unsere Posts auf Social Media und wünscht euch eine Folge zu Sunburst.
10:58: Jetzt ist eben die Frage, wie wurde denn diese Malware verbreitet? Du hast es schon gesagt, Lars, über Updates, die auf der offiziellen Webseite gehostet waren. Und dann liegt natürlich so ein bisschen die Frage im Raum, hat da jemand den Update-Server übernommen und kompromittiert und die Updates, sozusagen die legitimen Updates, ausgetauscht durch schadhafte Updates?
11:21: Und stellt sich raus, nein, es ist noch viel, viel schlimmer.
11:26: Werfen wir also nochmal einen Blick auf Orion. Man könnte sich die Frage stellen, auf wie vielen Systemen ist Orion denn überhaupt installiert, insbesondere weil dieser Name vielleicht gar nicht so geläufig ist, das ist keine Software, die Endbenutzer typischerweise zu Hause installiert haben. Zu dem damaligen Zeitpunkt gab es etwa 33.000 Orion-Benutzer. Etwa 17.000 davon haben die Malware bekommen. Das heißt, Ryan hatte schon eine extrem große Reichweite. Gerade von diesen 33.000 Benutzern gab es eben einige, die wirklich Schwergewichte waren. Zum Beispiel 425 von den 500 Fortune 500 Unternehmen setzten diese Software ein. Die zehn größten Telekommunikationsprovider setzten es ein und alle fünf Bereiche des US-Militärs setzten es ein. Unter anderem eben auch das Weiße Haus, das Pentagon, Außenministerium und so weiter.
12:21: So, also wir haben schon diesen Decline jetzt von 33.000. Insgesamt 17.000 davon haben dieses malicious, dieses bösartige Update bekommen. Und jetzt geht es noch weiter runter. Jetzt kann man sich ja fragen, welche von diesen 17.000 Infektionen, welchen davon ist überhaupt was passiert? Und da stellt sich raus, nur auf ungefähr 100 dieser Installationen wurden von dem Akteur aktiv genutzt, um weitere Aktionen durchzuführen, also Follow-on-Activity.
12:48: Bei circa 40 davon kam es wohl nachweislich dann auch zu Datenabfluss, also soweit man das irgendwie feststellen konnte. Also wir haben 33.000 angefangen, 17.000 haben das Update bekommen, nur auf 100 ist der Akteur aktiv geworden, also wieder ein Bruchteil davon und unter der Hälfte davon sind dann überhaupt Daten abgeflossen.
13:10: So, jetzt fragt ihr euch natürlich alle, was ist Orion? Das habe ich mich schon immer gefragt. Und das muss man vielleicht so erklären. Computersysteme müssen gemanagt und gewartet werden. Nicht bei euch zu Hause, aber in großen Netzwerken, also in Umgebungen, wo irgendwie tausende Computer zum Einsatz kommen.
13:29: Da machen solche Systeme Sinn, denn stellt euch Folgendes vor, ein System oder ein Computer fällt aus, dann will man das in der Regel nicht dadurch erfahren, dass der Benutzer diesen Dienst oder die Webseite nicht mehr nutzen kann. Sondern das will man idealerweise vorher erfahren und dazu gibt es halt ganz viele automatische Prozesse, die nichts anderes machen als zu überprüfen, sind bestimmte Dienste noch erreichbar oder wie lange dauert es, bis ich eine Antwort von einem Rechner bekomme. Und genau sowas hat Orion gemacht. Also es ist eine Monitoring- oder Überwachungs- oder Systemmanagement-Software, die eben für die Verfügbarkeit oder die Überprüfung der Verfügbarkeit von IT-Systemen gedacht ist. Aus Angreifersicht ist es jetzt eben besonders praktisch, wenn es einen großen Kundenstamm gibt und in diesem Kundenstamm noch eine hohe Anzahl von großen Unternehmen oder politischen Schwergewichten zu finden ist.
14:26: Also um nochmal gerade ein Stück raus zu zoomen, bei diesem Angriff wurde so ein Software-Lieferant kompromittiert und der hat danach quasi ohne es zu wissen Malware ausgeliefert. Und bei solchen Angriffen redet man von Supply-Chain-Attacks oder Supply-Chain-Angriffen oder Lieferketten-Angriffen, ein Wort I guess. Und da gehen wir später noch ein bisschen genauer drauf ein, aber das ist ein großes Thema, dieses Supply-Chain-Attacks. Könnte sowas in Deutschland eigentlich auch passieren, Chris?
14:55: Das kann in Deutschland auch passieren. Es gibt keinen Grund, warum es in bestimmten Regionen nicht irgendwie auch passieren könnte. Vielmehr ist hier wahrscheinlich entscheidend, ob dieses Ökosystem, sagen wir mal, heterogen ausgeprägt ist. Also wenn sich viele auf eine Lösung konzentrieren, dann wird diese eine Lösung auf einmal sehr attraktiv für einen Angreifer, für solche Supply-Chain-Angriffe, für solche Lieferketten-Angriffe. Und das mag durchaus in Deutschland auch der Fall sein. Also ich weiß nicht, welche VoIP-Telefoniesysteme in den Ministerien zum Einsatz kommen und ob das sich auf wenige Lieferanten beschränkt oder nicht. Aber genau das ist so etwas, was die Angreifer vielleicht versuchen herauszufinden.
15:43: Ich wollte jetzt noch mal auf das herauszufinden kurz eingehen. Also es ist irgendwie plausibel, dass die Angreifer vorher so Webseiten gescoutet haben und die Hersteller von dieser Orion Software, SolarWinds, die hatten da auch quasi alle Logos auf der Webseite drauf von ihren Kunden. Also sie konnten dann quasi, wahrscheinlich haben sie so ein paar solcher Software-Lieferanten-Webseiten angesurft, alle Logos angeguckt und dann vielleicht sich auf die konzentriert mit besonders vielen Logos. Guck mal, viele Fortune 500, alle Branches des Militärs, perfekt. Genau, ja, welche Software-Lieferanten könnte es in Deutschland geben? IBM, Lotus. Lotus Notes.
16:20: Ja, ich fürchte nicht mehr, aber hey. Ja, vielleicht sowas. Also es muss ja auch noch, es muss ja nicht nur eine Firma sein mit viel Impact, es muss auch noch eine Firma sein, die nicht so gigantisch groß ist. Also ich meine, eine Firma, die sofort natürlich ins Auge fällt oder in den Kopf kommt, ist Microsoft. Also ich denke, ein Großteil der deutschen Regierung hängt von Microsoft Windows ab und nicht nur der Regierung, sondern auch von allen Firmen. Es gibt ganz wenig Pilotprojekte, die irgendwie Linux einsetzen oder sowas. Aber es ist halt auf der anderen Seite auch so, dass Microsoft noch nie malicious Updates ausgeliefert hat. Also außer man bezeichnet das Ausliefern von Windows als malicious. Also mir ist kein Fall bekannt, dass das Windows Update jemals irgendwie Malware enthalten hat. Sagen wir nicht bekannt. Genau.
Build-System und Infektionsprozess
17:02: Gut, kommen wir zum zweiten Teil. Intro ist vorbei. Jetzt geht es ein bisschen ans Eingemachte. Und zwar müssen wir da erstmal drüber reden, wie man heute überhaupt Software baut.
17:12: Wie baut man denn heute überhaupt Software, Lars?
17:17: Da gibt es etwas, das nennt man Continuous Integration. Jetzt bin ich mal wieder bemüht, das auf Deutsch zu übersetzen. Kontinuierliche Herstellung oder kontinuierliche Integration, irgendwie sowas. Und was das bezeichnet ist, dass man Software automatisch und zentralisiert baut. Das macht man, damit so Bauprozesse von Software reproduzierbar sind und vielleicht auch, damit es nicht zu sehr abhängt von dem konkreten System, auf dem es dann gebaut wird. Ich kann mir vorstellen, dass wenn man vielleicht jetzt keine Firma ist, keine so große Firma ist, die so Continuous Integration einsetzt, dann wird so Software einfach auf Computern gebaut, die von EntwicklerInnen genutzt werden und die sind vielleicht alle so ein bisschen anders und dann ist das Kompilat, was am Ende rauskommt, so ein bisschen anders und dann könnte man vielleicht sogar im Kompilat erkennen, auf welchem EntwicklerInnen-System es gebaut wurde. Also das will man vermeiden mit sowas wie Continuous Integration.
18:10: Man könnte sagen, früher war das so, also da gab es die Petra und die hat halt immer den Code kompiliert. Und das hat die halt immer zu einem bestimmten Zeitpunkt gemacht und dann ist da die fertige Software bei rausgefallen. Und man wollte irgendwie weg davon, dass das irgendwie so an einzelnen Personen irgendwie hängt und an einzelnen Systemen, die diese Personen dafür benutzt haben, hin zu einem automatisierten Prozess. Da ist man heute häufig. Das hat halt die Effekte, die du gerade beschrieben hast, dieser Prozess, die Software zu bauen, wird reproduzierbarer. Das hat aber auch einen Effekt, nämlich in der Regel schaut man sich das Kompilat, also das, was quasi das Erzeugnis dieses Softwarebauens ist, das schaut man sich nicht mehr händisch an.
18:56: Jetzt kann man sehr tief in Definitionsfragen einsteigen, aber diesen Continuous Integration, diesen automatischen Bildprozess zu kompromittieren, das würde ich auf jeden Fall als Software Supply Chain Compromise oder Software Supply Chain Attack bezeichnen. Mein Gefühl ist, und es wird jetzt vielleicht ein bisschen ranty, ist, dass der Begriff Supply Chain Attack sehr häufig verwendet wird. Also, was nicht bei drei auf den Bäumen ist, nennt man plötzlich Supply Chain Attack. Weil ich nicht, jemand veröffentlicht eine Library, die so ähnlich heißt wie eine andere Library, aber die ist Malware stattdessen. Dann nennt man das jetzt schon Supply Chain Attack. Und das finde ich so ein bisschen lame, weil eigentlich finde ich, dass Supply Chain Compromises so eine gewisse Schöpfenshöhe oder so eine gewisse Komplexität voraussetzen, die wir hier in diesem Fall auf jeden Fall vorfinden, aber naja, also wie gesagt, der Begriff wird sehr inflationär verwendet.
19:52: Du willst sagen, es ist eine besonders schöne Supply Chain Attack, die wir uns hier herausgesucht haben.
19:55: Es ist ein Gemälde von Supply Chain Attack, genau, richtig.
20:00: Genau, und jetzt ist so ein bisschen die Frage, wie schnell wurde das eigentlich entdeckt? Da muss man sagen, das war nicht einfach zu entdecken. Also an der Stelle kann man sagen, haben die Angreifer schon Erfolg gehabt. Wir haben ja eben schon gehört, über den Einspieler vier bis fünf Monate hat es gedauert, zwischen dem ersten Mal ausprobieren bis zu dem Zeitpunkt, wo wirklich Malware auf die Art und Weise da reingekommen ist. Und das wird eben auch von Kevin Mandiaso beschrieben, der eben sagt, ja, wir sind irgendwann so auf so Unauffälligkeiten oder Missstimmigkeiten aufmerksam geworden und dann mussten wir quasi alles absuchen. Dann haben wir einfach von vorne bis hinten alles umgekrempelt.
20:42: Und das kann man sich auch relativ gut vorstellen, ja, selbst auf einem frisch installierten Windows-System läuft heutzutage super viel. Da gibt es jede Menge Prozesse, in diesen Prozessen jede Menge Threads, es gibt super viele Abhängigkeiten, also super viele Bibliotheken, die da laufen, das muss man alles kennen.
21:02: Genau, die haben auch jetzt keine sehr normalen Namen. Also es gibt zum Beispiel einen Windows-Dienst, der heißt Intelligent Background Transfer Service, Intelligenter Hintergrundsübertragungsdienst. Und wenn, also das hört sich einfach schon nach Malware an. Es ist aber einfach ein normaler Windows-Dienst, der da auch hingehört. Also das ist einfach extrem unübersichtlich, was da so alles läuft auf so einem Windows-Dienst.
21:23: Jetzt muss man sich vorstellen, dann kommt man an den Punkt, man hat irgendwie fast alles abgesucht. Aber natürlich gibt es da noch so ein paar Programme, die da irgendwie so installiert sind. Und eins davon ist dann irgendwie auch Orion. Und dann fängt man irgendwie an zu schauen. Jetzt kennt man natürlich selber diese Orion-Software nicht in- und auswendig. Das heißt, man guckt sich irgendwie an, wo kamen denn die Dateien her, die da von Orion gerade benutzt werden. Dann stellt man fest, ja, das sind also Dateien, die teilweise über die erste Installation kamen. Teilweise kamen die dann über die Update-Server. Und die kamen sogar über die legitimen Update-Server, die Orion da regelmäßig nutzt. So, und dann ist man an einem Punkt, wo man sich so als Incident Responder wirklich fragen muss, okay, was passt hier nicht zusammen? Sehe ich irgendwas nicht? Also hat der Angreifer sich so gut versteckt, dass ich gerade nicht sehe, wo der ist? Oder sehe ich eigentlich, was hier Teil des Angriffs ist? Nur die Art und Weise, wie diese Malware auf das System gekommen ist, ist mir nicht klar, beziehungsweise ist mitkompromittiert worden. Und genau Letzteres haben wir eben in diesem Fall. Und dazu müssen wir jetzt ein bisschen ans technisch Eingemachte gehen, um klar zu bekommen, was da eigentlich passiert.
22:39: Reverse Engineering im Audioformat, das ist ja unsere Spezialität. Also, wir gehen jetzt nochmal weg von der eigentlichen Software, in der die Malware drin ist, diesen Updates, die da auf der Orion-Webseite, die da auf der SolarWinds-Webseite waren und gehen hin zu deren Build-Server, also der Server, der diese Software kompiliert, diese Orion-Software. Also für die Leute, die darüber erscheint wissen, das ist eine .NET-basierte Software, Orion, und die werden häufig kompiliert mit dem Microsoft Compiler oder der Microsoft Build Toolchain. Und da gibt es eine Datei, die heißt msbuild.exe, die ist so hauptsächlich dafür verantwortlich, diese Software zu kompilieren. Und auf diesem Build-Server lief nicht nur diese Microsoft-Toolchain, um Software zu bauen, sondern auch eine weitere Malware, nämlich Sunspot. Und die hat Stuff gemacht. Und das ist halt richtig abgefahren.
23:38: Wenn man Software baut, dann läuft der Compiler nicht ständig, sondern in der Regel ist es so, man macht Änderungen am Quellcode, die werden vielleicht in so ein Quellcode-Verwaltungssystem gepusht und das triggert dann, dass diese Software neu gebaut werden muss. Und die eigentliche Dauer, die der Compiler da läuft, sind vielleicht ein paar Minuten, vielleicht manchmal auch nur ein paar Sekunden. Und die abgefahrene Technik, die die Angreifer jetzt hier verfolgt haben, ist, dass sie gesagt haben, wir warten, bis auf dem Buildsystem der Compiler angeschmissen wird, und dann tauschen wir Teile des Quellcodes aus. Und wenn der Compiler fertig ist mit Kompilieren, dann tauschen wir das Ganze wieder zurück, sodass es hoffentlich nicht auffällt.
24:27: Was da als erstes so passiert ist, ist, man hat geguckt, auf der Prozessliste ist msbuild.exe. Das wurde mit Hashing gemacht, aber das ist wirklich jetzt ein Nerd-Detail, sag ich mal vorsichtig. Also hat einfach gewartet, bis so eine Instanz davon läuft. Dann hat es die pausiert und dann hat es die Datei Core.sln in dem Pfad davon gesucht. Und Core.sln, also SLN-Dateien, sind in dem Microsoft-Universum Solution-Files und das ist für diese Microsoft-Build-Environment quasi so Projekte oder Sammlungen von Projekten. Und hier diese Sammlung von Projekten, die ist Core.sln, das ist wahrscheinlich eine SolarWinds-Sache, also die haben anscheinend einen Teil Core genannt. Dieser Schritt, der stellt sicher, dass es sich hier um eine Kompilierung handelt, die auch wirklich…
25:14: Die Software ist, die man hier kompromittieren wollte und nicht noch irgendwas anderes. Weil theoretisch könnte auf diesem Bildsystem jede Software, die SolarWinds hergestellt hat und herstellt, irgendwann mal kompiliert werden. Und vielleicht ging es darum, auch bei diesem Testing ganz am Anfang, die haben wahrscheinlich da lange rumgedoktert, bis sie hier angekommen sind. So, und dann passiert genau das, was Chris gesagt hatte. Es gab eine Datei, die heißt inventorymanager.cs. CS, also .CS-Dateien sind Source-Code-Files von C-Sharp, also Quellcode-Dateien mit C-Sharp-Quellcode drin, der wird nach .NET kompiliert und die Datei hieß Original Inventory Manager und der wird anscheinend dann nachher Teil von dieser Business-Layer-DLL. Und dann ist genau das passiert, was Chris gesagt hat, die Datei wurde ausgetauscht gegen was anderes, dann wurde gewartet, bis der Buildprozess also dann wurde der Buildprozess resumed, also dann konnte der seine.
26:09: Kompilierung zu Ende durchführen und dann wurde gewartet, bis er fertig ist und Und danach wurde die Datei, wurde das Original wieder hergestellt. Das heißt, selbst für den unwahrscheinlichen Fall, dass da jemand auf dem Buildsystem guckt, was liegt da noch für Quellcode rum nach so einem Softwarebau, hätte man nicht gesehen, dass hier Malware eingeschleust wurde. Also ich würde sagen, das wäre auch nicht aufgefallen. Vielleicht war das übervorsichtig, aber vielleicht gab es auch einen Grund. Also jedes schildernde Geschichte, vielleicht gab es einen Grund, dass die da entschieden haben, wir stellen danach die Originaldatei wieder her.
26:38: Genau, und jetzt hast du schon so beschrieben, wie man das vielleicht vernünftig softwaretechnisch machen würde. Also man hält den Compiler irgendwie an, tauscht dann aus und dann lässt man den irgendwie weitermachen. Da haben die Angreifer hier aber nicht drauf geachtet, sondern die sind also bewusst das Risiko eingegangen, dass theoretisch der Compiler schneller sein könnte mit dem Kompilieren, als sie es selber sind mit dem Austauschen von dem Code.
27:01: Und das nennt man Race Condition. Also auf Deutsch vielleicht sowas w ie… wie nennt man das auf Deutsch, Lars?
27:08: Ja, genau. Ich bin ja übersetzt alle englischen Fachbegriffe auf Deutsch beauftragt.
27:14: Wettrennsituation.
27:15: Ja, also eine Race, also genau, Race heißt Wettrennen und Condition heißt irgendwie eine Situation, die das vorkommt. Also da sind zwei Sachen und die laufen um die Wette miteinander und die Frage ist jetzt, welche von den beiden Sachen ist zuerst fertig? Ist die Malware zuerst fertig damit, diese Quellcode-Datei auszutauschen oder ist der Compiler erst fertig damit, zu Ende zu kompilieren? Naja, was das Austauschen dann unmöglich machen würde. Das hat hier aber wohl trotzdem funktioniert. Das ist auch vielleicht schon irgendwie nachvollziehbar. Also vielleicht war es auch nur Glück, dass es funktioniert hat und die haben sich da gar nicht so viel Gedanken drüber gemacht. Wahrscheinlich ist diese Orion-Software insgesamt relativ groß. Das heißt, da wird schon insgesamt relativ viel compiled. Und diese Quellcode-Datei, die dort manipuliert werden sollte, die war vielleicht immer sozusagen eher so, was weiß ich, letzten Drittel des Kompilats verwendet worden. Und dann kommt das vielleicht hin, weil das Austauschen von einer Quelldatei auf Platte ist jetzt auch nicht so aufwendig im Vergleich vielleicht zu dem, was ein Compiler sonst da alles so irgendwie machen muss. Ja, man könnte sich das vielleicht auch als Metapher vorstellen. Und zwar stell dir Folgendes vor, du bist Bäcker und du backst einen Kuchen. Also du bist ja so in der Küche, gehst da her und backst da irgendwie so einen Kuchen. Du hast dir so all deine Zutaten irgendwie bereitgestellt. Und in dem Moment, wo duden Zucker nehmen willst, um den in die Schüssel da zu schütten.
28:34: Stehe ich daneben und tausche den Zucker durch das Salz aus, sodass du es nicht merkst. Und dann stellst du das Salz, was du da reingeschüttet hast, die Schüssel, stellst du wieder zurück und in dem Moment tausche ich es wieder zurück, sodass es im Nachhinein vielleicht auch nicht auffällt. So muss man sich das vielleicht hier vorstellen mit dieser Race Condition. Und genau, wenn es richtig ungünstig gelaufen wäre, dann hättest du den Zucker schon in die Schüssel gepackt, bevor ich irgendwie bereit gewesen wäre, da irgendwie rumzutauschen. Und ja, so kann man sich das vielleicht so ein bisschen so vorstellen. Also der Angreifer geht so ein bisschen eine Wette ein. Man muss aber sagen, in dem Fall hat er hier ziemlich gute Karten, einfach weil der Aufwand, so eine Datei auf Platte zu tauschen, nicht so groß ist im Vergleich zu dem, was der Compiler sonst noch alles da so machen muss.
29:16: Gut, also das schließt eigentlich diesen ganzen Themenkomplex ab, aber wir haben uns ja für diese Sektion auch die Malware angeguckt und da Reverse Engineering betrieben und eine Sache, die ich jetzt hier nicht für mich behalten wollte, ist, dass da super viele Log-Messages in der Malware noch drin waren. Also so Sachen wie, das hier, das hat geklappt, das hier hat nicht geklappt, das hier hat geklappt, das hier hat nicht geklappt. Also so, ich sag mal, Statusmeldungen, die einfach die Malware ausgeben würde in so einer Konsole, in der die zum Beispiel läuft. Also ich rede jetzt von der Malware, die diesen Build-Prozess negativ beeinträchtigt hat. Genau, also sowas wie, habt den Compiler-Prozess msbuild.exe gefunden, ja oder nein und so weiter. Das habe ich dann, als wir dann später dieses Sanitary durchgehört haben und von Mandia ja da gehört haben, dass da ein Testrun durchgeführt wurde. Das war für mich sehr stimmig. Also man sieht in dieser Malware so Log-Messages und der Akteur hat da irgendwie Testing durchgeführt. Die haben da vielleicht so, ich sag mal, auf diesem Live-System auch rapide getestet. Ja, haben was probiert, das ging nicht, haben was Neues probiert, das ging nicht. Dann mussten sie ein bisschen mehr Log-Messages einbauen, um besser sehen zu können, was hat geklappt, was hat nicht geklappt. Und ja, das war dann für mich insgesamt schon eher stimmig.
Motivation und Vorgehensweis
30:30: Ja, vielleicht holen wir uns nochmal eben die Zeitleiste vor Augen.
30:35: Ja, lass uns das machen.
30:36: Und werfen dann auch so ein bisschen so einen Blick auf die Motivation für diese Vorgehensweise. Also im Oktober 2019 war dieser Trockenlauf sozusagen, dieser Übungslauf, das heißt signifikant vor Oktober 2019 muss der initiale Zugriff passiert sein. Im März 2020 startet dann sozusagen die tatsächliche Infektion und im Dezember 2020 wird sie entdeckt. Das heißt also neun Monate dauerte es bis zur Entdeckung. Das ist übrigens kein Einzelfall. Auch neun Monate hat es gedauert in der Uniklinik Düsseldorf und da hört am besten mal in Folge 3 rein. Im Februar 2021 war eben diese Senatsanhörung, zu der wir die Einspiele auch zu Beginn dieser Folge gehört haben. Jetzt steht vielleicht noch eine Frage im Raum, was will der Angreifer eigentlich erreichen? Lars?
31:33: Ich würde einfach sagen, der will die Orion-Software von SolarWinds dahingehend manipulieren, dass er Zugriff erhält, sobald diese Software irgendwo rausgeführt wird, in der Hoffnung oder in dem Wissen, dass das an vielen, vielen Systemen dann auch wirklich am Ende der Fall ist.
31:49: Jetzt kann man sich fragen, wie hätte er das denn eigentlich erreichen können? Er hätte halt zum Beispiel eben den Quellcode verändern können und zwar in der Phase, wo der Quellcode irgendwie geschrieben wird oder auf eine ähnliche Art und Weise, wie das eben die regulären Autoren mit dem Quellcode machen würden.
32:06: Das ist aber natürlich super auffällig. Also jeder ernstzunehmende Quellcode ist unter Versionskontrolle und dann wird man einfach sehen, dass es da so eine Änderung gibt und da wird dann einfach Malware-Code eingefügt.
32:20: Ja, er hat ja Quellcode manipuliert, aber er hat das Zeitfenster, in dem dieser manipulierte Quellcode überhaupt als Quellcode da ist. Dieses Zeitfenster hat er minimiert. Er hat eben versucht, das nur für den Zeitpunkt, wo der Compiler diesen Quellcode wirklich dann braucht und nimmt und in Binärcode überführt. Nur für diesen kurzen Moment hat er versucht, den irgendwie auf Platte irgendwo liegen zu lassen. Man hätte das eigentlich auch noch viel cooler machen können. So mit rein in Memory injecten und so. Aber wir wollen aber nicht zu tief reingehen.
32:52: Naja, und ich meine, es hat ja vor allem funktioniert. Ich bin ja ein großer, ich sehe mich gerne als großer Pragmatiker. Ich formuliere es mal so rum. Und also warum was machen, was, also ich meine, neun Monate nicht entdeckt werden, so viele Targets haben. Also warum dann noch mehr Aufwand betreiben dafür, dass es vielleicht auch noch unstabiler wird und schwerer zu maintainen? Also es hat ja auch einfach geklappt.
33:15: In der Vorbereitung für die Folge hast du so eine interessante Beobachtung zu der Malware-Terminologie gemacht. Und die kann man nur bei Supply Chain Attacks machen, nämlich…
33:24: Es gab früher so eine bestimmte Art von Malware, die hießen Computerviren. Einige Leute verwenden das als Synonym für Malware, aber eigentlich würde man damit eher Malware bezeichnen, die sich verbreitet und andere Sachen infiziert, wie halt biologische Viren auch. Und die sind sehr außer Mode gekommen, sage ich mal vorsichtig. Klar, die gehen nicht weg. Also die Computerviren, die es irgendwann mal gab, die schaffen es immer noch, sich so ein bisschen weiter zu verbreiten. Aber die haben heutzutage eigentlich kaum noch eine Chance, wirklich Fuß zu fassen, weil, auch aus vielen Gründen, Virenscanner sind besser geworden, die Viren sind inhärent nicht so sehr in der Lage, sich krass zu modifizieren, sind relativ leicht Signaturen für zu entwickeln, sowohl statische als auch dynamische und so.
34:09: Aber was mir aufgefallen ist, ist, dass so Supply Chain Compromises, so eine Art moderne Art dieser automatischen Verbreitung sind. Ja, also man könnte jetzt irgendwie sagen, wir haben hier diesen Virenhost, also dieses Ding, was auf dem Bildsystem von SolarWinds da lief. Und das hat dann sein Schadcode in alle möglichen Sachen injected, die dann sich verbreitet haben. So ein bisschen wie so ein Virus.
Attribution
34:32: Nachdem wir jetzt noch ein bisschen über die Motivation geredet haben, ist das so eine super Einleitung zu der Attribuierungsphase dieser Folge.
34:41: Wir haben ja schon anklingen lassen in dem Einspieler durch Kevin Mandia, dass die Attribuierung hier, sagen wir mal, nicht völlig offensichtlich war. Klar, im Nachgang kann man sagen, US-Government attribuiert den SolarWinds-Vorfall zum SWR. Also auch aus dem White House gab es ein Statement zur Attribuierung. Aber das ist jetzt eben die retrospektive Sichtweise. Und in guter Armchair-Investigators-Manier wollen wir die Attribuierung hier mal aufdröseln.
35:09: Denn wir haben gemerkt in der Vorbereitung dieser Folge, da gibt es nicht so viel. Also zumindest nicht so viel, wo wir mit öffentlichen Quellen rankommen, was dann reproduzierbar ist und irgendwie malwarelastig wäre oder so.
35:23: Und das muss man jetzt konkretisieren, denn wir haben ja hier maßgeblich die Sunspot-Malware beschrieben. Das ist also dieser Teil, der in diesem Build-System da arbeitet. Und wenn wir uns da so nochmal eben drauf fokussieren, dann ist genau wie du gesagt hast, dann gibt es da tatsächlich gar nicht so wahnsinnig viel zu holen. Also da sind auch keine C2s, irgendwie hops genommen, wo man irgendwie was draus lesen kann. Die Victimology hingegen, die ist natürlich bekannt.
35:49: Also Victimology heißt hier, wer ist hier zum Opfer gefallen von diesem Angriff?
35:55: Genau, nur das ergibt sich gar nicht mal unbedingt primär aus der Malware, also aus der Sunspot-Malware, sondern natürlich aus der Art und Weise, wie die Verteilung da passiert ist. Und das ergibt sich eben letztlich auch nur aus einer ganzen Menge an Incident Response, die in den Zielorganisationen dann passiert ist.
36:13: Und was hier auch der Fall ist, ist, dass kompromittiert sein nicht mehr ganz so schwarz und weiß ist. Also wir hatten ja am Anfang gesagt, 33.000 Kunden, 17.000 haben das malicious Update bekommen. Diese 17.000 waren in gewisser Weise kompromittiert, aber es ist nichts passiert. Nur bei irgendwie 100 davon ist da noch was passiert. Also jetzt kann man natürlich fragen, wie so ein Baum der umfällt, kompromittiert sein muss, passiert nichts, ist es dann überhaupt kompromittiert?
36:38: Man kann also kompromittiert sein im Sinne von, dass die Malware angelaufen ist, aber es kam halt möglicherweise nie zu einem Datenabfluss. Jetzt kann man in einem weiteren Schritt nochmal überlegen, auf was für eine Art von Akteur weist das denn eigentlich hin? Also wenn da irgendwie so im großen Stil 33.000 potenziell Betroffene, 17.000 de facto betroffen, ist das jetzt irgendwie ein Hinweis auf einen finanziell motivierten Akteur oder eher auf einen staatlich gestützten Akteur? Wie kann man das versuchen irgendwie einzuordnen?
37:10: Also hier würde man zum Beispiel ja sagen, also wenn es ein finanziell motivierter Akteur wäre, gewesen wäre, dann hätte ich vorher irgendetwas erwartet, was auch Geld macht, sag ich mal. Also Ransomware, Kryptomining, irgendwas so in die Richtung. Und nicht, dass man da lange wartet, nur sehr gezielt ganz wenige Ziele angreift im Sinne von, dass man wirklich Daten klaut. Und da würde sehr viel Disziplin dazu gehören. Also was heißt Disziplin? Also je länger man in so einem System sitzt, wahrscheinlich ist es auch, dass man irgendwann auffliegt. Also ich halte die Wahrscheinlichkeit für einen finanziell motivierten Akteur hier aus den eben genannten Gründen eher gering.
37:54: Man kann das letztlich nur festmachen an der Art der Daten, die dort entwendet wurden. Das ist nicht im Detail bekannt, aber es gibt die Einschätzung dazu und es gibt eben die Information, in welchen Zielumgebungen es eben zu dem Datenabfluss kam. Und das sind eben maßgeblich Ministerien, politische Institutionen und eben ein paar von diesen sehr großen Unternehmen gewesen, sodass es vermutlich eher nahe liegt, dass man hier einen Spionagehintergrund vermuten kann.
38:28: Ja, und da hört es auch leider schon auf mit der Attribution hier. Also es reduziert sich leider auf so ein Trust be bro, I’m the government. Also die USA haben gesagt, es ist der SWR, also der russische Nachrichtendienst und viel mehr konnten wir da nicht aus öffentlichen Quellen reproduzieren, leider.
38:44: Wenn man sich jetzt aber die Malware der Folgestufen anschaut, Sunspot hat dafür gesorgt, dass Ryan manipuliert wurde. Sunburst war die erste Stufe der Malware, die dann in der Zielumgebung zum Laufen kam. Und dann ging es eben weiter, die Malware-Familien danach, das waren so Cobalt-Strike-Loader, Teardrop, Raindrop und ähnliches. Wenn man die weiter analysiert hat, dann findet man irgendwann Code-Ähnlichkeit zu Malware, die man sich schon mal angeschaut hat. Das ist nicht wahnsinnig stark. Ein Beispiel für diese Code-Ähnlichkeit besteht zwischen Sunburst und Kazuar. Kazuar ist ein Implant, das Venomous Bear attribuiert ist. Ah, jetzt machen wir da einen Fass auf…
39:32: Ja, jetzt machen wir auf jeden Fall einen Fass auf.
39:34: Neben dem Code-Overlap, den Mandiant beschreibt, also zu altem Cozy Bear Tooling, gibt es von Kaspersky-Forschern etwas, das vielleicht auf den ersten Blick nicht so ganz ins Bild passt.
39:45: Nur gerade zur Erinnerung, Cozy Bear, das ist der SWR. Also der russische Geheimdienst.
39:50: Diese Code-Ähnlichkeit, die die Kaspersky-Forscher beschreiben, die besteht eben zwischen Sunburst und Kazuar. Fragen sich alle, was ist Kazuar?
39:57: Und Kasua ist Malware, die wird nicht Cozy Bear zugeordnet, sondern die wird Venomous Bear zugeordnet, nämlich dem FSB, also einem anderen Geheimdienst.
40:07: Immerhin beides russische Nachrichtendienste.
40:10: Aber es sind verschiedene Geheimdienste. Und wie kann es überhaupt dazu kommen?
40:14: Da gibt es sicherlich viele Optionen. Eine wäre, dass es zwar unterschiedliche Nachrichtendienste sind, die aber sozusagen auf einen gemeinsamen Entwickler irgendwie zurückgreifen. Das heißt, es könnte eine Form von Dienstleistung sein, diese Schadsoftware zu entwickeln oder diese Implants zu entwickeln. Es könnte sein, dass es da irgendwie zu einem Wissensaustausch kam. Das heißt, dass man sich da irgendwie abgeglichen hat über bestimmte Vorgehensweisen.
40:39: Genau, das ist quasi Option eins. Es gibt irgendwie einen personellen Overlap, also die Leute gehen zusammen Mittagessen oder vielleicht hat auch einfach einer den einen Dienst verlassen und ist in den anderen eingetreten. Solche Dinge können ja einfach passieren.
40:51: Ja, genau. Also Weitergabe von Code ist vielleicht auch nicht auszuschließen. Das heißt, dass man wirklich mal gesehen hat, wie jemand anders das implementiert hat. Dann eben diese Dienstleister-Geschichte oder also Contractor, dass man halt aus der gleichen Quelle so etwas bezieht. Ja, eine Option, die, weiß ich nicht, wie wahrscheinlich die ist, aber man könnte auch eine False Flag natürlich irgendwie denken, wobei die jetzt in dem Setting hier wahrscheinlich irgendwie am wenigsten sind.
41:17: Ergibt super viel Sinn. Ja, ich bin irgendwie Cozy Bear und tue so, als wäre ich Venemous Bear oder umgekehrt, um was zu erreichen? Also ich meine, die Medien werden sowieso nur berichten, die Russen waren es. Also wir müssen irgendwann mal eine Folge machen, wo wir die ganze Zeit nur über False Flag Anschuldigungen ranten. Ich bin da wirklich ein bisschen ermüdet. Aber das kann natürlich immer passieren.
41:38: Wenn man das Ganze mal zusammenfasst, dann muss man eben sagen, dieser Vorfall wird von verschiedenen Quellen mittlerweile dem SWR zugeordnet oder zugeschrieben. Auch aus der Industrie, also eben FireEye, Microsoft, SolarWinds und CrowdStrike wird diese Sichtweise eben hier gestützt, neben natürlich den offiziellen US-Erklärungen, die wir eben schon erwähnt haben.
42:03: So, das schließt jetzt erstmal diesen Attribution-Teil ab. Ich möchte aber noch eine Kleinigkeit erwähnen, einfach auch damit wir es nicht ungesagt lassen. Und das ist, dass Mandia in seiner Aussage an einer Stelle auch davon gesprochen hat, dass das hier eine more portable attack ist. Und da fragt man sich natürlich, was heißt denn das überhaupt?
42:23: Möglicherweise meint er damit, dass es weitere Lieferanten gibt, die auf eine ähnliche Art und Weise kompromittiert wurden oder kompromittiert werden sollten. Das heißt also, wenn ich mir eine technische Möglichkeit schaffe, so einen Buildprozess zu manipulieren, dann muss das ja vielleicht nicht unbedingt nur eben gegen eine Software eingesetzt werden, sondern das kann ich quasi auch in einem anderen Kontext gegen eine andere Software nutzen, sofern ich das denn da auch schaffe, dann auf das Bildsystem eben zu kommen. Oder? Was meinst du?
42:56: Ja, genau. Also das ist auch die einzige Erklärung, die mir so in den Kopf gekommen ist, als ich den Begriff gehört habe.
43:02: Wir haben nichts gesehen bis heute, glaube ich. Oder sagen wir mal, es ist nichts bekannt über andere Umgebungen, wodurch ein ähnliches Tooling Malware initiiert wurde.
43:12: Es wäre natürlich jetzt durch ähnliches Tooling auch borderline impossible heutzutage. Also dieser Angriff, der war so erfolgreich, so medienwirksam, so groß. Also das ist jetzt was, das sollte jeder detecten, der irgendeine Form von Schutzsoftware einsetzt. Das Tooling, wie man so sagt, ist jetzt verbrannt, ist jetzt burnt. Aber vielleicht war es ursprünglich portable gedacht, also vielleicht war es ursprünglich, aber sollte es an mehreren Stellen eingesetzt werden.
43:37: Fazit
43:37: Wollen wir ein Fazit ziehen?
43:39: Genau, kommen wir zum Fazit. Die Russen waren es.
43:44: Wir haben signifikanten Impact gesehen, viele US-Ministerien kompromittiert, aber auch einige Schwergewichte in der Industrie, also an IT-Unternehmen, sogar in der Cybersecurity. Ich finde nach wie vor diese technische Vorgehensweise so interessant, dass man beobachtet, wann wird die Software gebaut, dann schnell den Source-Code austauscht oder einen Teil des Source-Codes austauscht und dann wieder zurücktauscht, wenn das erledigt ist. Das finde ich schon ganz cool nach wie vor. Und es hat ja auch funktioniert.
Fazit
44:16: Genau, das ist nicht nur cool, sondern auch gefährlich. Immer wenn ich über Supply Chain Compromises nachdenke, dann werde ich richtig traurig. Also, die halte ich für eine richtig schlimme Bedrohung. Und warum halte ich das für eine so schwere Bedrohung? Ich glaube, weil es so unfair ist. Also, ich kann jetzt irgendwie, klar, wenn irgendjemand seine Software nicht updatet und dann ist da eine Sicherheitslücke drin und dann werden sie kompromittiert, dann schreien alle, die hätten noch updaten sollen, die hätten noch updaten sollen. Und jetzt wird aber diese SolarWinds-Supply-Chain kompromittiert und die Updates liefern jetzt Malware aus. Das heißt, alle, die abgedatet haben, haben die Malware bekommen. Wie man es macht, macht man es verkehrt. Das ist irgendwie etwas, was sich beunruhigt. Also man könnte jetzt quasi Leuten empfehlen, nicht abzudaten. Und das, for the record, empfehle ich nicht.
45:06: Es ist ein Supply-Chain-Angriff, aber sicherlich nicht der einzige. Es ist eben nur einer, der sehr fatal war. Ein weiteres Beispiel für einen Supply-Chain-Angriff ist das MEDOC-Update, das eben für die Verbereitung von NotPetya im Jahr 2017 gesorgt hat. Da ging es auch darum, dass der Update-Mechanismus einer legitimen Software verwendet wird.
45:31: Hat sich auch um einen russischen Akteur gehandelt. Lustigerweise noch einem anderen Geheimdienst, nämlich der GRU, was wahrscheinlich Fancy Bear entspricht. Also vielleicht das einfach so ein Meta unter den russischen Diensten im Moment.
45:45: Lasst uns hören, wenn wir dazu auch mal eine Folge machen sollen.
45:48: Und noch eine Sache, die mir zu Supply Channel Tags auch immer wieder übel aufstößt. Es ist so schwer, sich dagegen zu wehren. Ich meine, was soll ich jetzt machen? Soll ich jedes Software-Update, das ich bekomme, einmal reverse-engineeren, um sicherzustellen, dass da jetzt keine Malware drin ist? Das funktioniert so nicht. Und man kann auch so wenig dafür, ja? Also Supply Chain Attacks sind ja nicht immer nur Updates von Software, die sind ja auch noch breiter. Also zum Beispiel gibt es auch Supply Chain Compromise oder Supply Chain Attacks, die zielen auf Software-Bibliotheken. Die wenigsten Software heutzutage sind kleine Programme, die für sich allein stehen. Die meiste Software, das ist so eine, stehen-auf-den-Schultern-von-Giganten-Situationen. Also die verwendet super viele andere Bibliotheken, super viele Sachen, die jemand anders schon gut und schnell und verlässlich gebaut hat und so weiter. Das heißt also, dass so eine Software tausende von anderen Libraries verwendet, ist nicht untypisch. Und einige dieser Libraries finden Verwendung, aber sind maintained von irgendeinem Typen in Darmstadt oder so, also von einer einzelnen Person irgendwo auf der Welt, die gar kein Geld dafür kriegt, das einfach nur zum Spaß macht und so und.
46:49: Grüße gehen raus an unsere Hörer in Darmstadt übrigens.
46:56: War nur eine zufällige Stadt. Ich habe keine Ahnung von irgendjemandem, der kritische Software in Darmstadt kompromittiert. Aber hey, schreibt uns doch auf Exo. Da haben wir etwa in dieser Folge besonders viel auf unsere Socials geachtet. Anyway, irgendeine dieser Bibliotheken muss ja nur kompromittiert werden, damit alle Software, die da drunter liegt, auch quasi kompromittiert wird. Ja, davon gibt es auch Fälle, die dokumentiert sind. Und das ist einfach fies. Ich meine, als Softwareentwickler muss ich jetzt von allen meinen Abhängigkeiten, die ja vielleicht noch Abhängigkeiten von Abhängigkeiten von Abhängigkeiten sind, bei jedem Update gucken, was hat sich da drin verändert und sicherstellen, dass dann irgendwo ein Malware dazukommt. Das funktioniert so nicht. Ich habe da so noch keine gute Lösung.
47:39: Bevor wir das abrunden, wollen wir noch einmal kurz, denn was mich immer wieder fasziniert, ist die Tatsache, wie lange die Vorbereitung oder insgesamt auch die Kompromittierung in diesen Fällen eigentlich dauert. Im Dezember 2020 ist das Ganze entdeckt worden. Und jetzt gehen wir mal zurück. Im Mai etwa begann die Hands-on-Activity, das heißt also etwa neun Monate geht man davon aus, insgesamt waren die Umgebungen da kompromittiert. Und wenn wir dann nochmal weiter zurückgucken, wann begannen eigentlich so die Vorbereitungen, dann geht man eben bis in den September 2019 zurück. Dieser ganze Zeitraum, in dem diese Melwehr sozusagen gewirkt hat oder in dem diese Akteure mit dieser Malware gewirkt haben, ist eben deutlich über ein Jahr. Und das macht immer auch ein bisschen Hoffnung, denn das bedeutet, man hat als Verteidiger eine Chance.
48:40: Wir freuen uns, wenn ihr bis hierhin dran geblieben seid und wenn ihr Ideen zu künftigen Folgen habt, dann könnt ihr uns erreichen, zum Beispiel per E-Mail unter info at armchairinvestigators.de,
48:53: oder über soziale Medien, zum Beispiel auf Mastodon, auf Infosec Exchange at armchairinvestigators oder auf X unter dem Handle at armchairgators.
49:08: Und wenn euch die Folge gefallen hat, dann hinterlasst uns gerne eine gute Bewertung in eurem Podcatcher. Das hilft anderen möglicherweise Interessierten dabei, unseren Podcast zu finden.
49:25: Damit möchten wir uns verabschieden. Ich wünsche einen schönen Tag, schönen Ende des Laufs und bis bald mal.
49:31: Vielen Dank und bis bald. Macht’s gut. Ciao.