ProxyNotShell: Emergency Mitigation behebt Zero-Day Schwachstelle

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
ProxyNotShell: Emergency Mitigation behebt Zero-Day Schwachstelle

Mit dem folgenden Befehl kann geprüft werden, ob die ProxyNotShell Mitigation auf den Exchange Servern angewendet wurde:

Get-ExchangeServer | Format-List Name,*Mitigations*
ProxyNotShell: Emergency Mitigation behebt Zero-Day Schwachstelle

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:

ProxyNotShell: Emergency Mitigation behebt Zero-Day Schwachstelle

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.

10 Gedanken zu „ProxyNotShell: Emergency Mitigation behebt Zero-Day Schwachstelle“

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

    Antworten
    • 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

      Antworten
  2. 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.

    Antworten
  3. 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.

    Antworten
  4. 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.

    Antworten

Schreibe einen Kommentar