ProxyNotShell: Workaround lässt sich einfach umgehen

von

Die Exchange Mitigation EM1, welche am Wochenende durch Microsoft veröffentlicht wurde, dichtet die Exchange Zero-Day Schwachstelle ProxyNotShell (CVE-2022-41040) nur unzureichend ab und lässt sich einfach umgehen. Problem ist ein „@“ Zeichen im Reg-Ex Pattern, welches die Regel zu sehr präzisiert. Durch leichte Anpassungen lässt sich somit die Reg-Ex umgehen. Somit wird die Regel nicht mehr angewendet und die Schwachstelle trotzdem ausnutzen:

ProxyNotShell: Workaround lässt sich einfach umgehen

Microsoft hat bisher keine aktualisierte Version der Regel per Exchange Mitigation verteilt, daher sollte zusätzlich zur von Exchange Mitigation konfigurierten Regel, wieder eine eigene Regel erstellt werden.

Die Regel kann nach diesem Artikel konfiguriert werden, jedoch muss das Pattern angepasst werden:

.*autodiscover\.json.*Powershell.*
ProxyNotShell: Workaround lässt sich einfach umgehen

Die eigene Regel sieht dann wie folgt aus:

ProxyNotShell: Workaround lässt sich einfach umgehen

Auch das von Microsoft veröffentlichte Script zum Installieren von URL Rewrite und Konfiguration der Regel, weißt noch das falsche Pattern auf:

Microsoft Script

Von Microsoft gibt es aber eine neue Empfehlung: RemotePowerShell sollte für alle nicht administrativen Benutzer abgeschaltet werden. Leider ist in der Standardeinstellung RemotePowerShell für alle Benutzer erlaubt:

Get-User | ft name,RemotePowerShellEnabled
Disable-RemotePowerShell

Wenn man nun also RemotePowerShell für alle Benutzer deaktiviert, dann haben es alle neu erstellten Benutzer wieder aktiviert. Ich habe daher ein kleines Script erstellt, welches RemotePowerShell bei allen Benutzern deaktiviert, außer bei Mitgliedern einer bestimmten AD-Gruppe:

#Allowed AD Group for RemotePowerShell:
$AllowedGroup = "AllowRemotePowerShell"


$AllUsers = get-mailbox -resultsize Unlimited | Get-User -ResultSize Unlimited | select SamAccountName,RemotePowerShellEnabled | where {$_.RemotePowerShellEnabled -eq $true}
$AllowedUsers = Get-ADGroupMember $AllowedGroup -Recursive | ForEach-Object {Get-User -Identity $_.SamAccountName | select SamAccountName,RemotePowerShellEnabled}

#Enable RemotePowerShell for allowed Users
foreach ($AllowedUser in $AllowedUsers) {
	if ($AllowedUser.RemotePowerShellEnabled -eq $False) {
		Set-User $AllowedUser.SamAccountName -RemotePowerShellEnabled $true
	}
}

#Disable RemotePowerShell for all Users
foreach ($User in $AllUsers) {
	if ($AllowedUsers.SamAccountName -notcontains $User.SamAccountName) {
		Set-User $User.SamAccountName -RemotePowerShellEnabled $false
	}
}

#Display RemotePowerSthell State
$RemotePowerShellState = get-mailbox -resultsize Unlimited | Get-User -ResultSize Unlimited | select SamAccountName,RemotePowerShellEnabled
$RemotePowerShellState

Das Script könnte beispielsweise zyklisch per Windows Aufgabenplanung ausgeführt werden, in diesem Fall wird RemotePowerShell für alle Mitglieder der Gruppe „AllowRemotePowerShell“ aktiviert und für alle anderen Benutzer deaktiviert (Das Script muss in einer administrativen Exchange Management Shell gestartet werden)

Das Script konnte ich bisher nur in meiner Testumgebung testen und mit der „heißen Nadel gestrickt“, daher ist Vorsicht geboten. Ich habe das Script auch auf GitHub veröffentlicht, falls jemand mitwirken möchte:

Disable RemotePowerShell for all users except Active Directory Group
https://github.com/FrankysWeb/Disbale-RemotePowerShell
1 forks.
5 stars.
0 open issues.

Recent commits:

Aktuell ist noch kein Sicherheitsupdate für die ProxyNotShell Schwachstelle veröffentlicht worden. Es heißt also weiter warten, bis die Schwachstelle endgültig geschlossen wird. All diese Maßnahmen sind nur als Workaround gedacht und sollten daher sorgfältig geprüft werden.

51 Gedanken zu „ProxyNotShell: Workaround lässt sich einfach umgehen“

  1. Ja, ja, wer lesen kann…

    Habe die Postings von NL vom 05.10. und von NorbertFe ebenfalls vom 05.10. zur Kenntnis genommen.

    Geht gleich wieder viel besser… ;-)

    Antworten

  3. Moinse zusammen,

    nun wollte ich mal wieder ein paar Clients einrichten, aber ich bekomme die Outlook.Profile nicht
    eingerichtet. Selbst am Exchange-Server klappt es mit dem Outlook nicht. (Es steht eine verschlüsselte
    Verbindung mit Ihrem E-Mail-Server zur Verfügung)

    Kann es sein, daß die Autodiscover-Funktion mit diesem Workaround komplett außer Gefecht gesetzt ist?

    Es besteht durchaus die Möglichkeit, daß ich etwas missverstanden oder falsch konfiguriert habe…

    Vielen Dank im Voraus für Eure Einschätzung!

    Viele Grüße

    Marcus

    Antworten

  4. Vielen Dank,

    Ich denke ich habe meine Frage nicht vollständig formuliert. Werden diesen Systemusern ebenfalls die RemotePowershell rechte entzogen? Wäre dies ein Problem und wie verhindere ich das. In der AD kann ich Diese user gar nicht auswählen um diese in die Ausnahme gruppe aufzunehmen.

    Viele Grüße

    Christian

    Antworten

  5. Hallo,
    ich vielen Dank erst ma für das Script.
    Was ist eigentlich mit den Usern „krbtgtg“ oder „Exchange Online-ApplicationAccount“ usw.
    Werden solche Accounts nicht von Exchange benötigt?
    können diese mit deaktiviert werden ohne dass es einen Einfluss auf die Funktionalität von Exchange hat?

    Vielen Dank schon mal für die Antworten.

    Viele Grüße

    Christian

    Antworten

  6. Es wurde ein neuer Regex von Microsoft veröffentlicht:

    (?=.*autodiscover\.json)(?=.*powershell)

    Dieser soll nicht mehr umgehbar sein. Laut Microsoft…

    Grüße

    Antworten

      • Tja, da hast du die letzten 10 Änderungen von Microsoft verschlafen.

        Anfang der Woche wurde der String wieder auf (?=.*autodiscover)(?=.*powershell) geändert…

        Muss ja nicht alle hier posten ;)

        Antworten

  12. MS ist schon wieder zu spät, oder denkt nicht ’so weit‘ wie die anderen…
    …dass man auch daran denken sollte, dass der String encoded sein könnte ;)

    RegEx: .*autodiscover\.json.*Powershell.*
    Condition: {UrlDecode:{REQUEST_URI}}

    Wird wohl wieder mehr als 24h dauern, bis MS sich da wieder mit dem autom. Rollout der neuen Rule bequemt… **TRAURIG** !!

    Antworten

  15. Ich habe nochmal ne Frage.

    @Franky: Was ist der Grund dafür, dass du in deinem Skript $AllUsers nur mit Usern befüllst, die auch über eine Mailbox verfügen?
    Müsste man das nicht für alle AD-User deaktivieren, die keine administrativen Tätigkeiten an Exchange durchführen müssen?!

    Ich hätte jetzt eher Get-ADUser erwartet oder bin ich da auf dem Holzweg?

    Antworten

      • Hey Bent,

        das würde mich auch interessieren.
        Wir nutzen einen Hybrid Exchange welcher selber keine Mailboxen hostet.
        Das Script hat bei mir keinerlei Auswirkung.

        Ich habe jetzt prophylaktisch allen Usern bis auf wenigen Admins die RemotePowershell via get/set-user disabled.

        Antworten

        • Wenn ich die RemotePowershell via Exchange Management Shell OnPrem deaktiviere, ist diese auch nur OnPrem deaktiviert.

          In der ExchangeOnline Shell sehe ich weiterhin mit „get-user | fl RemotePowerShellEnabled“ das der User auf „true“ steht.
          -> das kann auch default vorerst so bleiben.

          Mir hat es jedenfalls die Erkenntnis gebracht, dass der Befehl „Set-User -Identity XX -RemotePowerShellEnabled $false“ nur einen Impact auf die jeweilige Instanz hat, sprich, führt man diesen OnPrem in der ExchangeManagementShell aus, wird die Remoteshell für den User auch nur OnPrem deaktiviert.

    • Das wüsste ich auch gern – ich könnte es mir so vorstellen, dass sich nur User, die auch eine Mailbox haben, überhaupt sinnvoll an der Remote Powershell authentifizieren können um etwas zu tun. Aber das konnte ich bisher noch nicht prüfen – über Rückmeldung von franky dazu würde ich mich sehr freuen.

      Antworten

  16. Achtung!
    Wurde zuerst manuell die Rewrite Regel mit @ und anschließend eine weitere Rewrite Regel ohne @ hinzugefügt funktioniert der Autodiscover nicht mehr (HTTP 500) wenn Exchange Mitigation die erste Regel automatisch anpasst. Exchange Mitigation passt die Regel mit @ an auf den Wert ohne @ und somit gibt es zwei gleiche Regeln. Es muss dann die zweite Regel gelöscht werden. Diese heißt meistens „RequestBlockingRule1“. Man erhält im Fehlerfall auch im IIS unter Default Website –> Autodiscover –> URL-Rewrite eine Fehlermeldung.

    Das Ergebnis ist reproduzierbar wenn man wieder eine zweite Regel ohne @ erstellt.
    Dann antwortet der Autodiscover wieder mit HTTP 500, löscht man die zweite Regel wieder funktioniert es wieder.

    Antworten

    • Die mußt du nicht löschen, sondern nur umbenennen in bspw. „RequestBlockingRule2“. ;) Danach kannst du dann die ursprüngliche Regel im /autodiscover löschen.

      Antworten

  17. Hallo und danke für das Skript,

    ähhhm, was müsste man denn machen wenn die Gruppe versehentlich einen Tippfehler hat und jetzt niemand mehr Zugriff auf die PowerShell hat?

    Antworten

    • Da es ja lediglich um die RemotePowerShell Berechtigung geht, solltest lokal auf dem Exchange-Server im Ordner „ExchangeServer\v*\bin“ die Datei „exshell.psc1“ (PowerShell Konsolendatei) öffnen können.

      Darin kannst für den benötigten administrativen User mit dem Befehl
      „Set-User „BenutzerName“ -RemotePowerShellEnabled $true“
      die RemotePowerShell Berechtigung wieder erlauben.

      Antworten

  18. Noch eine Verständnisfrage. MS schreibt im Remote PS Blog folgendes: „By default, all user accounts have access to remote PowerShell. However, to actually use remote PowerShell to connect to an Exchange server, the user needs to be a member of a management role group, or be directly assigned a management role that enables the user to run Exchange cmdlets.“

    Das bedeutet für mich: ja, alle User können standardmäßig remote PS benutzen, aber um es effektiv zu dürfen, müssen sie in einer entsprechenden Management Gruppe Mitglied sein, z.B. „Organization Management“.

    Wenn das so stimmt, dann sollte es genügen die Gruppen zu prüfen und etwaige non-admin User zu entfernen. Bei mir ist bspw. nur der Administrator in manchen Gruppen gelistet. Gibt es eine Möglichkeit es zu testen?

    Antworten

  19. Ich las gerade folgende Info „Exchange Remote PowerShell wird mittels IIS bereitgestellt und ist nicht zu verwechseln mit PowerShell Remoting (Port 5985/5986).“

    Bedeutet also, dass ich theoretisch beides unterbinden muss?
    Es wird ja auf unterschiedlichen Seiten zu dem Thema mal geraten die PS-Remoting Ports per FW zu sperren und auf anderen (u.a. MS selbst) wird geraten Remote PowerShell für nicht-administrative User zu deaktivieren.

    Was ist jetzt der richtige Weg?

    Antworten

  20. was ich noch gerne wissen würde: reicht nun der eintrag von MS und kann der benutzerdefinierte eintrag unter autodiscover wieder gelöscht werden oder besser drinnen lassen auch wenn der @ dabei steht?
    danke

    Antworten

  21. Muss dieser Workaround auch beim Exchange 2013 durchgeführt werden oder nur die Regel im autodiscover beim URL Rewrite + mit Anpassung ohne das „@“.

    Antworten

  22. Hallo,

    MS hat per Exchange Mitigation wohl den neuen RegEx verteilt. Bei einem unserer Server war es heute morgen noch falsch und bei allen weiteren die ich geprüft habe schon korrigiert.

    Antworten

  23. Ich war kurz davor, den folgenden Befehl auszuführen:

    Get-User | Set-User -RemotePowerShellEnabled $false

    Dan habe ich aber gelesen, dass die Remote Powershell selbst dann benötigt wird, wenn man die EAC oder die Shell LOKAL auf dem EX-Server öffnen will (was ich immer so mache). Ich würde mich mit dem Befehl also selber aussperren. Ist das zutreffend?

    „Remote PowerShell access is required to open the Exchange Management Shell or the Exchange admin center (EAC), even if you’re trying to open the Exchange Management Shell or the EAC on the local Mailbox server. “

    (Quelle: https://learn.microsoft.com/en-us/answers/questions/1033895/disable-remote-powershell-for-exchange.html)

    Antworten

    • Ja, zutreffend!

      Ich habe über folgenden Einzeiler für alle Benutzer einer OU die Remote Powershell deaktiviert:
      Get-User -OrganizationalUnit „OU=Standard,OU=Benutzer,DC=XXX,DC=XX“ -ResultSize Unlimited -Filter ‚RemotePowerShellEnabled -eq $true‘ | Set-User -RemotePowerShellEnabled $false

      Da ich die Admins in einer anderen OU habe, war das der einfachste Weg.

      Antworten

  24. Das von Microsoft bereitgestellte Script EOMTv2.ps1 enthält jetzt auch das neue Pattern ohne das „@“.
    Danke für die wertvolle Hilfe hier im Blog!

    Antworten

  26. Das Disable-RemotePowerShell Skript (Name bei GitHub ist auch falsch geschrieben) funktioniert nicht, wenn ein Benutzername so anfängt wie ein anderer Benutzer.

    Set-User : The operation couldn’t be performed because ‚XXX‘ matches multiple entries.

    Antworten

Schreibe einen Kommentar