[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.
Anzeige
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 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.
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
Anzeige
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?
Nene, siehst Du imho richtig.
Ich war auch von den Microsoft-Screenshots verunsichert und habe das einfach mal getestet. So weit ich das hier sehe, zieht das erwartungsgemäß nur als Regexp an.
Müssen die Anführungszeichen nicht weg? Nur .*autodiscover\.json.*\@.*Powershell.* ?
Ja ohne " "
.*autodiscover\.json.*\@.*Powershell.*
Haben wir auch getestet und kann bestätigen, dass die Regel von Microsoft nicht zieht.
Exchange Server Zero-Day Schwachstelle wird aktiv ausgenutzt
Danke für den Link auf den Artikel von Frank Zöchling – Frank erklärt die Vorgehensweise zum Schutz vor dem Angriff ja Schritt-für-Schritt mit Screenshots.
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
Das müsstest Du MS fragen – die sind aber wohl wieder einmal kalt erwischt worden und sehen momentan kein Land mehr. Offenbar gibt es da keine Lösung, die man über die auch im Blog-Beitrag Exchange Server September 2021 CU kommt zum 28.9.2021 mit Microsoft Exchange Emergency Mitigation Service Lösung als Regeln ausrollen kann – kommt aber vielleicht noch – wir werden sehen.
Zumal der URL Rewrite erst mit der Einführung der Exchange Mitigations quasi zur Pflicht wurde. Würde mich nicht wundern, wenn die Erweiterung auf vielen Systemen nicht einmal vorhanden ist, weil sich keiner gekümmert hat.
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
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
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
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.
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 …
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
.* 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
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!
Diese Beschreibung ist perfekt inkl. Testscripts und weiterführende Infos
https://www.alitajran.com/0-day-vulnerability-microsoft-exchange/
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?
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.
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 ;)
Guten Morgen,
auf unserem 2016er hat der EM-Service heute Nacht die Regel auf der Default Web Site automatisch erstellt.
Na endlich….
Ja, ENDLICH hat MS durch den Exchange Server Emergency Mitigation Service ( EMS-Infos gibt es hier: https://techcommunity.microsoft.com/t5/exchange-team-blog/new-security-feature-in-september-2021-cumulative-update-for/ba-p/2783155 ) die URL Rewrite Rule automatisch an alle teilnehmenden Exchange Server (2016 / 2019) ausgerollt.
Beim manuellen Eintrag der URL Rewrite Rule erhält man beim Testen -wie gewüncht und eingetragen- einen Error 403 zurück. Durch die per EMS autom. gesetzte neue Rule, erhält man nun den folgenden Fehler: ERR_HTTP2_PROTOCOL_ERROR
Also nicht wundern ;)
Danke für die Hinweise – ich habe einen Nachtragsartikel Neues zur Exchange Server 0-day-Schwachstelle ZDI-CAN-18333: Korrekturen, Scripte und EP-Lösung mit einer Übersicht/Zusammenfassung veröffentlicht.
Kann ich bestätigen.
PS C:\Program Files\Microsoft\Exchange Server\V15\Scripts> .\Get-Mitigations.ps1
Server : EXMB1
Version : Version 15.1 (Build 2507.6)
ID : M1.1
Type : UrlRewrite
Description : Mitigation of CVE-2022-41040 via a URL Rewrite configuration.
Status : Applied
Die vom EMS erstellte URL Rewrite Regel "EEMS M1.1 PowerShell – inbound" wurde direkt auf der Default Web Site erstellt und hat als Action Type "Abort Request" und benutzt korrekt "Regular Expressions".
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