Veröffentlichungshinweis: Dieser Beitrag entstand im Rahmen meiner Tätigkeit bei der SVA System Vertrieb Alexander GmbH. Er erschien zuerst im Blog FOCUS ON IT - Der Expertenblog der SVA am 27. September 2022.

Geschlossene Sicherheitslücken in Exchange Server

Mit dem Patch-Tuesday im August 2022 hat Microsoft auch einen neuen Sicherheitspatch (SU) für Exchange Server 2013, 2016 und 2019 herausgebracht.

Mit dem Installieren ist es aber - wie schon im Mai – nicht getan. Offiziell schließt der Patch sechs verschiedene Sicherheitslücken, wovon drei als kritisch eingestuft werden. Nach der Installation des Sicherheitsupdates wird allerdings nur eine Lücke mit der Einstufung Wichtig direkt geschlossen. Die restlichen Lücken benötigen darüber hinaus die Aktivierung der Extended Protection (EP).

Das Update steht für folgende Versionen von Exchange Server bereit:

• Exchange Server 2013 CU23
• Exchange Server 2016 CU22 und CU23
• Exchange Server 2019 CU11 und CU12

Aufgrund von geringeren Einschränkungen bei der Konfiguration von EP sollten Sie bei Exchange Server 2016 und 2019 erst auf das neueste Cumulative Update (CU) - 2022 H1 aktualisieren.

Was ist Extended Protection?

Der erweiterte Schutz für die Authentifizierung schützt gegen sog. Man-In-The-Middle (MITM)-Angriffe, bei denen die Anmeldeinformationen eines Clients von einem Angreifer abgefangen und an einen Server weitergeleitet werden.

Quelle: docs.microsoft.com (Abgerufen am 08.09.2022)

Die Ursprünge von EP versetzen uns fast in eine andere Zeit. Angekündigt wurde das Feature mit dem Patch Tuesday vom August 2009. Im selben Monat standen die entsprechenden Patches für Betriebssysteme ab Windows XP und Windows Server 2003 bereit. Zwischen der Einführung von Extended Protection in Microsoft Internet Information Services (IIS) und der Unterstützung in Exchange Server liegen somit 13 Jahre.

Der Hintergrund von EP liegt in der Vermeidung von Angriffen im Zuge der Authentifizierung. Es soll verhindert werden, dass sich Angreifende zwischen Client (bspw. Smartphone) und Server (bspw. Exchange) stellen können und die Authentifizierung im Namen des Clients durchführen. So hätte der Angreifende im Anschluss die gleichen Rechte wie der Client und könnte entsprechend auf Daten zugreifen.

Im Windows-Ökosystem unterstützen Clients zumeist automatisch EP. In Serveranwendungen muss die Unterstützung allerdings erst programmatisch eingefügt werden. Dies hat die Exchange-Produktgruppe mit dem SU nun nachgeholt. Was bleibt ist die Aktivierung, der wir uns mit diesen Zeilen widmen.

Voraussetzungen der EP-Aktivierung

Bevor EP für Exchange Server aktiviert werden kann, sind einige Voraussetzungen zu beachten. Diese werden nachfolgend kurz aufgeführt und basierend auf den offiziell bereitgestellten Informationen der Exchange-Produktgruppe erläutert.

Exchange Server Version

Für Exchange Server 2013 muss das aktuelle CU23 vorliegen. Bei Exchange Server 2016 und 2019 wird hingegen neben dem aktuellen CU auch das vorherige CU unterstützt. Bei Exchange Server 2013 ist zudem zu beachten, dass hier keine öffentlichen Ordner-Postfächer gehostet werden dürfen.

Im Falle von Exchange Server 2016 und Exchange Server 2019 müssen öffentliche Ordner-Postfächer, die die Hierarchie halten, in jedem Fall das neuste CU besitzen.

Tabelle 1: Für Extended Protection unterstützte Systemkonfigurationen - Angelehnt an https://microsoft.github.io/CSS-Exchange/Security/Extended-Protection/

Der erweiterte Support von Exchange Server 2013 endet bereits im April nächsten Jahres. Im Anschluss daran werden keine weiteren Sicherheitspatches mehr bereitgestellt. Es bleiben also nur noch 6 Monate, um ein Update auf eine aktuellere Version durchzuführen.

Exchange Hybrid

Falls Exchange im Hybrid-Modus mit Exchange Online gekoppelt ist, gibt es ebenfalls eine Einschränkung zu beachten, sofern man auf eine der Modern Hybrid-Varianten setzt. In diesem Fall läuft ein Agent auf mindestens einem der Exchange Server, der die Notwendigkeit von eingehenden Verbindungen via geöffnetem Port ersetzt. Server mit dem Agenten müssen dann gesondert behandelt werden.

In diesem Fall ist es empfehlenswert, auf die Classic Hybrid-Varianten zu wechseln. Alternativ nennt Microsoft drei Schritte, um Server abzusichern, auf denen der Agent läuft:

1. Eingehende Verbindungen zu Exchange Servern sollten via Firewall auf Server begrenzt werden, auf denen der Hybrid-Agent läuft.
2. Es sollten keine Postfächer auf Server gehostet werden, welche einen Hybrid-Agenten haben. Bestehende Postfächer sollten zu anderen Servern umgezogen werden.
3. EP kann für alle virtuellen Verzeichnisse aktiviert werden, bis auf das EWS-Verzeichnis im Frontend.

Kryptografie

TLS-Versionen

Die TLS-Versionen 1.0 und 1.1 gelten als veraltet und unsicher. Diese sollten daher in jedem Fall abgeschaltet werden. Die EP-Unterstützung ist allerdings trotzdem für die Versionen TLS1.0, TLS1.1 und darüber hinaus für TLS1.2 vorhanden. Für TLS1.3 gilt dies aktuell nicht, da Exchange Server dies bisher in keiner Version unterstützt. Für die Aktivierung von EP muss die TLS-Konfiguration auf allen Servern gleich sein. Die aktivierten Versionen dürfen sich pro Server also nicht unterscheiden.

.NET SchUseStrongCrypto und SystemDefaultTlsVersions

Abhängig von der .NET Version, die von den Exchange Binaries verwendet wird, wird ohne explizit gesetzte Registrierschlüssel ein unterschiedliches Verhalten hinsichtlich des verwendeten TLS-Protokolls angewendet. Entsprechend sollten die Registrierschlüssel explizit für .NET 4.x und .NET 3.5 gesetzt werden, mindestens jedoch für .NET 4.x.

SSL Bridging und Offloading

SSL Offloading, also das Terminieren der TLS-Verschlüsselung an einer vorgeschalteten Station (bspw. dem Loadbalancer) wird nicht unterstützt.

SSL Bridging, das Terminieren der TLS-Verschlüsselung bei anschließender Neuverschlüsselung, wird nur unterstützt, wenn von allen Stellen dasselbe Zertifikat verwendet wird. Es besteht also keine Möglichkeit, am Loadbalancer zu intern ausgestellten Zertifikaten zu wechseln.

NT LAN Manager (NTLMv1)

NLTMv1 gilt ebenfalls als schwach bzw. angreifbar. Entsprechend sollte NTLMv1 grundsätzlich in der kompletten IT-Infrastruktur abgeschaltet werden. Hierzu besteht auch die Möglichkeit, zentral die Anmeldung via NTLMv1 zu überwachen und entsprechende Alt-Anwendungen zu patchen.

Sobald EP aktiviert wird, funktionieren Anmeldungen an Exchange Server mit NTLMv1 nicht mehr. Eine Konfigurationsänderung ist nicht nötig, obwohl sie zu empfehlen ist. Die Konfiguration kann über Gruppenrichtlinien oder die lokale Sicherheitsrichtlinie erfolgen: Die Einstellung “Netzwerksicherheit: LAN Manager-Authentifizierungsebene” sollte auf “Nur NTLMv2-Antworten senden. LM & NTLM verweigern” gesetzt werden (Weiterführende Informationen zu LAN Manager).

Abbildung 1: Einstellungspunkt für die Deaktivierung von NTLMv1

Abbildung 2: Empfohlene Einstellung bei der Konfiguration der LM-Authentifizierungsebene

Dritthersteller Applikationen

Der Markt für Anwendungen, die mit Exchange Server interagieren, ist riesig. Entsprechend divers werden die Produkte auch in Exchange Server eingebunden. Sofern Anwendungen also mit Exchange über die Web-Schnittstellen wie bspw. EWS oder OAB kommunizieren, muss damit gerechnet werden, dass die Produkte ggf. nicht mehr funktionieren. Sofern der Hersteller keine Informationen bereitstellt, lässt sich dies nur durch entsprechendes Testen in einer Testumgebung oder nach der Umstellung im Produktivsystem erproben. Betroffen sind z.B. Sicherheitslösungen auf Endgeräten, die clientseitiges TLS-Bridging betreiben. In den meisten Fällen lässt sich die URL der Exchange Server hier auf eine Ausnahmeliste setzen.

Bekannte Probleme

Passwortabfragen bei Outlook

Sollte es vermehrt zu Passwortabfragen kommen, kann dies an der Einstellung für NTLM liegen. In diesem Fall sollte auf allen Exchange Servern “Netzwerksicherheit: LAN Manager-Authentifizierungsebene” mindestens auf “Nur NTLMv2-Antworten senden.” angehoben werden.

Archivierungsrichtlinie

Aufbewahrungstags mit der Anweisung “In Archiv verschieben” sind aktuell nur mit einem Workaround funktionsfähig. Hierbei wird das EWS-Backend auf die IP-Adressen der anderen Exchange Server zugangsbeschränkt. Mit einem künftigen Sicherheitsupdate soll dieser Workaround aufgelöst werden. Bei zukünftigen Updates sollten also die Patchnotes beachtet werden. In diesen wird auch darauf hingewiesen, dass der Workaround zurückgebaut werden kann.

Test-OutlookConnectivity

In allen Exchange-Server-Versionen kann das Cmdlet Test-OutlookConnectivity für folgende Testmodule fäschlicherweise “fehlgeschlagen” zurückmelden, obwohl bis auf das Testmodul alles funktional ist:

1. OutlookMapiHttpCtpProbe
2. OutlookRpcCtpProbe
3. OutlookRpcDeepTestProbe
4. OutlookRpcSelfTestProbe
5. ComplianceOutlookLogonToArchiveMapiHttpCtpProbe
6. ComplianceOutlookLogonToArchiveRpcCtpProbe

An einem Fix wird seitens Microsoft gearbeitet.

Fragebogen / Checkliste

Abschließend soll folgende Checkliste nochmal der Überprüfung aller nötigen Voraussetzungen dienen. Sofern eine Frage mit Ja beantwortet wurde, sollten Sie sich mit dem entsprechenden Punkt genauer beschäftigen bzw. die Voraussetzungen schaffen, damit EP aktiviert werden kann.

Tabelle 2: Fragebogen zur sicheren Aktivierung von Extened Protection bei Exchange

Skriptbasierte Konfiguration der Extended Protection

Prüfung des aktuellen Zustands

Gerade bei größeren Umgebungen sind die manuelle Konfiguration und Überprüfung eine mühselige Aufgabe. Microsoft stellt deshalb mit dem Skript ExchangeExtendedProtectionManagement.ps1 eine Möglichkeit bereit, die entsprechenden Aufgaben so weit wie möglich automatisch durchzuführen. Um den aktuellen Zustand von EP in der Exchange Server Farm zu überprüfen, lässt sich das Skript von der Exchange Management Shell als Administrator wie folgt aufrufen:

.\\ExchangeExtendedProtectionManagement.ps1 -ShowExtendedProtection

Im Anschluss wird für jedes virtuelle Verzeichnis der aktuelle Zustand ausgegeben. Zusätzlich bietet auch das HealhChecker Skript entsprechende Prüfungen an. In diesem Falle muss das Skript aber auf jedem Server separat ausgeführt werden, um ein vollständiges Bild zu erhalten.

Aktivieren von Extended Protection

Analog zur Überprüfung lässt sich das Skript auch zur Konfiguration der EP verwenden. Hierbei kann das Skript im Regelfall ohne weitere Parameter aufgerufen werden. Im Anschluss muss die Durchführung der Konfiguration allerdings noch einmal bestätigt werden.

Abbildung 3: Sicherheitsabfrage bei der skriptbasierten Konfiguration von Extended Protection

Danach sollte auch das HealthChecker-Skript bestätigen, dass die Server nicht mehr von den entsprechenden Sicherheitslücken betroffen sind.

Abbildung 4: Ausgabe des HealthChecker-Skripts, wenn alle bekannten Sicherheitslücken gepatched sind.

Sonderfall mit Archivierungsrichtlinie

Wenn wie zuvor beschrieben eine Archivierungsrichtlinie vorhanden ist, müssen in einer Datei zuerst alle IP-Adressen der Exchange-Server eingetragen werden. Hier sind IPv4, IPv6 sowie die Eintragung von Subnetzen (in CDIR Notation, bspw. 10.100.5.1/24) erlaubt.

Abbildung 5: Datei mit den IP-Adressen aller Exchange-Server der Umgebung

Im Aufruf des ExchangeExtendedProtectionManagement-Skripts muss diese dann hinterlegt werden, um die Funktionalität von Archivierungsrichtlinien aufrechtzuerhalten.

.\\ExchangeExtendedProtectionManagement.ps1 -RestrictType \'EWSBackend\' -IPRangeFilePath \'C:\\tmp\\ExchangeServerIPs.txt\'

Sonderfall Modern Hybrid

Im Falle von Modern Hybrid müssen Server mit Agenten von der Konfiguration von EP ausgenommen werden.

.\\ExchangeExtendedProtectionManagement.ps1 -SkipExchangeServerNames HybridServer1, HybridServer2

Rollback

Falls nach der Aktivierung doch noch unvorhergesehene Probleme auftreten, unterstützt auch hier das Skript, indem die IIS-Konfiguration von vor der Änderung zurückgespielt werden kann.

Achtung: Sollten zwischen Aktivierung und Rollback der EP manuelle Änderungen an der applicationHost.config vorgenommen worden sein, so müssen diese im Anschluss erneut angewendet werden. Sobald die entsprechenden Probleme beseitigt wurden, lässt sich EP mit dem Skript erneut aktivieren.

Fazit

Mit der Unterstützung von Extended Protection in Exchange sichert Microsoft die Server besser gegen Man-In-The-Middle-Angriffe ab. Aktuelle Einschränkungen machen allerdings die Verwendung von Workarounds nötig. Diese müssen bei zukünftigen Updates berücksichtigt und ggf. wieder zurückgebaut werden.