Exchange kritische Sicherheitslücke
Zwei Sicherheitslücken zwingen uns Administratoren wieder zur Umsetzung eines Workarounds.
Über diese Sicherheitslücken CVE-2022-41040 & CVE-2022-41082 gelingt es einem Angreifer, aber erst nach erfolgter Authentifizierung, die Ausführung von “Remote Code Execution). Betroffen sind gepatchte und ungepatchte Systeme.
Exchange Server 0-day-Schwachstelle CVE-2022-41040 & CVE-2022-41082
- Bei CVE-2022-41040 handelt sich um eine SSRF-Schwachstelle (Server-Side Request Forgery).
- CVE-2022-41082 ermöglicht dem Angreifer eine Remotecodeausführung (RCE) sofern er Zugriff auf PowerShell hat.
Angriffe unter Verwendung von Exchange-Schwachstellen vor der Veröffentlichung
MSTIC beobachtete im August 2022 Aktivitäten im Zusammenhang mit einer einzelnen Aktivitätsgruppe, die durch Verkettung von CVE-2022-41040 und CVE-2022-41082 in einer kleinen Anzahl gezielter Angriffe einen anfänglichen Zugriff erzielte und Exchange-Server kompromittierte. Diese Angriffe installierten die Chopper-Web-Shell, um den manuellen Zugriff über die Tastatur zu erleichtern, die die Angreifer für die Active Directory-Erkundung und Datenexfiltration verwendeten. Microsoft hat diese Angriffe in weniger als 10 Organisationen weltweit beobachtet. MSTIC schätzt mit mittlerer Sicherheit ein, dass es sich bei der einzelnen Aktivitätsgruppe wahrscheinlich um eine staatlich geförderte Organisation handelt.
Microsoft-Forscher untersuchten diese Angriffe, um festzustellen, ob es einen neuen Ausnutzungsvektor in Exchange gab, als die Zero Day Initiative (ZDI) im September 2022 CVE-2022-41040 und CVE-2022-41082 an das Microsoft Security Response Center (MSRC) weitergab.
Quelle:Microsoft
Exchange Server 0-day-Schwachstelle CVE-2022-41040 & CVE-2022-41082
Der von Microsoft gestellte Workaround lässt sich am besten per Skript umsetzen, so passieren keine Fehler beim Copy & Paste der benötigten Parameter.
Nach der Ausführung des Skripts findet ihr im IIS auf der “Default Web Site” unter URL Rewrite folgenden Eintrag.
Microsoft hat das Skript mehrfach nachgebessert (07.10.2022) und die Pattern von
.*autodiscover\.json.*\@.*Powershell.*
.*autodiscover\.json.*Powershell.* in
(?=.*autodiscover)(?=.*powershell)
geändert.
Das Bundesamt für Informationssicherheit (BSI) hat folgendes Dokument dazu veröffentlicht.
Neuer 0-Day Exploit in Microsoft Exchange Server. CSW-Nr. 2022-258168-1132, Version 1.1, 04.10.2022
Block Remote Powershell/WinRM Ports
Wer einen Schritt weitergehen möchte, der blockiert die Remote-Powershell-Ports:
- HTTP: 5985
- HTTPS: 5986
New-NetFirewallRule -DisplayName “Block Inbound Port 5985” -Direction Inbound -LocalPort 5985 -Protocol TCP -Action Block
New-NetFirewallRule -DisplayName “Block Inbound Port 5986” -Direction Inbound -LocalPort 5986 -Protocol TCP -Action Block
Alternativ mit einer Firewall-Regel:
New-NetFirewallRule -DisplayName “Block Remote Powershell Ports” `
-Direction Inbound `
-LocalPort 5985,5986 `
-Protocol TCP `
-Action Block
Oder einmalig per Remote:
Invoke-Command -ComputerName Exchange1 -ScriptBlock{
New-NetFirewallRule -DisplayName “Block Remote Powershell Ports” `
-Direction Inbound `
-LocalPort 5985,5986 `
-Protocol TCP `
-Action Block
}
Prüfen des Workarounds
Im Browswer ist folgender Pfad aufzurufen. Dieser sollte nach Möglichkeit fehlschlagen.
https://mail.windowspapst.de/Autodiscover/autodiscover.json@PowerShell
Invoke-WebRequest https:/mail.windowspapst.de/Autodiscover/autodiscover.json@PowerShell
Configure Powershell Remote Access
Set-PSSessionConfiguration -Name Microsoft.PowerShell -ShowSecurityDescriptorUI -Force
Es sollte jedoch bewusst sein, das diese Maßnahmen den Exchange in seiner Funktion einschränken können.