atiilla/cve-2026-42897CVE-2026-42897 - Blinder Fleck des Exchange Health Checkers: ausgehende IIS-URL-Rewrite-Regeln werden stillschweigend ignoriert, wodurch EOMT-Schutzmaßnahmen in Diagnoseberichten unsichtbar bleiben.
Schweregrad: Mittel (CVSS 5.3)
Komponente: Microsoft CSS-Exchange - Diagnosetool HealthChecker
Betroffene Dateien:
Diagnostics/HealthChecker/Analyzer/Get-URLRewriteRule.ps1 (L49, L72, L97)Diagnostics/HealthChecker/Analyzer/Invoke-AnalyzerIISInformation.ps1 (L442–459)
Gemeldet: 2026-05-15
Anerkennung: Ursprüngliche Entdeckung durch den Forscher, der CSS-Exchange Issue #2539 gemeldet hat
Referenzen:Get-URLRewriteRule.ps1, Invoke-AnalyzerIISInformation.ps1Security/src/EOMT/Mitigations/CVE-2026-42897.ps1 (L147–254)Der Exchange Health Checker (HealthChecker.ps1) meldet IIS-URL-Rewrite-Regeln als Teil seiner Serverkonfigurationsprüfung. Die Regelenumerationsfunktion Get-URLRewriteRule.ps1 liest jedoch nur eingehende Regeln (system.webServer/rewrite/rules) und ignoriert stillschweigend ausgehende Regeln (system.webServer/rewrite/outboundRules).
Die EOMT-Mitigation (Exchange On-premises Mitigation Tool) für CVE-2026-42897 setzt eine Content-Security-Policy-Header-Injection-Regel namens EOMT OWA CSP - outbound als ausgehende IIS-URL-Rewrite-Regel um. Da der Health Checker outboundRules nie liest, ist diese Mitigationsregel in Health-Checker-Berichten vollständig unsichtbar.
Ein Exchange-Administrator, der sich darauf verlässt, dass der Health Checker bestätigt, dass EOMT-Mitigationen vorhanden sind, erhält einen Bericht, der keine ausgehende CSP-Regel zeigt - was zu einem falsch-negativen Ergebnis für den Mitigationsstatus führt und ein falsches Gefühl der Gefährdung oder umgekehrt ein falsches Vertrauen erzeugt, dass keine Mitigation angewendet wurde, obwohl eine vorhanden ist.
Drei verschiedene Codepfade in Get-URLRewriteRule.ps1 lesen ausschließlich aus .rewrite.rules:
Pfad 1 - Parsen von web.config (L49):
$rules = $content.configuration.'system.webServer'.rewrite.rules
Pfad 2 - applicationHost.config pro Standort (L72):
$rules = $location.'system.webServer'.rewrite.rules
Pfad 3 - applicationHost.config global (L97):
$rules = $ApplicationHostConfig.configuration.'system.webServer'.rewrite.rules
Keiner dieser Pfade greift auf .rewrite.outboundRules zu. Das zurückgegebene $rules-Objekt wird anschließend in Invoke-AnalyzerIISInformation.ps1 (L442–459) durchlaufen:
$displayRewriteRules = ($currentRewriteRules.rule | Where-Object { $_.enabled -ne "false" }).name |
Where-Object { $_ -notcontains $excludeRules }
Das .rule-Element ist nur in der eingehenden <rules>-Sammlung vorhanden. Selbst wenn outboundRules gelesen würden, müsste die Anzeigelogik aktualisiert werden, um .rule aus beiden Sammlungen zu durchlaufen.
IIS speichert die URL-Rewrite-Konfiguration mit zwei getrennten untergeordneten Elementen unter <rewrite>:
<system.webServer>
<rewrite>
<!-- inbound - what Health Checker reads -->
<rules>
<rule name="Redirect to HTTPS" enabled="true">
<match url=".*" />
<conditions><add input="{HTTPS}" pattern="^OFF$" /></conditions>
<action type="Redirect" url="https://{HTTP_HOST}/{R:0}" />
</rule>
</rules>
<!-- outbound - INVISIBLE to Health Checker -->
<outboundRules>
<rule name="EOMT OWA CSP - outbound" enabled="true">
<match serverVariable="RESPONSE_Content-Security-Policy" pattern=".*" />
<action type="Rewrite"
value="default-src 'self'; script-src 'self' 'unsafe-inline';
style-src 'self' 'unsafe-inline';" />
</rule>
</outboundRules>
</rewrite>
</system.webServer>
| Szenario | Auswirkung |
|---|---|
| Admin führt den Health Checker nach Anwendung von EOMT aus | Bericht zeigt keine ausgehende CSP-Regel → Admin glaubt, die Mitigation fehlt |
| Admin verwendet den Health Checker als einziges Audit-Tool | EOMT-Ausgangsregeln können nicht überprüft werden, ohne die IIS-Konfiguration manuell zu prüfen |
| Vorfallreaktion / Compliance-Prüfungen | Mitigationsnachweise fehlen in der Health-Checker-Ausgabe |
| Automatisierte Überwachung, die Health-Checker-JSON parst | Vorhandensein / Fehlen ausgehender Regeln wird nie sichtbar |
Siehe poc_cve_2026_42897.ps1 in diesem Verzeichnis.
Das Skript:
web.config-XML mit sowohl einer eingehenden Regel als auch der ausgehenden Regel EOMT OWA CSP - outbound..\poc_cve_2026_42897.ps1
Erwartete Ausgabe bei einem verwundbaren (ungepatchten) Health Checker:
[*] Vulnerable path (inbound only):
Rules found: Redirect to HTTPS
MISSING: EOMT OWA CSP - outbound
[*] Patched path (inbound + outbound):
Rules found: Redirect to HTTPS, EOMT OWA CSP - outbound
Outbound rule visible: TRUE
Korrektur in Get-URLRewriteRule.ps1 - beide Sammlungen an jedem Pfad lesen:
# web.config (L49)
$inbound = $content.configuration.'system.webServer'.rewrite.rules
$outbound = $content.configuration.'system.webServer'.rewrite.outboundRules
$rules = @{ inbound = $inbound; outbound = $outbound }
# applicationHost.config per-location (L72)
$inbound = $location.'system.webServer'.rewrite.rules
$outbound = $location.'system.webServer'.rewrite.outboundRules
$rules = @{ inbound = $inbound; outbound = $outbound }
# applicationHost.config global (L97)
$inbound = $ApplicationHostConfig.configuration.'system.webServer'.rewrite.rules
$outbound = $ApplicationHostConfig.configuration.'system.webServer'.rewrite.outboundRules
$rules = @{ inbound = $inbound; outbound = $outbound }
Korrektur in Invoke-AnalyzerIISInformation.ps1 - beide Sammlungen durchlaufen:
$displayRewriteRules = @()
$displayRewriteRules += ($currentRewriteRules.inbound.rule |
Where-Object { $_.enabled -ne "false" }).name |
Where-Object { $_ -notcontains $excludeRules }
$displayRewriteRules += ($currentRewriteRules.outbound.rule |
Where-Object { $_.enabled -ne "false" }).name |
Where-Object { $_ -notcontains $excludeRules }
| Datum | Ereignis |
|---|---|
| 2026-05-15 | Problem im Rahmen der Verifizierungsforschung zur EOMT-Bereitstellung identifiziert |
| 2026-05-15 | PoC geschrieben und gegen Mock-IIS-Konfiguration getestet |
NUR FÜR AUTORISIERTE SICHERHEITSFORSCHUNG. Testen Sie ausschließlich in kontrollierten Laborumgebungen.