In einer Aufsehen erregenden Angriffswelle wurden im März 2021 aufgrund einer Sicherheitslücke im Microsoft Exchange Server weltweit zehntausende E-Mail-Server Opfer von Cyberattacken.
| INHALT |
Die Schwachstellen hatte in dem sogenannten Zero-Day-Exploit eine bisher unbekannte chinesischen Spionagegruppe mit dem Namen „Hafnium“ ausgenutzt. Auch das Bundesamt für Sicherheit in der Informationstechnik (BSI) ermahnte daraufhin tausende deutsche Unternehmen, die Lücke in selbst betriebenen Exchange Servern schnell zu schließen. Microsoft hatte kurz nach Entdeckung der Sicherheitslücke Patches veröffentlicht, die die Schwachstellen in Exchange-Servern behoben haben.
Wir klären in diesem Beitrag den zeitlichen Vorgang auf: Was war passiert und hätte man die Angriffe verhindern können?
Folgendes haben wir anhand eines DriveLock Testsystems recherchiert; der zeitliche Ablauf konnte bei vielen Unternehmen beobachtet werden:
Das wäre eigentlich einfach gewesen, handelt es sich doch nur um eine einzige Datei (Webshell), die in einem Verzeichnis des Exchange-Servers liegt.
Besonders in der Tagespresse las man, dass die Administratoren der betroffenen Systeme die verfügbaren Patches nur rechtzeitig hätten einspielen müssen, um den Angriff zu verhindern. Bei anderen Angriffen mag das stimmen, aber nicht bei dieser Welle:
Selbst, wer unmittelbar nach Veröffentlichung des Patches diesen eingespielt hatte, ist vermutlich bereits Opfer des Angriffes gewesen. Und da man davon ausgehen muss, dass einfach systematisch alle ip-Adressen im World Wide Web gescannt wurden, ist potenziell jeder Exchange-Server auch angegriffen worden.
Wenn man den Ablauf der Aktion aus Sicht der Kriminellen betrachtet, war das Ganze vom Timing her wirklich clever organisiert: Die Microsoft Exchange Server Hacker scannen einmal das gesamte Internet (ca. 4,3 Mrd. IP-Adressen) und hinterlassen auf jedem Server die genannte Webshell. Das klingt zunächst nach einem großen Aufwand. Aber wenn man sich bei einem der großen Cloud-Anbieter beispielsweise 255 virtuelle Maschinen mietet, dann verbleiben pro Maschine nur noch ca. 17 Mio. zu scannende IP-Adressen. Wer so in drei Tagen das ganze Internet „abarbeiten“ will, muss dann rund 66 IP-Adressen pro Sekunde schaffen. Das ist ziemlich leicht machbar. Mit der günstigsten virtuellen Maschine kostet das rund 400 €.
Der Scan muss jedenfalls beendet sein, bevor richtig Notiz von der Angriffswelle genommen wird. Denn wissen die Administratoren erstmal von der Gefahr und werden aktiv, sind die Einfallstore schnell geschlossen. Daher haben die Hacker ja neben dem eigentlichen Zero-Day-Exploit ein weiteres Einfallstor aufgesperrt, die Webshell. Es gab also insgesamt drei Angriffspunkte:
1. Zero-Day-Exploit
2. Webshell (erste Backdoor)
3. Zweite Backdoor
Beim Verteilen der Webshell hat die Hackergruppe eine Datenbank mit der Information erstellt, unter welchen IP-Adressen überhaupt ein Exchange-Server erreichbar ist.
Das macht den nächsten Schritt viel leichter: Nicht jedes System hat interessante Daten und ist deshalb relevant.
Damit eine Unterscheidung nach interessanten und irrelevanten Systemen getroffen werden kann, sind noch mehr Informationen nötig. Diese müssen auch automatisiert eingesammelt werden, denn noch sind es zu viele Server. Daher generierten die Kriminellen mit Windows-Bordmitteln (mittels hinterlassener Webshell) ein Systeminventar und sammelten diese Informationen ein. Nachdem die Angreifer damit rechnen mussten, dass ihre Angriffswelle mittlerweile entdeckt worden war, mussten sie das Inventar unmittelbar nach beendetem Scan fertigstellen – während die halbe Administratoren-Welt gerade in Panik Patches verteilte. Nun müssen sich die Hacker etwas beeilen, denn sie müssen mit dem gesammelten Inventar noch die interessanten Systeme finden und diese noch „richtig“ angreifen, bevor das zweite Einfallstor (Webshell) entdeckt wird. Die eigentlichen Angriffe könnten zum Beispiel Memory Dumps von Authentifizierungs-Datenbanken (LSASS) gewesen sein, in denen z.B. Passwörter liegen.
Und nun kommen wir zum Thema „Kochen mit Wasser“:
Der zeitliche Ablauf war gut, die Webshell aber war ausbaufähig. Diese war nämlich immer die Gleiche und damit von einem Virenscanner (auch als „Blacklisting“ bekannt) leicht erkennbar.
Man kann diese auch noch „personalisieren“, dann wird es sehr schwierig, sie im Blacklisting automatisch zu erkennen. Der kriminelle Angreifer kann Dateien, die er automatisch über die Webshell generiert und später heruntergeladen hat, auch über die Webshell wieder löschen – dann wird es sehr schwierig zu identifizieren, ob überhaupt ein Angriff stattgefunden hat. Zusammengefasst: Der Angriff hätte besser sein können und quasi unbemerkt durchgeführt werden können.
Es ist wie bei vielen Angriffen in der Vergangenheit: Wäre auf den Servern ein Whitelisting-Produkt (z.B. DriveLock Application Control) gelaufen, hätte der Exchange-Server nur die Skripte ausgeführt, die von Microsoft geliefert wurden. Dann hätte es zwar die Lücke im Exchange Server gegeben. Die Webshell-Datei kann jedoch nur abgelegt, nicht aber ausgeführt werden, weil sie nicht auf der Whitelist steht. Somit wird bei versuchter Ausführung der Zugriff blockiert.
Betrachten wir, was die Angreifer bei interessanten Systemen danach noch gemacht haben, beispielsweise Speicherabzüge von der Benutzerdatenbank des Betriebssystems (erstellt mit einem Tool von Microsoft) oder die Erstellung eines Archivs mit Daten (mit Hilfe eines Komprimierungsprogramms). Auch dies lässt sich sehr leicht durch Applikationskontrolle verhindern. Denn diese Tools wurden erst bei der Exchange Server-Attacke auf die Rechner jeweils aufgebracht und anschließend ausgeführt. Sie standen also nicht auf der Whitelist.
Die nächste Sicherheitslücke kommt bestimmt. Nehmen wir einmal an, es agiert diesmal jemand, der sich ein bisschen mehr Mühe gibt: Er personalisiert die Webshell, sodass sie vom Antivirusprogramm auch per Heuristik nicht leicht erkannt wird. Dies gibt dem Angreifer viel mehr Zeit, bis er entdeckt wird.
Die Angreifer löschen dieses Mal ihre Hinterlassenschaften/Backdoors wieder, nachdem sie die Daten heruntergeladen haben. Und sie löschen dieses Mal auch alle Logdateien. Einziges Indiz auf einen Angriff sind (nicht mehr vorhandene) Logs. Es gibt dann keine Möglichkeit mehr herauszufinden, was genau heruntergeladen wurde und was vor allem evtl. an zusätzlichen Backdoors geschaffen wurde. Und vielleicht werden diese Schlupflöcher auch erst in einem Jahr ausgenutzt. Dann muss das betroffene Unternehmen nach dem Angriff im Grunde seine gesamte Infrastruktur neu installieren, um sicherzugehen, dass sie keine Schlupflöcher übersehen haben. Das bedeutet einen hohen Kostenaufwand.
Applikationskontrolle mit Application Whitelisting verhindert solche Worst Case-Szenarien. Viele Unternehmen lehnen aber Application Whitelisting immer noch ab und befürchten einen hohen administrativen Aufwand. Der manuelle Aufwand lässt sich jedoch reduzieren. Predictive Whitelisting sorgt dafür, dass die Whitelist selbstständig dazulernt und das System trotzdem sicher bleibt: Zum Zeitpunkt der DriveLock Installation wird das System „versiegelt“. Ab dann gibt es nur noch definierte und konfigurierte Wege, wie Änderungen an der Whitelist selbstlernend vorgenommen werden. Das automatisierte Lernen der Whitelist gewährleistet stets den Sicherheitsstandard und reduziert den Pflegeaufwand.
Es stellt sich die grundsätzliche Frage nach diesem Angriff:
Ist der Aufwand für Application Whitelisting wirklich höher als die Aufklärungsarbeit, was im Zusammenhang mit diesem Hack alles passiert ist?