Microsoft Exchange - doppelter Zero-Day gemeldet

Am Freitag, den 30. September 2022 sind zwei Zero-Day-Sicherheitslücken in Microsoft Exchange bekannt geworden. Diese können miteinander verkettet werden. Dabei wird die erste Lücke genutzt, um genug Freiraum zu schaffen, damit die zweite ausgenutzt werden kann. Als Folge daraus ist es Angreifern potentiell möglich, eine Remote-Code-Execution auf dem Exchange Server auszuführen.

Microsoft hat auf die Schnelle eine offizielle Anleitung über diese Schwachstellen herausgegeben, welche die Situation wie folgt zusammenfasst:

  • Microsoft untersucht derzeit zwei berichtete Zero-Day-Schwachstellen, welche Microsoft Exchange Server 2013, 2016 und 2019 betreffen.
  • Bei der ersten Schwachstelle, CVE-2022-41040, handelt es sich um eine Server-Side Request Forgery (SSRF) Schwachstelle.
  • Die zweite Schwachstelle, CVE-2022-41082, erlaubt Remote Code Execution (RCE), wenn Power Shell für den Angreifer zugänglich ist.
  • Zum jetzigen Zeitpunkt ist Microsoft bekannt, das einige gezielte Angriffe mithilfe dieser zwei Schwachstellen durchgeführt wurden, um in die Systeme von Anwendern zu gelangen. In diesen Angriffen kann CVE-2022-41040 von einem authentifizierten Angreifer genutzt werden, um aus der Ferne CVE-2022-41082 auszunutzen. Für eine Ausnutzung der Schwachstellen ist authentifizierter Zugang zu dem anfälligen Microsoft Exchange Server erforderlich.

 

So schlecht diese Nachricht sein mag, gibt es zumindest zwei Hoffnungsschimmer:

Der Fehler kann nicht von jedem ausgelöst werden. Jeder Remote User der sich bereits über das Internet eingeloggt hat und dessen Computer bereits mit Malware infiziert ist, kann in der Theorie seinen Account durch einen Angreifer kompromittiert bekommen,  um diese Schwachstellen auszunutzen. Den Exchange allerdings nur über das Internet verfügbar zu haben, ist nicht genug, um als Angriffsziel zu dienen, da eine sogenannte Unauthenticated Invocation der Schwachstellen nicht möglich ist.

Blockieren von PowerShell Remoting schränkt die Attacken ein. Microsoft zufolge kann das Blockieren der TCP Ports 5985 und 5986 auf dem Exchange Server die Angreifer bei der Verkettung der ersten Schwachstelle mit der Zweiten einschränken (aber das Verhalten nicht unterbinden). Obwohl Angriffe ohne PowerShell Kommandos denkbar sind, scheinen die bisherigen Berichte darauf hinzudeuten, das PowerShell ausführen ein notwendiger Teil des Angriffs ist. 

Erinnerungen an ProxyShell

Wenn Sie dieser Angriff an die ProxyShell Schwachstelle vom letzten Jahr erinnert, so sind Sie mit diesem Gedanken nicht allein. Die GTSC, die vietnamnesische Cybersecurity-Firma, welche die Schwachstellen zuerst untersucht und gemeldet hat, sprach davon das Forscher Exploit Anfragen in IIS Logs entdeckt haben, welche das selbe Format haben, wie die ProxyShell Schwachstelle. Beachtenswert ist, dass die Art von Threat-Hunting Query welche Sophos empfohlen hat um ProxyShell Exploit Anzeichen zu finden auch für diese neuen Zero-Days eingesetzt werden kan. 

               SELECT grep.*

               FROM file

               CROSS JOIN grep ON (grep.path = file.path)

               WHERE

               file.path LIKE `C:\inetpub\logs\LogFiles\W3SVC%\u_ex210[89]%`

               AND grep.pattern = `autodiscover.json`

Microsoft merkt ebenfalls an, dass "(die Erkennung, die wir) in Reaktion zu ProxyShell erstellt haben, kann auch für Anfragen genutzt werden, da es Ähnlichkeiten in der Funktion mit dieser Bedrohung gibt." Derzeit ist allerdings nicht bekannt, ob ein Ausnutzen der Schwachstelle möglich ist, ohne diese speziellen Überbleibsel in den Logs zu hinterlassen. Anders gesagt: Finden Sie Anzeichen ähnlich denen, die von PowerShell Exploits hinterlassen werden, dann haben Sie wahrscheinlich Beweise, dass ein Angriff stattgefunden hat, ein Fehlen dieser Anzeichen muss jedoch nicht heißen, dass kein Angriff stattgefunden hat. In den untersuchten Angriffen nutzten die Angreifer ihre unauthorisierten RCE-Möglichkeiten, der GTSC zufolge, um eine ganze Reihe an Follow-on-Malware einzuschleusen und auszuführen.

Unter anderem:

Webshells um ein Web-basiertes Backdoor für späteren Gebrauch zu erzeugen: Webshells erlauben typischerweise Nachfolgeangriffe um beliebige Systembefehle mit beliebigen Parametern so aussehen zu lassen wie reguläre HTTP-Anfragen. Die Webshell führt im Anschluss den gewünschten Befehl mit den Rechten des Webservers selbst aus.

Malware zum Dumpen von Anmeldeinformation: Software zum Stehlen von Zugangsdaten sucht typischerweise auf der Disk und im Arbeitsspeicher (bei ausreichenden Rechten) nach Klartext-Passwörtern, Sitzungs-Cookies und Authentifizierungstokens, welche für Lateral Movement auf andere Computer im Netzwerk genutzt werden könnten.

Zombie Malware in der Form von DLLs die in legitim-aussehende Prozesse geladen werden: Eine DLL-Probe die GTSC-Forscher analysiert haben, konnte aus der Ferne mit verschlüsselten Instruktionen versorgt werden um Systeminformationen zu dumpen, beliebige Befehle auszuführen C# Module zu starten und Dateien und Ordner auf dem infizierten System zu verändern. 

Was können Sie tun?

So können Sie das Schadenspotenzial geringhalten:

Blocken Sie PowerShell Remoting um das Risiko von RCE zu reduzieren. Wie bereits erwähnt, das Blockieren von TCP-Ports 5985 und 5986 limitiert die möglichen Angriffsmuster gegen Ihren Exchange Server, laut Aussagen von Microsoft.

Nutzen Sie eine URL Rewrite Rule, um unbekannte Angriffsauslöser zu blockieren. GTSC und Microsoft bieten Erklärungen, wie IIS Server URL Rewriting genutzt werden kann, um die häufigsten Formen dieser Angriffe zu erkennen und zu neutralisieren.

Stellen Sie sicher, dass die verhaltensbasierte Endpoint Threat Detection ativiert ist, auch auf Servern. Wie oben bereits erwähnt, berichtet GTSC, dass Angriffe WebShells und Malware DLLs einschleusen, mit deren Hilfe beliebige Befehle, ausgeführt, Dateien manpuliert und Systeminformationen extrahiert werden können. Dadurch erhalten Sie allerdings zahlreiche potenzielle Anhaltspunkte für Detection-and-Response, um einen erfolgten Angriff zu unterbinden.

Ziehen Sie in Betracht, Ihre eingeloggten Email-Benutzer zu deauthentifizieren. Sind Sie in der Lage eine Endpoint-Sicherheitsanalyse auf jedem Gerät durchzuführen, bevor sich die Benutzer reauthentifizieren, minimieren (aber nicht eliminieren) Sie das Risiko, dass bereits infizierte Geräte für die Ausnutzung dieser Schwachstellen missbraucht werden. Zusätzlich reduzieren Sie die Angriffsfläche, wenn Sie Benutzer, die nicht eingeloogt sein müssen, oder nicht einmal wissen, dass Sie eingeloggt sind, einfach deauthentifizieren.

Spielen Sie verfügbare Patches so zeitnah wie möglich ein. Bis jetzt wurde nur eine begrenzte Zahl an Angriffen erfasst, davon die meisten in Südost-Asien und die GTSC hält bewusst Informationen zu den Schwachstellen zurück, bis entsprechende Patches verfügbar sind.

Behalten Sie im Hinterkopf, dass Angreifer mithilfe der Patches Rückschlüsse auf den Exploit ziehen können, um Ziele, die die Patches nicht eingespielt haben, attackieren zu können.

Zusammengefasst:

Die Tipps und Techniken, die Sie zum Aufspüren von ProxyShell-Angriffen gelernt haben, werden ihnen auch hier sehr wahrscheinlich eine Hilfe sein.

Trotz der Ähnlichkeiten handelt es sich bei diesen Schwachstellen NICHT um ProxyShell, die ProxyShell-Patches werden Angriffe gegen diese Schwachstellen also nicht unterbinden.

Wenn die Patches für diese Schwachstellen veröffentlicht werden, gehen Sie davon aus, dass diese reverse-engineered werden, um ungepatchte Systeme anzugreifen.

Als unser Kunde stehen wir Ihnen sehr gerne für Fragen rund um Sophos zur Verfügung. Da wir auf Sophos spezialisiert sind, können wir ggf. noch offene Rückfragen mit Sicherheit gut beantworten. Bitte zögern Sie nicht, uns zu kontaktieren (service@utm-shop.de - 0351-81077-50), wir freuen uns auf die weitere Zusammenarbeit mit Ihnen. Sollten Sie Hilfe benötigen, können Sie gern ein Ticket in unserem Support Portal https://support.utm-shop.de/ erstellen.