MOVEit SQLi Zero-Day (CVE-2023-34362) wird von der Ransomware-Gruppe CL0P ausgenutzt
von Ori David, Sam Tinklenberg, Maxim Zavodchik und Ophir Harpaz
Zusammenfassung
Am 31. Mai 2023 warnte Progress Software Kunden erstmals vor einer bisher unbekannten Sicherheitslücke in MOVEit Transfer- und MOVEit Cloud-Software. Die Schwachstelle bezüglich SQL Injection (SQLi), die die Kennung CVE-2023-34362 erhielt, wurde von Angreifern aktiv ausgenutzt.
Einem Bericht von Mandiant zufolge wurden bereits am 27. Mai 2023 Versuche erkannt, diese Schwachstelle auszunutzen. Am selben Tag entdeckten Forscher von Akamai einen versuchten Angriff gegen einen der Finanzkunden von Akamai. Der Angriff wurde von der Akamai Adaptive Security Engine blockiert.
Die Angriffskampagne wurde einer Ransomware-Gruppe namens CL0P zugeschrieben. Die Gruppe, die vermutlich von Russland oder Osteuropa aus operiert, verfolgt finanzielle Ziele und erpresst ihre Opfer durch Datenextraktion.
Angreifer haben die SQLi-Schwachstelle ausgenutzt und eine nutzerdefinierte ASP.NET-Webshell (LEMURLOOT) implementiert, um Persistenz in den Netzwerken der Opfer zu erreichen und weitere Angriffe zu ermöglichen.
Zum Zeitpunkt der Erstellung dieses Artikels sind die vollständigen Exploit-Details nicht öffentlich zugänglich. Die Analysen der Akamai Security Intelligence Group und die Ergebnisse der Zusammenarbeit mit dem Sicherheitsteam von Progress zeigen jedoch, dass die Adaptive Security Engine unsere Kunden vor Angriffsversuchen geschützt hat.
Zeitachse
Am 31. Mai 2023 veröffentlichte Progress Software eine Empfehlung und warnte seine Kunden erstmals vor einer Zero-Day-Schwachstelle in MOVEit Transfer und MOVEit Cloud. Diese wurde von Angreifern aktiv ausgenutzt, um mit dem Internet verbundene Server zu infizieren (Abbildung 1).
Diese Warnung erfolgte nach der Identifizierung einer massiven Exploit-Kampagne, die diese Sicherheitslücke ausnutzte, um sensible Dateien zu extrahieren, die auf anfälligen Servern gespeichert waren. Laut Mandiant wurden bereits am 27. Mai 2023 versuchte Angriffe auf die Schwachstelle festgestellt. Huntress führte eine technische Analyse der Schwachstelle durch und zeigte, dass die Sicherheitslücke eine vollständige Remote-Ausführung von Code auf dem Server ermöglicht.
Microsoft schrieb diesen Angriff am 2. Juni 2023 offiziell der Lace Tempest Group zu. Diese Einschätzung bestätigte sich endgültig am 5. Juni, als CL0P in ihrem Blog eine Erklärung zu dieser Kampagne veröffentlichte (Abbildung 2).
Umfang der Angriffe
Zu dem Zeitpunkt, als der Angriff bereits bekannt war und untersucht wurde, identifizierte Shodan etwa 2.500 internetbasierte Server, auf denen MOVEit ausgeführt wurde (Abbildung 3).
Progress Software gab an, dass alle Server, auf denen MOVEit ausgeführt wird, gefährdet seien und zum Zeitpunkt des massiven Angriffs kein Patch vorhanden war. Daher ist davon auszugehen, dass die Anzahl der Opfer beträchtlich ist. Mehrere Organisationen wurden bereits als Opfer von Angriffen bestätigt, und viele weitere werden wahrscheinlich in den nächsten Tagen bekannt werden.
Exploit-Kette
Zu der Sicherheitslücke wurden viele Informationen veröffentlicht. Die vollständigen Details zu den Exploits sind jedoch noch nicht bekannt. Basierend auf öffentlichen Informationen, Analysen der Akamai Security Intelligence Group und den Daten in unseren Protokollen haben wir ein klares Bild davon, wie moveitisapi.dll zur Ausführung von SQLi verwendet wird.
Außerdem traf sich unser Team mit dem Sicherheitsteam von Progress zu einem Informationsaustausch, in dem wir unsere Analyse und andere Informationen zu IOCs (Indicators of Compromise) weitergaben. Auf der Grundlage dieses Treffens können wir bestätigen, dass die Adaptive Security Engine von Akamai unsere gemeinsamen Kunden vor einem solchen Angriff geschützt hat und weiterhin schützt.
Wir werden weitere Details zu unserer Analyse und Exploit-Kette veröffentlichen, sobald ausreichend Zeit für ein Patching vergangen ist.
Kaschieren der Operation
Die CL0P-Gruppe ergriff verschiedene Maßnahmen, um unentdeckt zu bleiben und die Analyse zu erschweren.
Erstens war der Name der hochgeladenen Webshell „human2.aspx“, was stark der legitimen MOVEit-Datei zur Implementierung der Web-Schnittstelle ähnelt: „Human.aspx“.
Zweitens musste für den Zugriff auf die Webshell ein Passwort über den „X-siLock-Comment“-Header übermittelt werden. Wenn der Header fehlte oder das Kennwort falsch war, gab die Webshell die Antwort 404 „Not Found“ zurück. Häufig besteht die einfachste Möglichkeit, eine Webshell zu finden, im Senden einer einfachen GET-Anfrage. Wenn die Seite nicht existiert, wird eine 404-Meldung zurückgegeben. Wenn die Webshell eine 404 zurückgibt, wird nur die einfachste Form der Erkennung verhindert. Mit einigen zusätzlichen Schritten können Sie die 404-Antwort der Webshell mit der normalen 404-Antwort des Servers vergleichen und den Unterschied zwischen den beiden Antworten erkennen.
Drittens wurden in den Headern, die zur Steuerung der Webshell und zum Senden von Exploits verwendet wurden, Namen verwendet, die den ursprünglichen MOVEits-Headernamen sehr ähnlich sind. So wird beispielsweise „X-siLock-Comment“ zur Übertragung des Webshell-Passworts verwendet. Weitere Informationen aus der MOVEit-Datenbank wurden über ähnlich benannte Header extrahiert: „X-siLock-Step2“ und „X-siLock-Step3“.
Erkennung von Angriffen
Exploit-Versuche können auf verschiedene Weise identifiziert werden.
Bekannte IOCs (Indicators of Compromise)
Progress Software und die Sicherheits-Community haben viele host- und netzwerkbasierte IOCs veröffentlicht, unter anderem IP-Adressen, Datei-Hashes und YARA-Regeln.
Netzwerkadministratoren können Netzwerk-Traffic und IIS-Protokolle überprüfen und Assets im Netzwerk scannen, um bekannte IOCs zu finden und so ausgenutzte Geräte zu identifizieren.
Kunden der Adaptive Security Engine können ihre WAF-Protokolle auf Anzeichen von Ausnutzung überprüfen. Wenn ihre MOVEit-Hosts angegriffen wurden, sollten sie SQLi-Angriffsgruppen-Trigger sehen, die auf „/moveitisapi/moveitisapi.dll“ abzielen.
Threat Hunting
Server, auf denen die anfällige Software ausgeführt wird, sollten untersucht und auf ungewöhnliches Verhalten überprüft werden, selbst wenn keine bekannten IOCs auf ihnen erkannt wurden. Nach der Überprüfung der Payload, die die Angreifer verwendet haben, sehen wir beispielsweise, dass im Stammverzeichnis des Servers unter dem folgendem Pfad eine aspx-Webshell abgelegt wurde: <DriveLetter>: \MOVEitTransfer\wwwroot\. Der Name der in der ursprünglichen Angriffskampagne eingesetzten Webshell lautete human2.aspx, doch diese Bezeichnung könnte sich leicht ändern.
Anstatt sich nur auf statische IOCs zu verlassen, empfehlen wir die Verwendung von anomaliebasierten Methoden zur Bedrohungssuche auf anfälligen Servern. In diesem speziellen Fall könnte ein Ansatz sein, das Stammverzeichnis des MOVEit-Servers zu überprüfen, um kürzlich erstellte aspx-Dateien zu finden. Aspx-Dateien sind relativ statisch und werden normalerweise nicht geändert oder erstellt. Daher könnte eine Neuhinzufügung verdächtig sein und sollte untersucht werden. Weitere verdächtige Dateipfade wurden in den ersten Hinweisen von Progress und in einer aktuellen #StopRansomware-Empfehlung von CISA veröffentlicht.
Kunden von Akamai Guardicore Segmentation können die in Abbildung 4 dargestellte Insight-Abfrage verwenden, um solche Dateien zu finden.
Beachten Sie, dass der Laufwerksbuchstabe (C:\) und der Installationspfad variieren können. Diese Abfrage deckt nur den Standardinstallationspfad ab.
Akamai Hunt – der Managed Threat Hunting Service von Akamai – hat die Umgebungen von Kunden gründlich gescannt, um anfällige Assets, Exploitversuche und mit der Angriffskampagne verknüpfte IOCs zu erkennen. In Fällen, in denen MOVEit-Komponenten gefunden wurden, informierten die Forscher von Hunt die relevanten Teams und halfen bei der unmittelbaren Bedrohungsabwehr (Abbildung 5).
Abwehr
Leider sind Software-Schwachstellen unvermeidlich, aber Unternehmen können viel tun, um sich vor dieser Art von Angriffen zu schützen.
Server mit Internetzugriff erfassen
Um Angriffe abwehren zu können, müssen Verteidiger zunächst feststellen, welche sensiblen internetbasierten Anwendungen sie ausführen. Im MOVEit-Fall wurden alle gefährdeten Kunden von Progress über die Schwachstelle informiert. Dennoch ist es wichtig, sich der Angriffsfläche für Attacken von außen bewusst zu sein und alle sensiblen Anwendungen zu identifizieren, die mit dem Internet Kontakt haben. Sobald Sie diese Anwendungen identifiziert haben, können die folgenden Abwehrschritte das Gefährdungsrisiko für die Anwendungen minimieren.
Internetzugang beschränken
Die Reduzierung der Angriffsfläche sollte oberste Priorität haben. Wenn es keinen triftigen Grund für einen nicht autorisierten Internetzugriff auf eine Anwendung gibt, sollte die Anwendung durch nutzerbasierte Zugriffskontrollen geschützt werden. Dies ist über ZTNA (Zero Trust Network Access) oder mit herkömmlichen VPN-Produkten möglich.
Wenn für einige Anwendungsfälle ein nicht autorisierter Internetzugang erforderlich ist, empfehlen wir, einen separaten externen Anwendungsserver auszuführen, die darauf gespeicherten oder von ihm aus zugänglichen Daten einzuschränken und sie so weit wie möglich aus dem internen Netzwerk zu segmentieren. Auf diese Weise wäre der Auswirkungsradius selbst bei einem Angriff auf den Anwendungsserver begrenzt.
Angriffe mit einer WAF blockieren
Anwendungen mit Webschnittstellen sollten hinter einer WAF platziert werden, da diese ungewöhnliche und verdächtige Anfragen blockieren und die Ausnutzung bisher unbekannter Zero-Day-Schwachstellen blockieren kann.
Nach unserem derzeitigen Erkenntnisstand hinsichtlich der Exploit-Kette bietet die Akamai Adaptive Security Engine Schutz vor einem solchen Angriff mit der SQLi-Angriffsgruppe. Insbesondere haben wir Fälle identifiziert, in denen die Adaptive Security Engine Angreifer daran gehindert hat, die SQLi-Schwachstelle auszunutzen. Die blockierten Anfragen stammten von den IPs, die in den bekannten IOCs aufgeführt sind.
Laterale Netzwerkbewegung mit Segmentierung verhindern
Server mit Internetkontakt sind oft der Einstiegspunkt für Angreifer in das Netzwerk. Daher sollten diese Server entsprechend behandelt und in einem separaten Segment gehalten werden, was die Fähigkeit des Angreifers, laterale Bewegungen innerhalb des Netzwerks durchzuführen, einschränkt.
So kann zum Beispiel eine Regel erstellt werden, alle ausgehenden Verbindungen von Servern mit Internetzugriff über Verwaltungsports zu blockieren (Abbildung 6).
Wenn ein Angreifer in diesen Server eindringt, ist es unmöglich, laterale Netzwerkbewegungen über diese Ports durchzuführen. Es sollten zusätzliche Regeln für sensible Anwendungen und andere Verwaltungsports erstellt werden, um die Angriffsfläche dieser Server so weit wie möglich zu begrenzen. Beachten Sie, dass solche Regeln auch den normalen Netzwerkbetrieb unterbrechen können. Daher sollten Sie beim Erstellen der Regeln und beim Hinzufügen von Ausschlüssen zum vorhandenen, für den täglichen Betrieb erforderlichen Traffic, mit Umsicht vorgehen.
Bis zum nächsten Mal?
MOVEit ist ein weiterer Fall eines Angriffs auf die Zero-Day-Sicherheitslücke eines MFT-Service (Managed File Transfer). Mittlerweile ist die Ransomware-Gruppe CL0P für diese Art von Aktivität berüchtigt. Zuvor attackierte sie bereits Schwachstellen in den Anwendungen GoAnywhere, SolarWinds Serv-U und Accellion, um Daten zu stehlen und ihre Opfer zu erpressen. Die Gruppe nutzte auch noch Sicherheitslücken in anderen Anwendungen mit Internetkontakt aus.
Sollte eine der führenden MFT-Lösungen in Ihrem Netzwerk installiert sein, können Sie davon ausgehen, dass in diesem Moment, in dem Sie diesen Satz lesen, irgendwo auf der Welt ein hochqualifizierter und motivierter Hacker diese Anwendungen studiert und versucht, ihre Sicherheitslücken zu finden. Es ist nur eine Frage der Zeit, bis die CL0P-Gruppe wieder eine neue Angriffsserie startet, und weitere Gruppen werden ihr vermutlich bald folgen.