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:
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.
| Exchange Version | CU Version | SU Version | Öffentliche Ordner-Postfächer | EP unterstützt? |
| Exchange 2013 | CU23 | Aug. 2022 oder neuer | Nein | Ja |
| Exchange 2016 | CU22 | Aug. 2022 oder neuer | Keine Postfächer mit Hierarchie | Ja |
| Exchange 2016 | CU23 oder neuer | Aug. 2022 oder neuer | Alle | Ja |
| Exchange 2019 | CU11 | Aug. 2022 oder neuer | Keine Postfächer mit Hierarchie | Ja |
| Exchange 2019 | CU12 oder neuer | Aug. 2022 oder neuer | Alle | Ja |
| Alle anderen Versionen | Jedes andere CU | Jedes andere SU | Alle | Nein |
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:
- Eingehende Verbindungen zu Exchange Servern sollten via Firewall auf Server begrenzt werden, auf denen der Hybrid-Agent läuft.
- Es sollten keine Postfächer auf Server gehostet werden, welche einen Hybrid-Agenten haben. Bestehende Postfächer sollten zu anderen Servern umgezogen werden.
- 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).
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:
- OutlookMapiHttpCtpProbe
- OutlookRpcCtpProbe
- OutlookRpcDeepTestProbe
- OutlookRpcSelfTestProbe
- ComplianceOutlookLogonToArchiveMapiHttpCtpProbe
- 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.
| Ja | Nein | |
| Ist in Ihrer Umgebung ein Exchange Server 2013 vorhanden, welcher öffentliche Ordner-Postfächer [FC1] [MD2] hostet oder diese in Koexistenz mit 2016 oder 2019 betreibt? | ☐ | ☐ |
| Ist in Ihrer Umgebung ein Exchange Server 2016 Server mit CU 22 vorhanden, welcher öffentliche Ordner-Hierarchien hostet? | ☐ | ☐ |
| Ist in Ihrer Umgebung ein Exchange Server 2019 Server mit CU 11 vorhanden, welcher öffentliche Ordner-Hierarchien hostet? | ☐ | ☐ |
| Ist bei Ihnen Exchange Hybrid im Modus Modern (Modern Minimal oder Modern Full) eingerichtet? | ☐ | ☐ |
| Haben Sie vor Ihrer Exchange-Umgebung einen Loadbalancer oder eine Web Application Firewall (WAF) implementiert, welche „SSL-Offloading“ nutzt? | ☐ | ☐ |
| Haben Sie vor Ihrer Exchange-Umgebung einen Loadbalancer oder eine WAF, welche „SSL Bridging“ mit unterschiedlichen Zertifikaten auf LB/WAF und Exchange einsetzt? | ☐ | ☐ |
| Gibt es Inkonsistenzen in den Einstellungen für TLS auf den Exchange-Servern oder existieren Exchange Server, welche noch nicht explizit TLS 1.2 verwenden? | ☐ | ☐ |
| Haben Sie Drittanbieter-Software auf den Exchange-Servern installiert oder an diese angebunden, welche inkompatibel zu den verstärkten Sicherheitskonfigurationen sein könnte (bspw. Signatursoftware, Archivsysteme, u.s.w)? | ☐ | ☐ |
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 -ShowExtendedProtectionIm 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.
Danach sollte auch das HealthChecker-Skript bestätigen, dass die Server nicht mehr von den entsprechenden Sicherheitslücken betroffen 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.
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, HybridServer2Rollback
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.