Exchange Extended Protection aktivieren (CVE-2024-21410)

Exchange Extended Protection ist mittlerweile in aller Munde. Vor allem auch deswegen, weil es momentan den einzigen wirksamen Schutzmechanismus gegen die Sicherheitslücke CVE-2024-21410 (NTLM Hash Authentifizierung) darstellt. Aber auch abseits davon ist die Exchange Extended Protection eine empfohlene Vorkehrung, die man innerhalb von On-Premises Umgebungen unbedingt aktivieren sollte. Da man diese Funktion allerdings nicht ohne etwaiger Evaluierung einschalten sollte, schauen wir uns in diesem Beitrag die notwendige Vorbereitung an.

Vorbereitung

Unterstützte Exchange Versionen

Für folgende Exchange Versionen kann Extended Protection aktiviert werden:

Alle Exchange Versionen: Exchange Server

Installiert man auf einem Exchange 2019 das aktuellste CU (CU14), wird automatisch die Extended Protection aktiviert. Administratoren müssen also im Vorfeld prüfen, ob es dabei zu Problemen kommen kann und falls ja, Vorkehrungen treffen. Wer das Feature nicht aktivieren möchte, kann dies während des Updates auf CU14 deaktivieren.

SSL Offloading nicht unterstützt

Das könnte in einigen Umgebungen wohl die schmerzhafteste Voraussetzung darstellen. Exchange Extended Protection kann nicht aktiviert werden, wenn ein Loadbalancer oder eine WAF (Web Application Firewall) den Traffic mittels SSL Offloading an den Exchange weiterreicht. Falls dir das Keyword „SSL Offloading“ auf Anhieb nichts sagt, möchte ich das kurz konkretisieren.

In einigen Umgebungen terminiert der Exchange Traffic nicht direkt am Exchange Server, sondern auf einem Loadbalancer (z.b. Kemp) davor. Der Loadbalancer übernimmt dabei nicht nur die Rolle der Lastverteilung (falls mehrere Exchange Nodes im Einsatz sind), sondern entschlüsselt/verschlüsselt auch den Traffic zwischen Loadbalancer und Client. In manchen Fällen findet die Kommunikation zwischen Loadbalancer und Exchange anschließend unverschlüsselt statt. So ein Szenario nennt man „SSL Offloading„. Möchte man Exchange Extended Protection aktivieren, wird genau dieser Aufbau nicht unterstützt.

In so einem Fall muss die Umgebung auf „SSL Bridging“ umgebaut werden. Dabei terminiert der Traffic zwar weiterhin am Loadbalancer und wird dort entschlüsselt, allerdings werden, sobald die Datenpakete vom Loadbalancer an den Exchange Node weitergereicht werden, diese mit dem gleichen Zertifikat erneut verschlüsselt. Entscheidend dabei ist, dass unbedingt  sowohl am Exchange, als auch am Loadbalancer das gleiche Zertifikat verwendet werden muss. Unterschiedliche Zertifikate (bspw. einer internen PKI für den Exchange) werden nicht unterstützt.

Bevor man also an die Aktivierung von Exchange Extended Protection denkt, muss dieser Punkt unbedingt vorab geprüft werden.

Mindestens TLS 1.2

Damit Exchange Extended Protection aktiviert werden kann, wird mindestens TLS 1.2 vorausgesetzt. Das bedeutet, dass die mittlerweile veralteten Protokolle TLS 1.0 & TLS 1.1 deaktiviert werden müssen. Im Normalfall sollte diese Deaktivierung zu keinen Probleme führen, außer es befinden sich alte und nicht mehr durch Updates unterstützte Clients im Netzwerk (z.b. Windows Server 2008 oder Windows 7). Sollte das bei dir der Fall sein, können die IIS- & SMTP-Logs nach den verwendeten TLS Versionen vorab überprüft werden.

Wie man bei Exchange auf TLS 1.2 setzt und veraltete Cipher Suites deaktivieren kann, habe ich in diesem Artikel bereits näher erklärt.

NTLMv2 vorausgesetzt

NTLMv1 oder gar LM sollten innerhalb der Active Directory Umgebung ohnehin nicht mehr zum Einsatz kommen und bereits durch einen Administrator deaktiviert worden sein (warum, erkläre ich hier). Wer diese Vorkehrung noch nicht getroffen hat, sollte sich abseits dieser Umstellung ebenfalls zeitnah darum kümmern. Durch die Aktivierung von Exchange Extended Protection können sich Clients, welche nach wie vor auf NTLMv1 setzen, sich nicht mehr am Exchange authentifizieren. Moderne Clients verwenden bevorzugt aber ohnehin schon NTLMv2 und daher sollte es in einer relativ aktuellen Umgebung zu keinen Problemen kommen. Selbst Windows 7 unterstützt bereits NTLMv2.

Aber wie bereits zuvor kurz angerissen: Falls LM & NTLMv1 nicht unbedingt benötigt werden, solltest du diese veralteten Protokolle mittels GPO deaktivieren und somit die Angriffsfläche der Umgebung minimieren.

Public Folder Limitierungen

Keine Sorge, Public Folder werden auch weiterhin mit Extended Protection funktionieren, allerdings nicht unter den folgenden Bedingungen:

• Public Folder dürfen nicht auf einem Exchange 2013 gehostet werden, wenn sich in der Umgebung auch noch Exchange 2016/2019 Nodes befinden. In so einem Fall müssen die Public Folder Postfächer zuerst auf die neueren Nodes migriert werden.
• Nodes, die eine Public Folder Hierarchie Mailbox hosten, müssen mindestens folgende Version haben:
  • Exchange 2016 CU23
  • Exchange 2019 CU12

Exchange Hybrid und Modern Hybrid

Ich bin nach wie vor der Meinung, dass man seine Exchange Hybrid Umgebung nicht auf „Modern Hybrid“ aufbauen sollte, wer dies allerdings getan hat, kann Extended Protection nicht aktivieren. Normalerweise sollte das auch gar nicht notwendig sein, denn meist wählt man Modern Hybrid nur, wenn der Exchange von außen ohnehin nicht erreichbar ist.

Umsetzung

Aktivieren

Nachdem alte Verschlüsselungsprotokolle deaktiviert wurden und wir sichergestellt haben, dass wir kein SSL-Offloading betreiben, können wir in diesem Kapitel Extended Protection aktivieren. Wer das Exchange 2019 CU14 Paket installiert, muss nichts weiter tun. Alle anderen müssen Extended Protection manuell einschalten. Hierzu gibt es zwei Wege:

• Extended Protection über die IIS Manager pro IIS Site aktivieren (siehe dazu Exchange Server support for Windows Extended Protection)
• Mittels PowerShell Script aktivieren

Um Fehler zu vermeiden, greifen wir das auf das PowerShell Script von Microsoft zurück. Dabei werden alle Exchange Nodes auf Verfügbarkeit getestet und EP anschließend flächendeckend ausgerollt. Das bedeutet, auch wenn man einen Cluster betreibt, muss das Script nur auf einem Node ausgeführt werden.

Dazu muss das Script zuerst von der Microsoft Github Website heruntergeladen und auf einen Exchange Node kopiert werden. Anschließend reicht es aus, das Script in einer Powershell mit administrativen Berechtigungen mittels „.\ExchangeExtendedProtectionManagement.ps1“ aufzurufen:

Dabei geht das Script wie folgt vor:

1. Es wird auf allen Exchange Nodes überprüft, ob sie den Mindestanforderungen entsprechen (CU, TLS-Version, SSL Offloading deaktiviert)
2. Anschließend wird ein Backup der aktuellen IIS Config erstellt
3. Zum Schluss wird auf den IIS die Option Extended Protection aktiviert

Es ist kein weiterer Neustart der Exchange Nodes notwendig.

Deaktivieren

Sollte man nach der Aktivierung von Extended Protection feststellen, dass sich Clients nicht mehr mit dem Exchange verbinden können, kann die Funktion mit dem Parameter „DisableExtendedProtection“ wieder deaktiviert werden. Dazu muss das Script wie folgt aufgerufen werden: „.\ExchangeExtendedProtectionManagement.ps1 -DisableExtendedProtection„

Fazit

Auch wenn das Aktivieren von Extended Protection einige Voraussetzungen mit sich bringt, sollten Administratoren trotzdem nicht darauf verzichten. Abgesehen davon, dass EP momentan der einzige Schutzmechanismus gegen CVE-2024-21410 ist, gelten Verschlüsselungsprotokolle wie TLS 1.0 / TLS 1.1 als veraltet und sollten ohnehin nicht mehr verwendet werden. Auch NTLMv1 sollte man domänenweit mittels GPO deaktivieren.