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.
Weitere Updates zu diesem Post aufklappen
  • Update – 06.10.2022 (09:05) – Microsoft hat nun auch offiziell bestätigt, dass die Condition auf „{UrlDecode:{REQUEST_URI}}“ angepasst werden muss. Der Mitigation Service, sowie das PowerShell Script wurden aktualisiert.
  • Update – 06.10.2022 (08:00) – Laut GTSC reichen die von Microsoft empfohlenen Einstellungen nicht aus, um die Sicherheitslücke vollständig zu schließen! Hierzu muss der Wert von „{REQUEST_URI}“ auf „{UrlDecode:{REQUEST_URI}}“ angepasst werden. Seitens Microsoft gibt es dazu noch keine offizielle Aussage, ich habe aber die Anleitung schon entsprechend den neuen Erkenntnissen angepasst. Wer zum jetzigen Zeitpunkt also das Script oder den Mitigation Service verwendet, bekommt dieses Update noch nicht automatisiert ausgeliefert.
  • Update – 05.10.2022 (10:00) – Das zuvor gesetzte Regex Pattern schließt die Schwachstelle nicht vollständig. Daher muss die Regel angepasst werden, um vollständig geschützt zu sein! Die Mitigation-Anleitung wurde entsprechend überarbeitet.
  • Update – 01.10.2022 (15:30) – Microsoft hat mittlerweile eine automatisierte Mitigation der Sicherheitslücken über den „Exchange Server Emergency Mitigation Service“. Administratoren, die den Service aktiv verwenden, bekommen die unten angeführte Rewrite-Rule automatisch gesetzt und müssen nicht manuell intervenieren. Wie man herausfindet, ob der Service korrekt funktioniert, kann man hier nachlesen.
  • Update – 01.10.2022 (09:45) – Weitere Details zur Attack-Chain sind bekannt.
  • Update – 01.10.2022 (08:30) – Microsoft empfiehlt mittlerweile, dass man die URL Rewrite Rules nicht mehr im „Autodiscover“ Verzeichnis setzt, sondern für die gesamte „Default Web Site“ Site. Ob das wirklich notwendig ist oder ob es sich hierbei um eine reine Vorsichtsmaßnahme handelt, ist leider nicht bekannt. Somit unterscheiden sich zum jetzigen Zeitpunkt die Mitigation-Empfehlungen von Microsoft und GTSC.
  • Update – 31.09.2022 – Wer noch Exchange 2013 auf Windows Server 2012R2 betreibt, muss das URL Rewrite Modul zuerst installieren. Hier geht es zum Download.

 

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:

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.

Microsoft empfiehlt mittlerweile die nachfolgenden Schritte nicht mehr im „Autodiscover“ Verzeichnis, sondern direkt unter der „Default Web Site“ auszuführen.

Ö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.

Solltet ihr eine Exchange DAG betreiben, dürft ihr keinesfalls die Remote Powershell Ports vollständig sperren! Dies würde die Funktionalität des DAGs beeinflussen.

Quellen

You may also like...

Abonnieren
Benachrichtige mich bei
guest
0 Comments
Inline Feedbacks
View all comments
0
Hinterlass' doch deine Meinung zu diesem Artikelx