Microsoft hat dieses Wochenende die URL Rewrite Regel, welche den erfolgreichen Angriff via ProxyNotShell verhindert, als Emergency Mitigation Regel ausgerollt. Damit sollten alle Exchange 2016 und Exchange 2019 Server mit dem Workaround ausgestattet sein. Dies gilt allerdings nur, wenn Exchange auf einem aktuellen Patchlevel ist und das Emergency Mitigation Feature aktiv ist. Für Exchange 2013 Server, muss die URL Rewrite Regel nach wie vor manuell konfiguriert werden. Für Exchange 20133 muss dazu zunächst auch das Modul „URL Rewrite“ installiert werden und die Regel konfiguriert werden.
Für Exchange 2013 findet sich hier das URL Rewrite Modul und ein Artikel wie die Regel konfiguriert wird:
Auf Exchange 2016 und Exchange 2019 Servern lässt sich mit folgendem Befehl prüfen, ob das Emergency Mitigation Feature aktiv ist:
Get-OrganizationConfig | fl MitigationsEnabled
Get-ExchangeServer | ft Name,MitigationsEnabled
Mit dem folgenden Befehl kann geprüft werden, ob die ProxyNotShell Mitigation auf den Exchange Servern angewendet wurde:
Get-ExchangeServer | Format-List Name,*Mitigations*
Sollte die Regel „M1.1“ nicht in der Liste der Applied Mitigation auftauchen, dann sollte einmal geprüft werden, ob der Exchange Server die folgende Webseite anzeigen kann:
Von dieser URL ruft der Dienst „MSExchangeMitigation“ jede Stunde die XML-Datei mit den entsprechenden Regeln ab. Zur ProxyNotShell (CVE-2022-41040) lautet der Name der Mitigation „M1“.
Falls die Regel nicht angewendet wurde, kann auch ein Blick in das MitigationService Logfile hilfreich sein:
Das Logfile findet sich unter im Pfad $Exinstall\Logging\MitigationService. Wer bereits schnell gehandelt hatte und eine eigene URL Rewrite Regel erstellt hatte, sollte die selbst erstellte Regel nun wieder löschen:
Die Regel, welche durch Microsoft veröffentlicht wurde, greift weiter, als die selbst erstellte Regel. Microsoft schaltet die URL Rewrite Regel auf die „Default Web Site“ und vererbt die Regel an alle Unterverzeichnisse. Die selbst erstellte Regel wurde nach den ersten Informationen zu dieser Zero-Day Schwachstelle nur auf dem Verzeichnis „Autodiscover“ angewendet.
Hier findet sich ein kleines Script, welches nach den IOC der ProxyNotShell Schwachstelle sucht:
Ein Sicherheitsupdate ist bisher nicht verfügbar, daher sollte sichergestellt werden, dass die URL Rewrite Regel konfiguriert ist.
Hallo Frank,
sollte man mittlerweile diese alte Regel wieder löschen? Bringt sie Nachteile? Ausgerollt wird sie ja nicht mehr, aber auch nicht automatisch entfernt.
Viele Grüße
Markus
Hallo Frank. Erstmal vielen Dank für die schnellen Infos.
Kleine Frage: Hat mir jemand einen Tipp wie ich vorgehen muss, dass EMS trotz Proxy rauskommt?
netsh winhttp scheint nicht zu funktionieren.
Das gleiche Problem habe ich auch. Der Mitigation Service kommt nicht raus, somit auch keine aktivierten Mitigations.
Hallo Jens,
wie sollte denn jetzt die Antwort aussehen?
Wenn ich den Test mit folgender URL „https://unserer.exchangeserver/autodiscover.json@notreallyevilpowershell“ & „https://unserer.exchangeserver/autodiscover.jsonnotreallyevilpowershell“ aufrufe erhalte ich :
Die Website ist nicht erreichbar
Die Webseite unter https://unserer.exchangeserver/autodiscover.json@notreallyevilpowershell ist eventuell vorübergehend nicht verfügbar oder wurde dauerhaft an eine neue Webadresse verschoben.
ERR_HTTP2_PROTOCOL_ERROR
Wir haben auf allen unserer Mailserver auch beide Regeln angewandt.
ACHTUNG: die Entdecker der Schwachstelle haben den RegEx-Teil angepasst auf: „.*autodiscover\.json.*Powershell.*“
MS hat da anscheinend noch nicht nachgezogen…
Laut den Entdeckern, konnte man anscheinend das ‚alte‘ RegEx-Pattern ‚umgehen‘ – man sollte daher zus. zu MS eine weitere eigene Regel am Start haben.
Auch das 403 wurde im Update 8 zun „Anforderung abbrechen“ umgestellt. Siehe den Original-Artikel: https://www.alitajran.com/0-day-vulnerability-microsoft-exchange/#h-block-known-attack-patterns-manual
Danke für die Info. Wer Kemp einsetzt, kann das natürlich auch dort umsetzen.
Dort kann man das dann im Virtual Service (entweder global oder per Sub-VS) und dem Pattern “ /.*autodiscover\.json.*Powershell.*/“ einfügen.
Der Kemp Artikel hat noch nicht die Aktuellsten Änderungen drin, aber das sollte man ja anpassen können:
https://support.kemptechnologies.com/hc/en-us/articles/9548819650701
Moin!
Auf Twitter empfiehlt oder weist man auf eine ergänzende Regel ({HTTP_COOKIE} containing Email=autodiscover) hin – keine Ahnung wie die dann aussehen müsste :(
Angepasst mit Anforderung abbrechen und RegEx Eintrag.
Keine extra neue Regel gemacht, die alte gelöscht und neu angelegt.
Sind jetzt weiterhin 2 drin, einmal die von MS und die selbst erstellte
Zur Info.
Wir haben cu11 mit August Patch, ohne Windows Extended Protection aktiviert.
Die Regel wurde trotzdem angewandt. Ich schätze es reicht wenn das Modul installiert ist, ohne kompletten Patchstand.
Hallo Jens,
Emergency Mitigation wurde mit CU11 eingeführt, daher hast du das Update erhalten. Auf einem Exchange 2013 würde nur die Installation des Moduls nicht reichen, da hier das Feature Emergency Mitigation nicht verfügbar ist.
Beste Grüße,
Frank