Exchange: kritische Sicherheitslücke CVE-2022-41040 & CVE-2022-41082

Aktuell kursieren wieder zwei kritische Sicherheitslücke für Exchange (CVE-2022-41040 & CVE-2022-41082), welche es unter anderem Angreifern ermöglicht, Remote Code Execution auf den betroffenen Systemen auszuführen. Dadurch kann ein Exchange Server vollständig kompromittiert und übernommen werden. Auch vollständig gepatchte Systeme sind momentan davon betroffen. Seitens Microsoft gibt es noch keinen Patch, der dieses Problem behebt. Die gute Nachricht ist allerdings, dass sich der Angreifer zuerst erfolgreich authentifizieren muss. Somit ist das Angriffsspektrum etwas eingegrenzt. Es gibt aktuell auch einen Workaround. Dadurch lässt sich die schwerwiegendere der beiden Sicherheitslücke (CVE-2022-41040) schließen, ohne einen Patch bereitstellen zu müssen. Im folgenden Artikel zeige ich euch, wie man sich dagegen schützen kann.

Die Attack-Chain sieht nach Angaben von Microsoft wie folgt aus:

Durch das Ausnutzen beider Schwachstellen in Kombination mit bekannten Credentials, gelingt es Angreifern eine WebShell auf dem Exchange zu hinterlegen. Diese WebShell ermöglicht es den Angreifern schlussendlich das gesamte System und ggf. auch die gesamte Active Directory Domäne zu übernehmen.

Updates

• Update – 08.11.2022 – Es ist Patch-Tuesday und Microsoft hat nun offiziell ein Security Update bereitgestellt, welches die Lücke nachhaltig schließt.

Exchange Security Updates einspielen

Microsoft hat nun mit dem Patch-Tuesday im November nachgebessert und ein Security Update bereitgestellt. Das Update soll die Sicherheitslücke nachhaltig schließen. Für folgende Exchange Versionen steht der Patch bereit:

• Exchange Server 2013 CU23 (support ends in April 2023)
• Exchange Server 2016 CU22 and CU23
• Exchange Server 2019 CU11 and CU12

Der Patch kann dabei wie gewohnt über die Windows Updates installiert werden. Falls gewünscht, können die zuvor gesetzten IIS Rules wieder entfernt werden – notwendig ist dies seitens Microsoft aber nicht.

Remote Code Execution – CVE-2022-41040

Lücke automatisiert mittels Emergency Mitigation Service schließen

Mittlerweile hat Microsoft auch eine automatisierte Möglichkeit bereitgestellt, wie die IIS Rewrite Rule ohne Zutun eines Administrators gesetzt werden kann. Damit das automatisierte Setzen der Rule funktioniert, muss der „Exchange Server Emergency Mitigation Service“ aktiviert sein. Wenn der Service aktiviert ist, werden die IIS Einstellungen automatisch vorgenommen. Um zu überprüfen, ob das wie gewollt funktioniert hat, kann man folgende Checks via Management Shell durchführen.

### Check if Mitigation Service has been enabled for Organization
[PS] C:\Program Files\Microsoft\Exchange Server\V15\scripts>Get-OrganizationConfig | select MitigationsEnabled

MitigationsEnabled
------------------
              True


### Check if Mitigation Service has been enabled for Exchange Nodes
[PS] C:\Program Files\Microsoft\Exchange Server\V15\scripts>Get-ExchangeServer | select Name, Miti*

Name   MitigationsEnabled MitigationsApplied MitigationsBlocked
----   ------------------ ------------------ ------------------
EX0401               True {M1.1, PING1}

### Check already applied Mitigations
[PS] C:\Program Files\Microsoft\Exchange Server\V15\scripts>cd $exscripts
[PS] C:\Program Files\Microsoft\Exchange Server\V15\scripts>.\Get-Mitigations.ps1


Server      : EX0401
Version     : Version 15.2 (Build 1118.7)
ID          : M1.1
Type        : UrlRewrite
Description : Mitigation of CVE-2022-41040 via a URL Rewrite configuration.
Status      : Applied

Server      : EX0401
Version     : Version 15.2 (Build 1118.7)
ID          : PING1
Type        : Ping
Description : EEMS Heartbeat probe. Does not modify any exchange settings.
Status      : Applied

Außerdem kann man auch direkt in der IIS Verwaltungskonsole prüfen, ob die Regel erfolgreich gesetzt wurde.

Damit hat Microsoft das erste Mal den neuen Mitigation Service produktiv und sinnvoll verwendet. Da der Service standardmäßig aktiviert ist, dürften auch Organisationen, die nicht die notwendigen personellen Ressourcen besitzen, vor der Schwachstelle geschützt sein.

Lücke manuell mittels PowerShell Workaround schließen

Microsoft hat nun auch ein PowerShell Script bereitgestellt, welches auf jedem Exchange Node ausgeführt werden kann. Dabei wird die unten angeführte Rule automatisiert gesetzt. Als Administrator muss demnach nur das Script ausgeführt und anschließend die Regel überprüft werden. Gerade bei Firmen, die eine größere Anzahl an Exchange Nodes managen, ist das eine zeitsparende Alternative. Das Script ließe sich auch mittels einer Automatisierung (z.b. Ansible) ausrollen und aktivieren. Die PS1 könnt ihr direkt von Microsoft Github Repository herunterladen.

Lücke manuell mittels Workaround schließen

Mithilfe des Autodiscover-Endpunktes kann der Angreifer aus der Ferne Scripte am lokalen Exchange ausführen und so den gesamten Server kompromittieren. Da es hierzu noch keinen Patch gibt, müssen die Administratoren selbstständig darauf reagieren.

Öffnet am Exchange die IIS Verwaltungskonsole und wechselt auf Sites -> Default Web Site -> Autodiscover und wählt dort den Punkt „URL Rewrite“ aus.

Erstellt eine neue „Request Blocking“ Regel.

Verwendet als Pattern „.*autodiscover\.json.*Powershell.*“ und als Using „Regular Expression„.

Speichert die Regel und editiert anschließend die Condition. Bei der Condition muss das Feld Condition Input auf „{UrlDecode:{REQUEST_URI}}“ gesetzt werden.

Damit habt ihr die Sicherheitslücke bereits geschlossen. Laut Microsoft wird durch das Setzen der Regel kein weiterer Impact auf eure Exchange Umgebung entstehen (das kann ich soweit bestätigen). Falls ihr mehrere Exchange Server betreibt, müssen die oben aufgeführten Schritte natürlich auf jedem Node durchgeführt werden.

Solltet ihr noch einen Exchange 2013 auf Windows Server 2012R2 betreiben, so habt ihr das URL Rewrite Modul höchstwahrscheinlich noch nicht installiert. In diesem Fall empfiehlt Microsoft es nachträglich auf allen Nodes zu installieren. Den Downloadlink zum Modul findet ihr hier.

Somit haben wir bereits alle notwendigen Vorkehrungen getroffen, bis Microsoft einen entsprechenden Patch bereitstellt. Ein Neustart des Servers oder IIS ist dabei nicht notwendig. Die Änderungen werden automatisch angewendet.

Testen

Ein kurzer Test zeigt auch schon, ob diese Schritte bei euch korrekt ausgeführt worden sind und zum gewünschten Ergebnis geführt haben. Öffnet dazu eine PowerShell und führt folgenden Befehl aus:

PS C:\Users\kschweiger> Invoke-WebRequest https://mail.domain.com/autodiscover/autodiscover.json?@evil.com/powershell$Email=autodiscover/autodiscover.json%3f@evil.com 

Invoke-WebRequest : Der Remoteserver hat einen Fehler zurückgegeben: (403) Unzulässig.
In Zeile:1 Zeichen:1
+ Invoke-WebRequest https://mail.domain.com/autodiscover/autodis ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
   eption
    + FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand

Ersetzt dabei die „mail.domain.com“ mit eure Public Domain. Hierbei müsst ihr als Response eine „403 – Unauthorized“ zurückbekommen. Falls das der Fall ist, habt ihr euch erfolgreich gegen die Lücke geschützt.

Überprüfen

Nachdem die Lücke geschlossen wurde, sollte man auch noch prüfen, ob sie bereits aktiv ausgenutzt wurde. Dazu gibt es aktuell mehrere Ansätze, die ich im folgenden Absatz kurz beschreibe.

Führt folgenden PowerShell Befehl aus und prüft, ob ihr irgendwelche Resultate zurück geliefert bekommt:

Get-ChildItem -Recurse -Path "C:\inetpub\logs\LogFiles" -Filter "*.log" | Select-String -Pattern 'powershell.*autodiscover\.json.*\@.*200'

Falls ihr den oben genannten Test durchgeführt habt, müsste zumindest ein Eintrag zurück geliefert werden. Ist der Output leer, stehen die Chancen gut, dass ihr noch nicht davon betroffen wart.

Weiters wurden laut GTSC (Entdecker der Schwachstelle) auf den betroffenen Systemen folgende WebShells installiert:

Prüft also die Pfade und schaut, ob ihr dort entsprechende Files findet. Die Datei „RedirSuiteServiceProxy.aspx“ solltet ihr jedenfalls vorfinden, da diese vom Exchange verwendet wird. Da es sich hierbei grundsätzlich um eine legitime Datei handelt, müsst ihr zusätzlich noch den Hash überprüfen. Erst wenn der Hash mit jenem aus dem oben genannten Screenshot übereinstimmt, solltet ihr das Debugging weiterführen.

PowerShell Remoting – CVE-2022-41082

Die zweite Lücke bezieht sich dabei auf den Remote Powershell Endpunkt, welcher jeder Exchange innerhalb des Netzwerks bereitstellt. Dabei werden die Ports 5985 (HTTP), sowie 5986 (HTTPs) verwendet. Hier muss sichergestellt werden, dass diese zwei Ports niemals ins Internet oder andere Netze freigegeben werden. Da das unter normalen Umständen allerdings sowieso nicht der Fall ist, ist diese Lücke weitaus schwerer auszunutzen. Als Administrator kann man hierfür eine zusätzliche Windows Firewall Regel erstellen, welche den Zugriff auf die beiden genannten Ports entweder komplett einschränkt oder nur für bestimmte IPs zulässt.

Quellen

• Offizielle Aussage von Microsoft: Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange Server
• Analyse zur Schwachstelle von Microsoft: Analyzing attacks using the Exchange vulnerabilities CVE-2022-41040 and CVE-2022-41082
• Weitere Informationen: Warning: New attack campaign utilized a new 0-day RCE vulnerability on Microsoft Exchange Server