Microsofts Empfehlungen für die Exchange Server 0-day-Schwachstelle ZDI-CAN-18333

Exchange Logo[English]Die Nacht hatte ich im Blog über eine 0-Day-Schwachstelle ZDI-CAN-18333 in Microsofts On-Premises Exchange Servern berichtet, die bereits in freier Wildbahn ausgenutzt wird. Binnen weniger Stunden hat Microsoft nun reagiert und bestätigt, dass man derzeit zwei gemeldete Zero-Day-Schwachstellen (CVE-2022-41040, CVE-2022-41082) die Microsoft Exchange Server 2013, 2016 und 2019 betreffen, untersucht. Gleichzeitig gibt Microsoft betroffenen Administratoren Hinweise, was man zum Schutz vor diesen Zero-Day-Schwachstellen tun kann, bis entsprechende Sicherheitsupdates vorliegen.


Anzeige

Microsoft bestätigt Schwachstellen

Die Information über mögliche Zero-Day-Schwachstellen in den On-Premises Installationen von Microsoft Exchange sind erst seit einigen Stunden öffentlich. Ich hatte die Nacht im Blog-Beitrag Exchange Server werden über 0-day Exploit angegriffen (29. Sept. 2022) darüber berichtet. Microsoft hat binnen Stunden reagiert und im Techcommunity-Beitrag Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange Server vom 29. September 2022 bestätigt, dass man derzeit zwei gemeldete Zero-Day-Schwachstellen, die Microsoft Exchange Server 2013, 2016 und 2019 betreffen, untersucht. Es handelt sich um folgende Schwachstellen:

  • CVE-2022-41040: Es handelt sich um eine SSRF-Schwachstelle (Server-Side Request Forgery)
  • CVE-2022-41082: Ermöglicht eine Remotecodeausführung (RCE), wenn der Angreifer Zugriff auf PowerShell hat

Details legt man nicht offen. Microsoft gibt zudem an, dass derzeit nur wenige gezielte Angriffe bekannt, bei denen die beiden Sicherheitslücken genutzt werden. Bei diesen Angriffen kann CVE-2022-41040 laut Microsoft einem authentifizierten Angreifer ermöglichen, CVE-2022-41082 remote, d.h. aus der Ferne, auszulösen.

Erste Einstufung durch Microsoft

Microsoft schreibt in seinem Beitrag: Es ist zu beachten, dass ein authentifizierter Zugriff auf den anfälligen Exchange Server erforderlich ist, um eine der beiden Sicherheitslücken erfolgreich auszunutzen.

Das klingt erst einmal "beruhigend", da eine Authentifizierung auf dem Exchange Server benötigt wird. Aber beim Hafnium-Hack Ende Februar, Anfang März 2021 kam es zu einem massiven Angriff auf Microsoft Exchange Server (siehe Exchange-Server 0-day-Exploits werden aktiv ausgenutzt, patchen!). Später beschuldigten die USA China dieses Angriffs (siehe USA, EU, NATO, Microsoft & Co. beschuldigen China für Hafnium Exchange-Hack). Und ich bin mir nicht sicher, wie viele Informationen zur Authentifizierung an Exchange-Systemen in den letzten Monaten bei Hacks erbeutet wurden.

Microsoft Exchange Online nicht betroffen

Laut Redmond verfügt Microsoft Exchange Online über Erkennungsmöglichkeiten und Abhilfemaßnahmen, um Kunden gegen die Schwachstellen zu schützen. Microsoft überwacht auch diese bereits implementierten Erkennungen auf bösartige Aktivitäten und wird, laut eigener Aussage, die notwendigen Maßnahmen zum Schutz der Kunden ergreifen.

Ergänzungen durch Sicherheitsforscher

Sicherheitsforscher Kevin Beaumont hat inzwischen einen eigenen Artikel mit den aktuellen Informationen und seinen eigenen Erkenntnissen auf DoublePulsar zum Sachverhalt veröffentlicht (danke an die Blog-Leser für die Links auf die Artikel von Beaumont und Microsoft).

Beaumont schreibt, dass Nutzer der Cloud-Version Exchange Online nicht betroffen seien. Das Gleiche gelte für Systeme, die keine Outlook-Webanwendung (Outlook Web App) betreiben, die per Internet erreichbar ist.  Aber Beaumont hat auch nachfolgende Darstellung der Suchmaschine Shodan gepostet. In Deutschland sind über 40.000 Exchange Installationen per Outlook Web App über das Internet erreichbar.

Exchange reachable via Outlook Web App per Internet
Exchange Server per Internet über Outlook Web App erreichbar, Quelle: Shodan

Abschwächung der Sicherheitslücken

Microsoft erklärt zwar, dass man mit Hochdruck an der Veröffentlichung eines Fixes arbeite. Bis neue Erkenntnisse oder ein Fix vorliegen, schlägt Microsoft die nachfolgenden Maßnahmen zur Entschärfung der Schwachstellen und Erkennung von Angriffen vor.


Anzeige

Die derzeitige Abhilfemaßnahme besteht darin, unter "IIS-Manager -> Standard-Website -> Autodiscover -> URL-Rewrite -> Aktionen" eine Blockierungsregel hinzuzufügen, um die bekannten Angriffsmuster zu blockieren.

Diese Maßnahme hatten die Entdecker der Schwachstelle bereits beschrieben (siehe auch meinen Blog-Beitrag Exchange Server werden über 0-day Exploit angegriffen (29. Sept. 2022)). Der Microsoft-Beitrag enthält einige Bilder, die die Vorgehensweise verdeutlichen. Microsoft schreibt, dass keine Auswirkungen auf die Exchange-Funktionalität bekannt seien, wenn das URL-Rewrite-Modul wie empfohlen installiert wird.

Achtung: Blog-Leser Robert Richter weist in diesem Kommentar hier im Blog auf eine Diskrepanz in der URL für den regulären Ausdruck hin. Microsoft verwendet ein * als Pattern für die Blocking-Rule, während die Entdecker aus Vietnam den Ausdruck .* für die Regel angeben. Meiner Ansicht nach (bin da kein Crack), ist der Ausdruck .* die korrekte Ausführung – da dieses Pattern laut diesem Beitrag beliebig viele Zeichen finden soll. Vor dem * müsste demnach noch ein Zeichen, welches gesucht werden soll, stehen (siehe auch). In der von Microsoft angegebenen Form * des Pattern wird ein leerer String gesucht – da wurde imho der Punkt vergessen.

Weiterhin schreibt Microsoft, dass authentifizierte Angreifer, die auf PowerShell Remoting auf anfälligen Exchange-Systemen zugreifen können, in der Lage seien, RCE mit CVE-2022-41082 auszulösen. Daher kann das Blockieren der für Remote PowerShell verwendeten Ports

HTTP: 5985
HTTPS: 5986

diese Angriffe einschränken.

Erkennung von Angriffen

Microsoft hat aktuell noch keine spezifische Erkennungsabfrage für die Schwachstellen in seinen Sicherheitslösungen implementiert. Im Techcommunity-Beitrag Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange Server schreibt Microsoft aber, dass man nach dem, was in freier Wildbahn bei Angriffen beobachtet wurde, bestehende Erkennungstechniken hilfreich seien.

Der Beitrag Web Shell Threat Hunting with Microsoft Sentinel über die Suche nach Web Shell-Bedrohungen mit Microsoft Sentinel biete auch eine gute Anleitung für die Suche nach Web Shells im Allgemeinen.

Die Exchange SSRF Autodiscover ProxyShell-Erkennung, die als Reaktion auf ProxyShell erstellt wurde, lässt sich ebenfalls für Abfragen verwenden. Denn es gibt Ähnlichkeiten in der Vorgehensweise der obigen Bedrohung. Außerdem gibt es eine neue Abfrage für Exchange Server Suspicious File Downloads, die speziell nach verdächtigen Downloads in IIS-Protokollen sucht. Zusätzlich zu diesen Abfragen gibt es noch einige weitere, die bei der Suche nach Aktivitäten nach der Ausnutzung hilfreich sein könnten, die Microsoft im Beitrag aufführt. Auch der Microsoft Defender for Endpoint kann Angriffsversuche erkennen und Alarm schlagen.

Zudem hatte ich im Blog-Beitrag Exchange Server werden über 0-day Exploit angegriffen (29. Sept. 2022) ja einen PowerShell-Befehl zum Scannen angegeben. Administratoren sind dem Ganzen also nicht hilflos ausgesetzt, sondern können ihre On-Premises Exchange-Installationen vor dieser Bedrohung weitgehend schützen.

Ergänzung: Beachtet, dass Microsoft die Empfehlungen zur Abschwächung der Sicherheitslücken inzwischen mehrfach überarbeitet hat – sieht folgende Artikellinks.

Artikelreihe:
Exchange Server werden über 0-day Exploit angegriffen (29. Sept. 2022)
Microsofts Empfehlungen für die Exchange Server 0-day-Schwachstelle ZDI-CAN-18333
Neues zur Exchange Server 0-day-Schwachstelle ZDI-CAN-18333: Korrekturen, Scripte und EMS-Lösung
Exchange Server: Microsofts 0-day-Schutz aushebelbar, neue Einschätzungen (3. Oktober 2022)
Exchange Server: Microsofts bessert Lösungen für 0-day-Schutz nach (5. Oktober 2022)
Exchange Server: Microsofts bessert Lösungen für 0-day-Schutz nach (8. Oktober 2022)

Ähnliche Artikel:
Exchange-Server 0-day-Exploits werden aktiv ausgenutzt, patchen!
Wichtige Hinweise Microsofts und des BSI zum Exchange-Server Sicherheitsupdate (März 2021)
Exchange-Hack: Neue Patches und neue Erkenntnisse
Anatomie des ProxyLogon Hafinum-Exchange Server Hacks
Exchange-Hack: Neue Opfer, neue Patches, neue Angriffe
Neues zur ProxyLogon-Hafnium-Exchange-Problematik (12.3.2021)
Gab es beim Exchange-Massenhack ein Leck bei Microsoft?
ProxyLogon-Hack: Repository für betroffene Exchange-Administratoren
Microsoft Exchange (On-Premises) one-click Mitigation Tool (EOMT) freigegeben

Exchange Server Sicherheitsupdates (9. August 2022)
Probleme mit Exchange März 2022-Updates
Exchange Update-Fehler und -Infos (13. April 2021)
Exchange-Probleme mit ECP/OWA-Suche nach Sicherheitsupdate (März 2021)
Exchange 2016/2019: Outlook-Probleme durch AMSI-Integration
Exchange Server September 2021 CU kommt zum 28.9.2021 mit Microsoft Exchange Emergency Mitigation Service
Exchange Server 2016-2019: Benutzerdefinierte Attribute in ECP nach CU-Installation (Juli 2021) nicht mehr aktualisierbar
Exchange: Extended Protection, Checkliste und Probleme
Update für Exchange Extended Protection-Script, aber weiterhin Fehler
Exchange Health Checker – Script-Erweiterungen von Frank Zöchling


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Sicherheit, Software abgelegt und mit , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

27 Antworten zu Microsofts Empfehlungen für die Exchange Server 0-day-Schwachstelle ZDI-CAN-18333

  1. Philipp Beck sagt:

    Mir scheint, als wäre die Mitigation von Microsoft falsch.

    Das angegebene Muster für URL-Rewrite (".*autodiscover\.json.*\@.*Powershell.*") sieht mir eindeutig nach RegEx aus, erkenntlich an den Backslashes als Escape-Character. In der Anleitung wird aber beim Auswahlfeld "Using" (Deutsch "Unter Verwendung von") nicht auf RegEx umgestellt, sondern auf "Wildcards" belassen.

    Dadurch wird das angegebene Muster nicht als Regex-Muster, sondern als normalen String mit Wildcards interpretiert. Und somit wird die Blockierung der Anfrage vermutlich NICHT funktionieren.

    Oder sehe ich das falsch?

  2. Mario sagt:

    Die Exchangeserver fallen mal wieder, wie die Blätter im Herbst von den Bäumen…
    Wäre das nun nicht ein Case, bei welchem MS "Emergency Mitigations" nutzen könnte?
    Siehe auch:
    https://www.heise.de/hintergrund/Das-bedeutet-Microsofts-neuer-Notausschalter-fuer-Exchange-6206287.html

  3. Boris sagt:

    Der Microsoft Artikel ist definitiv falsch und der von Franky richtig.

    Man kann es auch am Ende selber testen:

    Beim Aufruf folgender Adresse (mail.meinedomain.de bitte gegen die Autodiscover Adresse tauschen)

    -https://mail.meinedomain.de/autodiscover/autodiscover.json?@evil.com/powershell&Email=autodiscover/autodiscover.json%3f@evil.com

    muss als Antwort ein Fehler 403 kommen.

    Wir habe das in den letzten Stunden bei diversen Kunden umgesetzt (2013 – 2019).

    Bei 2013 muss leider das "IIS URL Rewrite" Modul zuerst nachinstalliert werden, welches zu einer kurzen Störung (< 1 Minute) führt

  4. fxbastler sagt:

    Dann auch hier noch einmal da Folgebeitrag.

    setzt beide Regeln automatisch (löscht die vorher falls vorhanden)

    $site = "iis:\sites\Default Web Site\Autodiscover"
    $filterRoot1 = "system.webServer/rewrite/rules/rule[@name='BlockBadAutodiscoverJSON1$_']"
    Clear-WebConfiguration -pspath $site -filter $filterRoot1
    Add-WebConfigurationProperty -pspath $site -filter "system.webServer/rewrite/rules" -name "." -value @{name='BlockBadAutodiscoverJSON1'+ $_ ;patternSyntax='Regular Expressions'; stopProcessing='True' ; enabled='True'; httpResponseStatus="Permanent"}
    Set-WebConfigurationProperty -PSPath $site -filter "$filterRoot1/match" -name 'url' -value ".*"
    Set-WebConfigurationProperty -PSPath $site -filter "$filterRoot1/conditions" -name '.' -value @{input='{REQUEST_URI}'; matchType='0'; pattern='.*autodiscover\.json.*\@.*Powershell.*'; ignoreCase='True'; negate='False'}
    Set-WebConfigurationProperty -pspath $site -filter "$filterRoot1/action" -name "type" -value 'CustomResponse'
    Set-WebConfigurationProperty -pspath $site -filter "$filterRoot1/action" -name "statuscode" -value 403

    $filterRoot2 = "system.webServer/rewrite/rules/rule[@name='BlockBadAutodiscoverJSON2$_']"
    Clear-WebConfiguration -pspath $site -filter $filterRoot2
    Add-WebConfigurationProperty -pspath $site -filter "system.webServer/rewrite/rules" -name "." -value @{name='BlockBadAutodiscoverJSON2'+ $_ ;patternSyntax='Wildcard'; stopProcessing='True' ; enabled='True'; httpResponseStatus="Permanent"}
    Set-WebConfigurationProperty -PSPath $site -filter "$filterRoot2/match" -name 'url' -value "*"
    Set-WebConfigurationProperty -PSPath $site -filter "$filterRoot2/conditions" -name '.' -value @{input='{REQUEST_URI}'; matchType='0'; pattern='.*autodiscover\.json.*\@.*Powershell.*'; ignoreCase='True'; negate='False'}
    Set-WebConfigurationProperty -pspath $site -filter "$filterRoot2/action" -name "type" -value 'CustomResponse'
    Set-WebConfigurationProperty -pspath $site -filter "$filterRoot2/action" -name "statuscode" -value 403

  5. Jürgen sagt:

    Jetzt ist es offiziell:
    Nino Bilic Microsoft
    ‎Sep 30 2022 01:50 PM
    @reph1510 @JJuergen @sjhudson

    To all that have asked: indeed, the screenshot should say "Regular Expressions" and not "Wildcards". We are working with the MSRC team to correct the blog post ASAP.

    https://techcommunity.microsoft.com/t5/exchange-team-blog/customer-guidance-for-reported-zero-day-vulnerabilities-in/bc-p/3641698#M34250

    • Feuerpanda sagt:

      Microsoft sind echt Experten. Will gar nicht wissen wie viele es nun falsch eingetragen haben und denken das hat sich für's erste erledigt und schauen nicht nochmal nach.

    • Boris sagt:

      Ja, das ist hochpeinlich für Microsoft.
      Habe von mehreren Kunden gehört, die es zuerst falsch umgesetzt hatten.
      Und bis die gecachte MS Seite überall weg ist dauert das wieder Tage …

  6. Flo sagt:

    Wenn wie in den Anleitungen von Microsoft oder FrankysWeb die URL Rewrite Regel angelegt wird, ist unter Pattern bei mir ein ".*"

    https://postimg.cc/LqSG2czS

    In den bebilderten Anleitungen ist dort nur ein "*"

    Muss das von Hand noch extra korrigier werden?
    Weil dieser Schritt ist nirgends beschrieben.

    Server 2012R2 Exchange 2016 CU23

    • Singlethreaded sagt:

      .* ist in Verbindung mit dem regulären Ausdruck richtig.

      ->

      Die Anleitung von Microsoft war am Anfang falsch (Wildcard statt regulärer Ausdruck) und jetzt kursieren viele falsche Anleitungen und Screenshots. Ziemliches Chaos leider.

      Am besten die Regel testen und sicherstellen, dass Du einen 403 Fehler bekommst. Beispiel hier:

      https://postimg.cc/cvfj2ns9

      Für die schwarze Box Deinen Exchange-Server einsetzen.

      Gruß Singlethreaded

    • Stefan A. sagt:

      Aus meiner Sicht sind die Bilder (noch) falsch.
      Ggf. wurde vergessen diese anzupassen?

      Der nur „*" bei Pattern kommt, wenn du beim Anlegen (fälschlicherweise) nicht auf „Regular Expression„ umgestellt hattest.
      Das war heute morgen noch bei der Anleitung von MS nämlich so, was mich heute Vormittag ziemlich verunsicherte!!!

      Der Pattern mit „.*" ist richtig so, wie er automatisch angelegt wurde.
      Zumindest ist es so, stellst du den nachträglich um auf nur „*", bricht es den Autodiscover. Hatte ich heute nämlich kurz…

      Schau dir mal den original Artikel vom vietnamesischen Cybersicherheitsunternehmen GTSC zum Vergleich an.

      Vielleicht kann das nochmal jemand bestätigen bzw. wenn ich falsch liege mich korrigieren!

      P.S. Wegen den zusätzlichen Firewall Regeln.
      Solltet ihr eine Exchange DAG betreiben, dürft ihr die Remote Powershell Ports nicht vollständig sperren!
      Soweit ich das interpretiere, würde das die Funktionalität des DAGs beeinflussen.

      Vielleicht kann das nochmal jemand bestätigen bzw. wenn ich falsch liege mich korrigieren!

  7. Bernd sagt:

    Diese Beschreibung ist perfekt inkl. Testscripts und weiterführende Infos
    https://www.alitajran.com/0-day-vulnerability-microsoft-exchange/

  8. Don L. sagt:

    Kurze Frage an die Leute mit einem deutschen Exchange 2016:

    Bezüglich des PS-Befehls für die Logfiles zu durchsuchen: Ich hab mir testweise mal ein eigenes Logfile angelegt mit dem entsprechenden Pattern 'powershell.*autodiscover\.json.*\@.*200' – auf unserem 2016ner (deutsche Sprache) findet er das Pattern nicht und gibt somit auch keine Ergebnisse zurück und es sieht aus als wäre alles in Ordnung. Wenn man das Pattern dann kürzt auf nur 'powershell.*autodiscover' findet er auch die Ergebnisse. Getestet mit PS x86 & x64. Jetzt die Frage: Hab ich in der Eile einen Denkfehler oder funktioniert der Befehl auf einem deutschen Exchange 2016 einfach nicht?

  9. Don L. sagt:

    Habs eben selbst getestet. Mit folgenden Befehlen kommen korrekte Ergebnisse ohne die "-Zeichen vorne und hinten:

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

    oder

    "Get-ChildItem -Recurse -Path -Filter "*.log" | Select-String -Pattern 'powershell.*autodiscover\.json.*\@.*200' -SimpleMatch"

    So wie der Befehl online steht gibt er immer ein "cleanes"-Ergebnis raus und somit scheint der Exchange nicht betroffen zu sein.

    Getestet auf Exchange 2016 mit aktuellem CU auf Deutsch. Kollege von einer anderen Firma konnte das auch nochmal bestätigen.

  10. Robert sagt:

    Kurzes Update: es tut sich was bei Microsoft…

    Es wurde ein Powershell Script von MS released, welches alles automatisch macht: https://microsoft.github.io/CSS-Exchange/Security/EOMTv2/

    Ausserdem hat MS nun die Sache mit den RegEx endlich korrigiert und hat nun auch die Absicherung ERWEITERT: betrifft nicht mehr nur das Virt. Dir. Autodiscover, sondern MS wendet die URL Rewrite nun auf die KOMPLETTE Default WebSite an: https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/
    (Doku wurde aktualisiert)
    Das o.a. neue Script macht die Absicherung auch für die komplette Default WebSite.
    So, jetzt aber ab ins 'lange' Wochenende ;)

  11. Gero sagt:

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

  12. Alex sagt:

    Die Regex Rewrite URL kann umgangen werden.
    Siehe dazu die Aktualisierung von GTSC: https://web.archive.org/web/20221026020832/https://www.gteltsc.vn/blog/warning-new-attack-campaign-utilized-a-new-0day-rce-vulnerability-on-microsoft-exchange-server-12715.html

    Damit ist die Empfehlung gegeben auf foldende RegEx Rewrite URL umzustellen:
    ".*autodiscover.json.*Powershell.*" ohne Anführungszeichen

Schreibe einen Kommentar zu Robert Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.