Exchange Server Zero-Day Schwachstelle wird aktiv ausgenutzt

by

Aktuell wird eine Zero-Day Schwachstelle in Exchange Server 2013, 2016 und 109 aktiv ausgenutzt. Aktuell gibt es noch kein Sicherheitsupdate für die folgenden Schwachstellen:

  • CVE-2022-41040
  • CVE-2022-41082

Es gibt aber Abhilfe um einen erfolgreichen Angriff zu vermeiden. Um die Ausnutzung der Schwachstelle zu verhindern, kann eine Regel für das Feature URL Rewrite erstellt werden. Dazu wird im IIS Manager zunächst das Autodiscover Verzeichnis der Default Web Site ausgewählt:

Exchange Server Zero-Day Schwachstelle wird aktiv ausgenutzt

Unter dem Punkt „Add Rules…“ kann dann eine neue Regel erstellt werden:

URL Rewrite Regel

Als Vorlage muss „Request blocking“ ausgewählt werden:

Request Blocking

Im Feld „Pattern (URL Path“ wird nun der folgende String eingegeben:

(?=.*autodiscover)(?=.*powershell)

Hinweis: Das Pattern wurde in letzter Zeit mehrfach durch Microsoft angepasst.

Das Feld „Using“ muss von „Wildcard“ auf „Regular Expressions“ umgestellt werden:

Die neu hinzugefügte Regel wird nun aufgeklappt und bearbeitet;

Rewrite Rule

Im Feld „Condition input“ wird nun {URI} zu {REQUEST_URI} geändert:

Rewrite Rule

Die Regel ist nun fertig und verhindert den aktuellen Angriff. Sobald ein Sicherheitsupdate verfügbar ist, sollte dies zeitnah eingespielt werden.

URL Rewrite Rule

Authentifizierte Benutzer mit Zugriff auf PowerShell Remoting könnten versuchen die Schwachstelle CVE-2022-41082 auszunutzen. Da PowerShell Remoting allerdings hoffentlich in keiner Umgebung aus dem Internet zu erreichen ist, beschränkt sich hier der Angriffsvektor auf das lokale Netzwerk. Um auch diesen Angriff zu erschweren, können die beiden Port für PowerShell Remoting an der Windows Firewall blockiert werden:

Windows Firewall

Als Aktion wird „Block the connection“ ausgewählt:

Windows Firewall

Der Regel muss nun noch einem Namen bekommen und kann dann gespeichert werden:

Windows Firewall

Unter den folgenden beiden Links finden sich weitere Informationen zu der Schwachstelle:

Der erste Link enthält auch Informationen, wie ein bereits erfolgreicher Angriff festgestellt werden kann.

Update 11.10.2022: Das Pattern wurde durch Microsoft mehrfach aktualisiert. Dieser Beitrag enthält das aktuelle Pattern.

93 thoughts on “Exchange Server Zero-Day Schwachstelle wird aktiv ausgenutzt”

  1. Weiß zufällig jemand welchen Statuscode der IIS bei erfolgreicher Exploitation und beim Testen der Schwachstelle zurück gibt? Wir haben zwei Einträge die zu dem Suchpatter passen, jedoch mit einem Statuscode 401, den wir als gescheiterten Versuch einstufen. Gibt es da Zustimmung? Das Suchpattern von Microsoft scheint sich ja auf einen Statuscode 200 festzulegen…

    Reply

  2. Backup eingespielt.
    Hat alles wieder funktioniert.
    ECP/OWA Intern und Extern
    Mail Empfang ebenfalls Intern/Extern.
    EX Mgmt Shell auch.
    Windows Updates, Reboot.
    Funktioniert noch immer alles.
    Anpassung Regel auf => {UrlDecode:{REQUEST_URI}} und (?=.*autodiscover)(?=.*powershell)
    Reboot
    Funktioniert noch immer alles.
    Installation via EX Mgmt Shell => Exchange2016-KB5019077-x64-de (CU Update 23KB5019077)
    Reboot
    Hat alles wieder funktioniert.

    Reply

  3. Also es starten auch die Dienste nicht:

    PS C:\Users\Administrator> Get-Service *Exchange*

    Status Name DisplayName
    —— —- ———–
    Stopped MSExchangeADTop… Microsoft Exchange Active Directory…
    Stopped MSExchangeAntis… Microsoft Exchange-Antispamupdate
    Stopped MSExchangeCompl… Microsoft Exchange-Compliancedienst
    Stopped MSExchangeDagMgmt Microsoft Exchange DAG-Verwaltung
    Stopped MSExchangeDelivery Microsoft Exchange-Postfachtranspor…
    Stopped MSExchangeDiagn… Microsoft Exchange-Diagnose
    Stopped MSExchangeEdgeSync Microsoft Exchange EdgeSync
    Stopped MSExchangeFastS… Microsoft Exchange-Suche
    Stopped MSExchangeFront… Microsoft Exchange Frontend Transport
    Stopped MSExchangeHM Microsoft Exchange-Integritätsdienst
    Stopped MSExchangeHMRec… Microsoft Exchange-Integritäts-Mana…
    Stopped MSExchangeImap4 Microsoft Exchange IMAP4
    Stopped MSExchangeIMAP4BE Microsoft Exchange-IMAP4-Back-End
    Stopped MSExchangeIS Microsoft Exchange Information Store
    Stopped MSExchangeMailb… Microsoft Exchange-Postfach-Assiste…
    Stopped MSExchangeMailb… Microsoft Exchange-Postfachreplikation
    Stopped MSExchangeMitig… Microsoft Exchange-Notfallschutzdienst
    Stopped MSExchangeNotif… Microsoft Exchange-Benachrichtigung…
    Stopped MSExchangePop3 Microsoft Exchange POP3
    Stopped MSExchangePOP3BE Microsoft Exchange-POP3-Back-End
    Stopped MSExchangeRepl Microsoft Exchange-Replikation
    Stopped MSExchangeRPC Microsoft Exchange-RPC-Clientzugrif…
    Stopped MSExchangeServi… Microsoft Exchange-Diensthost
    Stopped MSExchangeSubmi… Microsoft Exchange-Postfachtranspor…
    Stopped MSExchangeThrot… Microsoft Exchange-Einschränkungen
    Stopped MSExchangeTrans… Microsoft Exchange-Transport
    Stopped MSExchangeTrans… Microsoft Exchange-Transportprotoko…
    Stopped MSExchangeUM Microsoft Exchange Unified Messaging
    Stopped MSExchangeUMCR Microsoft Exchange Unified Messagin…
    Stopped SearchExchangeT… Tracing Service for Search in Excha…
    Stopped vmickvpexchange Hyper-V-Datenaustauschdienst
    Stopped wsbexchange Microsoft Exchange Server Extension…

    PS C:\Users\Administrator>

    Reply

  4. Ich habe jetzt das Update Installiert (Exchange2016-KB5019077-x64-de) und d. Server Neugestartet.
    Jetzt Starten die EX Dienste wieder bis auf ein paar.
    Der MS EX-Benachrichtungsbroker auf Lokaler Computer konnte nicht gestartet werden.
    Fehler 1068:

    Dann habe ich ausgeführt:
    [PS] C:\Users\ExAdmin\Desktop>.\EOMTv2.ps1
    AUSFÜHRLICH: Checking if EOMTv2 is up to date with https://aka.ms/EOMTv2-VersionsUri
    AUSFÜHRLICH: Starting EOMTv2.ps1 version 22.10.07.2029 on SVRAIGEX
    AUSFÜHRLICH: EOMTv2 precheck complete on „Servername“
    AUSFÜHRLICH: Applying mitigation on „Servername“
    AUSFÜHRLICH: Starting mitigation process on „Servername“
    AUSFÜHRLICH: IIS URL Rewrite Module is already installed on „Servername“
    AUSFÜHRLICH: Applying URL Rewrite configuration to „Servername“ :: Default Web Site
    AUSFÜHRLICH: Mitigation complete on „Servername“ :: Default Web Site
    AUSFÜHRLICH: EOMTv2.ps1 complete on „Servername“, please review EOMTv2 logs at
    C:\Users\ExAdmin\AppData\Local\Temp\EOMTv2\EOMTv2.log and the summary file at C:\EOMTv2Summary.txt

    Neustart

    AUSFÜHRLICH: Verbindung mit „Servername“ wird hergestellt.
    New-PSSession : „Servername“ Beim Verbinden mit dem Remoteserver „Servername“ ist folgender Fehler aufgetreten: Der WinRM-Client hat einen Status in Bezug auf einen
    HTTP-Serverfehler (500) empfangen, aber der Remotedienst hat keine anderen Informationen zur Fehlerursache bereitgestellt. Weitere Informationen finden Sie im Hilfethema
    „about_Remote_Troubleshooting“.
    In Zeile:1 Zeichen:1
    + New-PSSession -ConnectionURI „$connectionUri“ -ConfigurationName Micr …
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotingTransportException
    + FullyQualifiedErrorId : WinRMHttpError,PSSessionOpenFailed

    Habe ich etwas verpasst oder falsche gemacht ?
    Es wurde heute nur der Server Neugestartet, seitdem die Fehler.

    Reply

  5. [PS] C:\Windows\system32>winrm e winrm/config
    WSManFault
    Message
    ProviderFault
    WSManFault
    Message = Der WS-Verwaltungsdienst kann die Anforderung nicht verarbeiten. Der Ressourcen-URI unterstützt den Vorgang „Enumerate“ nicht.

    Fehlernummer: -2144108495 0x80338031
    Der WS-Verwaltungsdienst kann die Anforderung nicht verarbeiten, weil der Aktions-URI der WS-Adressierung in der Anforderung nicht mit der Ressource nicht kompatibel.
    [PS] C:\Windows\system32>

    Reply

  6. Ich bin die Anleitung nochmal durch bzw. eintrag v. Dennis.

    Jetzt bekomme ich :

    AUSFÜHRLICH: Verbindung mit „Servername“ wird hergestellt.
    New-PSSession : „Servername“ Beim Verbinden mit dem Remoteserver „Servername“ ist folgender Fehler aufgetreten: Der WinRM-Client hat einen Status in Bezug auf
    einen HTTP-Serverfehler (500) empfangen, aber der Remotedienst hat keine anderen Informationen zur Fehlerursache bereitgestellt. Weitere Informationen finden Sie im Hilfethema
    „about_Remote_Troubleshooting“.
    In Zeile:1 Zeichen:1
    + New-PSSession -ConnectionURI „$connectionUri“ -ConfigurationName Micr …
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotingTransportException
    + FullyQualifiedErrorId : WinRMHttpError,PSSessionOpenFailed

    Reply

  7. Ich habe das selbe Problem wie @Michael.
    Heute Server 2016 mit EX2016 Neugestartet und keine Shell mehr.
    AUSFÜHRLICH: Verbindung mit „Servername“ wird hergestellt.
    New-PSSession : [„Servername“] Beim Verbinden mit dem Remoteserver „Servername“ ist folgender Fehler aufgetreten: Der WinRM-Client kann die Anforderung nicht verarbeiten. Der Inhaltstyp der HTTP-Antwort vom Zielcomputer kann nicht
    ermittelt werden. Der Inhaltstyp fehlt oder ist ungültig. Weitere Informationen finden Sie im Hilfethema „about_Remote_Troubleshooting“.
    In Zeile:1 Zeichen:1
    + New-PSSession -ConnectionURI „$connectionUri“ -ConfigurationName Micr …
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotingTransportException
    + FullyQualifiedErrorId : -2144108297,PSSessionOpenFailed
    Fehler beim Herstellen der Verbindung zu einem Exchange-Server am aktuellen Standort.
    Geben Sie den vollqualifizierten Domänennamen des Servers ein, zu dem eine Verbindung hergestellt werden soll.:

    Reply

  9. wenn ich die regeln anwende, geht unser ganzer EXC in die KNIE.
    OWA/ECP Outlook clients haben keine connection mehr..

    Reply

  10. Mit aktivierter Regel funktioniert bei uns die Exchange Management Shel auf dem Server nicht mehr:
    Win 2012R2, Exchange 2013 full patched. Nach Löschung der Regel ist alles OK.

    Der WinRM-Client hat einen Status in Bezug auf einen HTTP-Serverfehler (500) empfangen, aber der Remotedienst hat keine anderen Informationen zur Fehlerursache bereitgestellt.
    Weitere Informationen finden Sie im Hilfethema
    „about_Remote_Troubleshooting“.
    In Zeile:1 Zeichen:1
    + New-PSSession -ConnectionURI „$connectionUri“ -ConfigurationName Microsoft.Excha …
    + ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo : OpenError: (System.Manageme….RemoteRunspace:RemoteRunspace) [New-PSSession], PSRemotingTransportException
    + FullyQualifiedErrorId : WinRMHttpError,PSSessionOpenFailed

    Fehler beim Herstellen der Verbindung zu einem Exchange-Server am aktuellen Standort.
    Geben Sie den vollqualifizierten Domänennamen des Servers ein, zu dem eine Verbindung hergestellt werden soll.:

    Reply

    • Habe noch festgestellt, dass sich die Regel auch in der „Exchange Backend Site“ auf dem IIS einträgt. „Default Web Site“ und „Exchange Backend“ sind miteinender verknüpft.
      Das ist auf einem Exchange 2016 nicht der Fall, hier funktioniert ja auch alles danach.

      Reply

  11. Hallo,
    wir haben bei uns bisher den Workaround noch nicht angepasst, denn Zitat heise.de: „Eine Bestätigung der besseren Wirksamkeit der angepassten Regel durch weitere IT-Sicherheitsexperten findet sich derzeit nicht.“
    Wir halten allerdings die Augen und Ohren offen…

    Grüße

    PS: Danke Franky für Deine Arbeit!

    Reply

  14. Auf meinem Exchange2019 auf Server2022 ist auch über Nacht eine EEMS M1.1 PowerShell-inbound automatisch eingebunden worden.

    Reply

  15. Moin zusammen,

    ist der Angriff eigentlich auch möglich, wenn 443 in der FW closed ist ?

    Also kein Owa ohne VPN möglich ist.

    Zweitens, ich habe gestetern irgendwo gelesen, das ein authentifizierter Account mit Admin Rechten notwendig ist, um den Angriff auszuführen.

    Hat sich das bewahrheitet ?

    Herzlichen Dank!

    Best
    Lothar

    Reply

  16. PS: Neustart des Exchange ist erst später möglich, werde das aber damit auch noch versuchen…
    Auf allen EX2016er Servern ist inzwischen die Regel von EM angelegt, dort steht REQUEST-URI…

    Reply

  17. Moin,

    Nachdem ich gestern meine 2016 Exchange bearbeitet hatte schaute ich heute morgen nach den 2019er. Hier gab es bereits eine Regel EEMS M1.1 PowerShell – inbound. Es scheint als hätte Microsoft die Regel verteilt.

    Per Powershell liefert: Get-ExchangeServer | Format-List Name,MitigationsApplied,MitigationsBlocked
    folgendes Ergebnis: MitigationsApplied : {M1.1, PING1}

    Auf die schnelle heute morgen habe ich noch nichts weiter dazu gefunden.

    LG

    Reply

    • Same thing here, my 2016 were not having the Mitigation, but the 2019 did already (and their EOMT just added a second same rule)

      Reply

  18. Hallo, bei mir gibt es mit der Regel, auch mit der Version von MS grosse Probleme mit Autodiscover. O365 an einem Ex2013 aktuelles CU und URL_Rewrite (2012R2 Server), der Chef muss auf die Kalender diverser AD-Mitarbeiter zugreifen. Mit Vollzugriff automatische Einbindung. Bislang… Jetzt erscheinen die zusätzlichen Accounts für vielleicht 30 Sekunden und verschwinden dann wieder.
    Ohne die Regel klappt es… Habe schon beide Varianten REQUEST_URL und REQUEST_URI versucht, beides ohne Erfolg….

    Hat jemand eine Idee?

    Reply

  21. Guten Morgen,
    auf unserem 2016er hat der EM-Service heute Nacht die Regel auf der Default Website automatisch erstellt.
    Na endlich…

    VG
    Gero

    Reply

  23. Also bei mir mit Exchangeserver 2019 mit aktueller CU + SU inkl. Erweitertem Schutz und unter Pattern mit Eintrag:
    .*autodiscover\.json.*\@.*Powershell.* wie oben im Bild, funktioniert alles tadellos.
    Die Fehlermeldung Error403 über die Test URL kommt wie es soll.
    Handy`s funktionieren noch.
    Neue Postfächer mit Einbindung unter Outlook über Autodiscover funktionieren auch.

    Wenn der Exchangeserver mit allen Updates und Patches aktuell ist, sollte es auch funktionieren.

    Reply

  25. Wenn ich den Workaround so anwende geht auch bei mir kein Autodiscover mehr. Interessanterweise muss ich auch gleich die ganze Regel löschen damit es wieder funktioniert. Ein Deaktivieren der Regel reicht nicht.
    Ich habe wie beschrieben eine Regel mit dem Pattern .*autodiscover\.json.*\@.*Powershell.* und Regular Expression angelegt und als Condition Input {REQUEST_URI} eingetragen.
    Beim Pattern steht bei mir auch ein .* und nicht wie im Bild nur ein *
    Beim Server handelt es sich um einen deutschen Exchange 2013 .
    Hat jemand eine Idee was ich falsch mache?

    Reply

    • Das war bei mir in einer Umgebung auch so … Exchange 2016 gleicher Patchstand, identische Konfig… ich hatte die Regel wie Du auch zunächst nur deaktiviert was aber nicht ausreichte … habe gerade den Exchange neugestartet … jetzt funktionieren die Outlook Profile wieder…

      Reply

  26. Hallo, wir setzen bei uns im Unternehmen 2 Exchange Server ein. Wir haben einen Reverse Proxy vorgeschalten. Auf einem der Exchange Server erhalte ich beim ausführen des Befehls folgende Ausgaben angezeigt:

    C:\inetpub\logs\LogFiles\W3SVC2\u_ex220319.log:75442:2022-03-19 17:57:16 f_4f::12_7f:f5_5:e_77:_d4e%3 POST /Powershell X
    -Rps-CAT=VgEAVAd_aW5sb3dzTwBBC_tlcmJlcm9z_B9BZG1pbmlzdHJhdI9_QG1lZGlhAW50ZXJmYWNlLmR_VS1TLTEtNS0yMS0_OTM2Nzg3Nzk3LTMxMz
    AtNj34TkktMzEzNTI1_jg5NC_1MABHAQAAAAcADDDMUy0xL_UtMzItNTQ0_QABAAA=&Email=autodiscover/autodiscover.json%3F@xuhnf.zvc
    444 administrator@firma.de f_4f::12_7f:f5_5:e_77:_d4e%3 Python+PSRP+Client – 200 0 0 2

    Alle Einträge sind vom 19.03.22?!?

    Leider ist unser Admin heute nicht erreichbar. Was mich wundert, ich finde im IIS Default Pool kein URL Rewrite? Exchange Version 15.1 (Build 2106.2). Ich frage mich gerade ob ich nun ohne Admin https://www.iis.net/downloads/microsoft/url-rewrite installiere und den Workaround durchführen soll. Was denkt Ihr?

    Reply

  27. In dem Screenshot wo die {REQUEST_URI} eingetragen wird sind die Hochkommas bei .*autodiscover\.json.*\@.*Powershell.* noch vorne und hinten angefügt. Das sollte noch korrigiert werden um möglicherweise keinen zu verunsichern.

    Reply

  28. RegEx-Notation erkennt man an der Kombi: “.*”
    PUNKT steht für: Any character except linebreak
    STERNCHEN steht für: Match zero or more of the preceding token.
    Kombi aus PUNKT und STERNCHEN ist dann identisch mit einem STERNCHEN wenn es WILDCARD-Notation wäre.

    Reply

  29. da ist wohl ein Kleiner Tipfehler:

    Aktuell wird eine Zero-Day Schwachstelle in Exchange Server 2013, 2016 und 109 aktiv ausgenutzt. Aktuell gibt es noch kein Sicherheitsupdate für die folgenden Schwachstellen:

    Sollte doch eher sowas ein?
    Aktuell wird eine Zero-Day Schwachstelle in Exchange Server 2013, 2016 und 2019 aktiv ausgenutzt. Aktuell gibt es noch kein Sicherheitsupdate für die folgenden Schwachstellen:

    Reply

  31. Nach ausführen des Workarounds funktioniert bei mir überhaupt kein Autodiscover mehr (Outlook intern und extern, Smartphones etc.)

    Exchange 2016 mit Outlook 2016 und Outlook 365, Android Smartphones

    Reply

    • Prüf die Regel, evtl. fehlt wo ein „.“ am Anfang.
      Das Kann passieren wenn es zuerst als Wildcard angelegt wird und später auf RegEx geändert wird.

      Reply

  33. Jetzt bin ich nicht so der RegEx-Experte, aber muss bzw. soll das Pattern nicht

    .*autodiscover\.json.*\@.*Powershell.*

    lauten (Das erste Zeichen des Pattern ist ein „.“ und nicht ein „*“)?

    Reply

  34. Wenn Autodiscover nicht im Internet Publiziert ist, sehe ich es richtig das der Handlungsbedarf nicht so extrem kritisch ist oder?

    Reply

  35. Also wenn ich eine Regel mit „Regex“ erstelle und Pattern „*autodiscover\.json.*\@.*Powershell.*“ funktioniert Autodiscover danach überhaupt nicht mehr. Stelle ich um auf „Wildcard“ greift die Regel nicht mehr (insofern auch logisch, ist ja auch klar eine Regular expression…).

    Ich habe jetzt eine Wildcard-Regel mit Pattern „*autodiscover.json*@*Powershell*“ erstellt. Das scheint zu funktionieren.
    Getestet mit Aufrufen nach https://owa.example.local/Autodiscover/autodiscover.json@PowerShell und https://owa.example.local/autodiscover/autodiscover.json\?@evil.com/powershell\&Email\=autodiscover/autodiscover.json%3f@evil.com

    Reply

      • Stimmt. Und auch beim „Pattern“-Feld in der eigentlichen Regel (und nicht in den Conditions) stand „*“ und nicht „.*“.
        Wohl weil ich initial die Regel als Wildcard erstellt hatte und danach auf Regex geswitcht. In dem Fall muss man auch das Pattern anpassen. Und ebenfalls entfernt IIS bei „Wildcard“-Regeln den von dir erwähnten Punkt am Anfang beim Condition-Pattern automatisch.

        Wie auch immer, jetzt funktionierts :)

        Reply

  36. Update: ich habe die Regeln nochmals gelöscht und neu angelegt, funktioniert jetzt. Im Gegensatz zu dem Screenshots steht bei mir aber als Muster .*

    Reply

  37. Bei RegEx müsste der Match-Wert der Regel .* lauten und nicht nur *, wenn man die Regel direkt als RegEx anlegt. Wenn man von Wildcard auf RegEx wechselt, nachdem sie schon erstellt war, ändert sich das nicht automatisch (was bei den Screenshots wohl der Fall war?).

    Reply

  38. Mahlzeit,

    die UrlReWrite Regel macht bei mir die Einrichtung eines neuen Mailkontos im Outlook kaputt, Autodiscover findet den User und Server, bleibt aber am 3. Punkt („Am E-Mail Server anmelden“) hängen.
    „Fehler beim Anmelden. Überprüfen Sie die Netzwerkverbindung… Outlook muss im Onlinemodus…“
    Server 2012 R2 mit Exchange 2013, letztes CU und aktuelles Patchlevel.
    Deaktiviere ich die Regel geht die Einrichtung wieder problemlos.

    Reply

    • Tag zusammen,
      habe es eben ausprobiert. Bei uns kein Problem. Neues Konto lässt sich normal einrichten. Trotz der ReWrite Regel.
      Ebenfalls Server 2012R2 mit Exchange 2013 latest CU und Patch.

      Reply

    • Moin Moin,

      bei uns auch, trotz der ReWrite Regel, bis jetzt noch kein Problem mit der Einrichtung des Kontos festgestellt!
      Mit Exchange 2016 als auch mit Exchange 2019 latest CU und Patch ausprobiert.

      Reply

  39. Für die Core Server Leute hier das ganze per PS – gerne verbessern !

    $site = „iis:\sites\Default Web Site\Autodiscover“
    $filterRoot = „system.webServer/rewrite/rules/rule[@name=’CVE-2022-41040′]“
    Clear-WebConfiguration -pspath $site -filter $filterRoot
    Add-WebConfigurationProperty -pspath $site -filter „system.webServer/rewrite/rules“ -name „.“ -value @{name=’CVE-2022-41040′ + $_ ;patternSyntax=’Regular Expressions‘;stopProcessing=’True‘}
    Set-WebConfigurationProperty -pspath $site -filter „$filterRoot/match“ -name „url“ -value „.*“
    Set-WebConfigurationProperty -pspath $site -filter „$filterRoot/conditions“ -name ‚.‘ -value @{input='{REQUEST_URI}‘; matchType=’0′; pattern=‘.*autodiscover\.json.*\@.*Powershell.*‘; ignoreCase=’True‘; negate=’False‘}
    Set-WebConfigurationProperty -pspath $site -filter „$filterRoot/action“ -name „type“ -value „CustomResponse“
    Set-WebConfigurationProperty -pspath $site -filter „$filterRoot/action“ -name „statuscode“ -value 403

    Reply

    • Zeichen angepasst und Firewallregel ergänzt:

      $site = „iis:\sites\Default Web Site\Autodiscover“
      $filterRoot = „system.webServer/rewrite/rules/rule[@name=’CVE-2022-41040′]“
      Clear-WebConfiguration -pspath $site -filter $filterRoot
      Add-WebConfigurationProperty -pspath $site -filter „system.webServer/rewrite/rules“ -name „.“ -value @{name=’CVE-2022-41040′ + $_ ;patternSyntax=’Regular Expressions‘;stopProcessing=’True‘}
      Set-WebConfigurationProperty -pspath $site -filter „$filterRoot/match“ -name „url“ -value „.*“
      Set-WebConfigurationProperty -pspath $site -filter „$filterRoot/conditions“ -name ‚.‘ -value @{input='{REQUEST_URI}‘; matchType=’0′; pattern=‘.*autodiscover\.json.*\@.*Powershell.*‘; ignoreCase=’True‘; negate=’False‘}
      Set-WebConfigurationProperty -pspath $site -filter „$filterRoot/action“ -name „type“ -value „CustomResponse“
      Set-WebConfigurationProperty -pspath $site -filter „$filterRoot/action“ -name „statuscode“ -value 403
      New-NetFirewallRule -DisplayName „Block PowerShell Remoting“ -Direction Inbound -LocalPort 5985, 5986 -Protocol TCP -Action Block

      Reply

  44. Nach der URL Rewrite Regel kann ich mich von Admin PCs nicht per Powershell zum Exchange verbinden.
    Geht das noch jemanden so? Ist das gewollt?

    Lokale auf dem Exchange Servern geht alles.

    Reply

  45. Wenn ein deutsches Exchange installiert ist, sollte die [REQUEST_URI] durch die deutsche Variable ersetzt werden, oder täusche ich mich?

    Reply

    • Ich glaube das ist ein Fehler hier in der Anleitung.
      Im Original steht nicht, dass URI in REQUEST_URI geändert werden soll. Da steht nur REQUEST_URI eintragen. Im Englischen steht da auch URL.

      Reply

  47. Wenn ich mich recht erinnere, basiert der Mitigation Service auf dem URL Rewrite Modul und dieses wurde erst mit dem letzten oder vorletzten CU installiert (daher evtl. die Ungleichheit ob das Modul installiert ist oder nicht)

    Tipp für mehrere Exchange Server:
    1x Regelwerk exportieren mit dem guten alten app cmd

    %systemroot%\system32\inetsrv

    appcmd list config „Default Web Site/Autodiscover“ -section:system.webServer/rewrite/rules -xml > rules.xml

    Und auf den weiteren Servern dann

    appcmd set config „Default Web Site/Autodiscover“ -in < rules.xml

    Reply

  48. wenn ich den Port 5985 blockiere können unsere beiden Exchange untereinander nicht mehr kommunizieren?
    2022-09-30 11:13:50 DROP TCP 10.10.1.44 10.10.2.44 40225 5985 48 S 2707299551 0 8192 – – – RECEIVE

    vermutlich können auch andere Server (JOB Server) im Unternehmen keine PS mehr am Exchange ausführen. Das fällt ja sicher auch unter Remote PS

    Reply

  51. Ich finde es schon wieder fatal, dass es zwei unterschiedliche Workarounds gibt..

    Wir haben stand jetzt erstmal nur den Eintrag von GTSC gesetzt, sprich auch so wie Franky den Artikel hat.
    Beobachten aber weiter ob das ausreicht oder hier doch der MS eintrag muss

    Reply

    • Der String ist eindeutig Regex-Syntax, womit der Fall ziemlich klar ist.

      Deshalb muss man als guter Admin etwas Grundlagenwissen in allen Bereichen mitbringen um sowas dann richtig einordnen zu können. Auch den Powershell-Befehl zur Überprüfung eines möglichen Angriffs sollte man zumindest grundlegend verstehen, um dann das Ergebnis einzuordnen. In dem Fall also -> kein Ergebnis = kein verdächtige Aktivität im Log

      Inzwischen hat auch Microsoft seine Anleitung übrigens auch angepasst, so dass jetzt überall Regex angegeben ist.

      Reply

  52. Vielen Dank für die Info und die Lösung.
    Sollte nach den Einträgen ein iisrestart gemacht werden oder wird die Regel sofort aktiv?

    Viele Grüße
    Katrin

    Reply

  53. Und ist nicht eigentlich für genau solche Fälle die „Exchange Emergency Mitigation“ zuständig, welche solche Regeln eigenständig setzt?
    Oder habe ich die EM falsch verstanden?

    Reply

    • Das Modul URL rewrite sollte installiert sein, dies wird benötigt um den Workaround anzuwenden.
      Heißt -> Installieren des Moduls. (Achtung IIS wird hier neustarten und die Clients bekommen kurzen disconnect)

      Danach die Regel anwenden, wie beschrieben.

      Reply

    • Doch! Wenn du IISURL Rewrite nicht installiert hast, ist dein Exchange 2016/2019 stark veraltet oder du hast noch Exchange 2013. In allen Fällen dafür sorgen, dass du auf aktuellstem CU und Security Updates bist und danach im IIS URL Rewrite (den du bei Exchange 2013 so oder so installieren musst) den Workaround konfigurieren.

      Reply

  55. Danke @franky – wie immer mega schnell.

    Es ist korrekt, dass es ohne “ “ eingetragen werden muss.
    Siehe auch der MS Artikel:
    https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/

    Hier wird noch diskutiert, ob man WILDCARD oder REGULAR EXPRESSION verwenden soll:
    https://techcommunity.microsoft.com/t5/exchange-team-blog/customer-guidance-for-reported-zero-day-vulnerabilities-in/ba-p/3641494

    Ich würde hier pragmatisch erstmal beides eintrage, bis es konkrete Infos gibt.

    Reply

  58. Hallo Frank!
    1. Frage: WARUM trägst du den Ausdruck .*autodiscover\.json.*\@.*Powershell.* mit „“ ein ?
    2. Frage: MS Doku widerspricht der Doku aus Vietnam, denn MS fügt die Regel als Wildcard ein und die Vietnamesen als Reg.Expr. ! Was ist nun richtig?

    Reply

Leave a Comment