Extended Protection

Im Aug 2022 hat Microsoft Updates für kritische Lücken in Exchange 2016/2019 released, die aber nicht durch die Installation des Updates gestopft werden. Sie müssen manuell noch die Konfiguration hinsichtlich Extended Protection anpassen.

Die Funktion Extended Protection (EP) ist eigentlich eine Windows IIS-Thematik und schon seit 2009 verfügbar. Die Aktivierung ist aber mit dem Exchange Aug 2022 Updates erforderlich, um zusammen mit dem Update entsprechende Lücken zu schließen.

Offizielle Quellen

Wer genau den Exchange Team Blog Artikel liest, kann die relevante Zeile finden:

Addressing some of CVEs released this month requires admins to enable Windows Extended protection on your Exchange servers
Quelle: https://techcommunity.microsoft.com/t5/exchange-team-blog/released-august-2022-exchange-server-security-updates/ba-p/3593862

Das kleine Wort "require" wird dabei gerne überlesen. Es bedeutet aber, dass ohne die Aktivierung von "Windows Extended Protection" die Lücken noch nicht geschlossen sind und allein die Installation der Updates nicht ausreicht. Auch aus dem "Flussdiagramm" ist eigentlich gut zu sehen, dass die Aktivierung von "Windows Extended Protection" erforderlich ist.

Warum auch immer, scheint dies bei vielen Administratoren aber nicht angekommen zu sein. Um die Einrichtung abzuschließen, hat das Exchange Team sogar ein kleines Skript samt Warnung bereitgestellt:

To help you enable this feature, we have developed a script for this process. Please carefully evaluate your environment and review all known issues mentioned in the script documentation before enabling Windows Extended protection on your Exchange servers.
The current version of this script can be found at https://aka.ms/ExchangeEPScript and the documentation is at https://aka.ms/ExchangeEPDoc.
Quelle: https://techcommunity.microsoft.com/t5/exchange-team-blog/released-august-2022-exchange-server-security-updates/ba-p/3593862

Und es kommt noch eine weitere Warnung dazu:


Quelle: https://techcommunity.microsoft.com/t5/exchange-team-blog/released-august-2022-exchange-server-security-updates/ba-p/3593862

Wenn ich es richtig sehe, brauchen alleine 5 von 6 CVEs die Aktivierung von Extended Protection, damit die Lücken geschlossen sind.

... And it is not mandatory to enable Extended Protection, but we recommend that you work to do so. The CVEs that refer to it will not be addressed until Extended Protection is enabled. But there is no "time requirement" here.
Quelle: Nino Bilic, Microsoft: https://techcommunity.microsoft.com/t5/exchange-team-blog/released-august-2022-exchange-server-security-updates/bc-p/3595407/highlight/true#M33555

Welche CVE-Lücken erst durch die Aktivierung von "Extended Support" abgesichert werden, können Sie im CVE nachlesen. Nach meiner Recherche am 25. Aug 2022 waren dies

Das kann sich aber auch ändern, wenn Microsoft die Updates überarbeitet.

Was ist Extended Protection?

Wenn ein Client eine HTTPS-Verbindung zu einem Webserver aufbaut und dann über die verschlüsselte Verbindung sich anmeldet, dann sollte diese Kommunikation eigentlich sicher sein. Dennoch gibt es das Risiko eines "Man in the Middle (MITM)"-Attacke, wenn sich der Angreifer z.B. ReverseProxy dazwischenschaltet. Klingt schwer aber ist es nicht, denn genau genommen sind Fiddler und Co auch solche Tools und genauso könnte eine lokale Malware die Verbindung aufbrechen.

Um dies zu verhindern, wird mit Extended Protection auch eine Information aus dem "äußeren TLS-Kanal" verknüpft. Vereinfacht nutzt der Webserver eine Information aus dem Webserver-Zertifikat, um bei der Windows Anmeldung einen weiteren Faktor zu addieren. Diese Information hat der Angreifer nicht und kann daher die Anmeldung nicht simulieren, da der Client ja nur das Zertifikat des Angreifers sieht. Extended Protection ist daher keine Funktion von Exchange sondern eine Einstellung der Authentication pro virtuellem Verzeichnis im IIS.

Die Funktion gibt es nur für die Anmeldung mittels "Windows Authentication", d.h. Kerberos, NTLM aber nicht Basic, OAUTH oder andere Anmeldeverfahren. Sie sichert daher keine Anmeldungen ab, wenn Sie OWA über eine Formularanmeldung nutzen. Die beiden Hyperlinks gehen zu.

Wenn ein Client eine Verbindung zu einem Server aufbaut, könnte ein Angreifer sich einmal zwischen die beiden Systeme platzieren und als Relay, ReverseProxy,, NAT-Router alle Pakete mitschneiden und ggfls. sogar aufbrechen und damit mitlesen. Ein zweiter Angriff basiert darauf dass der Angreifer übertragene Pakete einfach noch mal überträgt und die Endstellen das nicht bemerken. Wenn z.B. das Anmeldeverfahren zwar an sich verschlüsselt ist aber die Kennwort immer mit dem gleichen Schlüssel geschützt werden, dann kann ich eine "Replay-Attacke" fahren.

Diese und andere Schwächen können abgesichert werden, indem Challenge-Response-Verfahren und Abhängigkeiten mit dem Zertifikat auf dem Backend einbezogen werden. Der IIS kann z.B. Informationen nutzen, die in seinem Zertifikat eh vorhanden und das Gegenstück "öffentlich" ist. Das macht es aber einem Angreifer unmöglich oder scher schwer, solche Verbindungen zu übernehmen, denn er hat das Wissen nicht. Allerdings hat so ein erweiterter Schutz auch Einschränkungen wie:

  • NTLMv1
    Diese schwache Anmeldefahren sollten Sie sowieso nicht nutzen aber mit Extended Protection kann es nicht mehr genutzt werden.
  • SSL Offloading/SSL-Bridging
    Wenn sie einen Reverse Proxy oder Layer-7-Loadbalancer vor dem IIS platzieren, der die HTTPS-Verbindung aufbricht, dann funktioniert dies nur dann, wenn auch auf der inneren Verbindung HTTPS mit dem genau gleichen Zertifikat zum Einsatz kommt. Sie müssen als auch den internen Verkehr wieder verschlüsseln. ein "Offloading" der Verschlüsslung ist nicht möglich.
  • Kompatible Clients mit "Required"
    Der Schutz wirkt ab besten, wenn er auch erzwungen wird, da sonst ein dazwischengeschaltetes System ja vorgeben kann, dass der Client oder der Server kein Extended Protection könnten. Mit dem Zwang sperren Sie aber alte Clients aus, die mit Extended Protection nichts anfangen können.

Das Feature wurde von Microsoft schon im August 2009 im Rahmen eines "Non Security Updates" bereitgestellt. Die meisten Webserver sollten es also können aber es wurde nicht per Default aktiviert. Es obliegt dem Anwendungsentwickler, bei der Installation seiner Lösung auf einem IIS die Konfiguration entsprechend anzupassen. Windows 7 Clients und Windows 2008R2-Server haben die Funktion schon an Bord.

Da könnte natürlich schon fragen, warum das Exchange Team diese Einstellung nicht schon viel früher zum "Standard" gemacht hat und erst jetzt nach ca. 13 Jahren den Support in Exchange dafür bereitstellt.

Checkliste

Sie könnten nun fragen, warum Microsoft mit der Installation der Updates nicht auch gleich mit aktiviert. Das wäre aber keine gute Idee, denn es gibt schon einige Abhängigkeiten, die Microsoft publiziet.

Hier meine Zusammenfassung und Ergänzungen aus anderen Quellen:

Prüfung Erledigt

Exchange Minimalversion

Die Aktivierung von Extended Protection betrifft nicht nur die Frontend-Server, sondern alle Server. Ehe Sie daher die Funktion aktivieren, müssen alle Server in der Topologie den folgenden Stand haben.

  • Exchange Server 2013 CU23
  • Exchange Server 2016 CU22
  • Exchange Server 2019 CU11 oder höher mit August 2022 Security Updates installed

Aktivieren Sie nicht Extended Protection auf älteren Exchange Servern.

Public Folder auf Ex2016 CU22 / Exchange 2019 CU11 oder älter

Aktualisieren Sie die Server zuerst auf die aktuelle Version (Exchange 2016 CU23 / Exchange 2019 CU12 + Security updates).

Public Folder auf Exchange 2013 Public Folder Koexistenz

Ein Zugriff auf öffentliche Ordner über Exchange 2013 ist nicht mehr möglich. Migrieren Sie die öffentlichen Ordner auf einen Exchange 2016/2019 Server. Wenn Sie nur Exchange 2013-Server haben, können Sie das SSL-Kennzeichen auf dem "RPC virtual directory" im IIS des Backend Servers entfernen.

Modern Hybrid

Sie können keine "Modern Hybrid"-Bereitstellung mit Extended Protection betreiben. Sie müssen den Server ausfindig machen, der vom Microsoft bereitgestellten Proxy für den Zugriff auf EWS genutzt wird und bei der Konfiguration ausschließen oder nachträglich die Einstellungen auf dem EWS zurückstellen.

Um die Sicherheit zu verbessern, sollte der Hybrid Server dann keine Postfächer hosten und auch sonst nur von den Hybrid Agenten erreichbar sein.

Keine Azure App Proxy Veröffentlichung

Wenn Sie z.B. OWA über den Azure AD Application Proxy veröffentlichen, dann funktioniert dies mit xtended Protection nicht mehr, da der App Proxy wie ein Layer-7-Loadbalancer die SSL-Verbindung terminiert und nach innen neu aufbaue. SSL-Bridging ist zwar erlaut, aber nur wenn die Zertifikate überall gleich sind. Laut Nino Bilic (Microsoft) soll das nichts gehen.

That is correct - it will not work; that is exactly why Hybrid Agent (aka Modern Hybrid) does not work with Extended Protection; because it is an Azure App Proxy.
https://techcommunity.microsoft.com/t5/exchange-team-blog/released-august-2022-exchange-server-security-updates/bc-p/3596373/highlight/true#M33591

NTLMv1

Die Absicherung des Server mit Extended Protection verhindert eine Anmeldung per NTLMv1. Wenn alle Client auch NTLMv2 oder neuer können, dann stört es nicht. Es ist aber ein Problem für Clients, die nur NTLMv1 können oder per Richtlinie auf NTLMv1 gezwungen werden oder wenn Sie auf dem Server, warum auch immer, NTLMv1 erzwingen.

Sie "müssen" NTLMv1 nicht abschalten aber der Zugriff auf Exchange geht dann einfacn nicht mehr per NTLMv1-Only-Clients.
Die Abschaltung von NTLMv1 sollten sie schon lange vollzogen haben. Nun gibt es einen Grund mehr.

Retention Policies mit Tags die eine "Move"-Aktion ausführen

Diese Funktion würde dann nicht mehr funktionieren. Microsoft arbeitet daran. Ich gehe davon aus, dass der Prozess selbst auch per EWS auf den Server zugreift und hier noch Nacharbeiten erforderlich sind.

MAPI over HTTP-Probe auf Exchange 2013 geht auf "Fail"

Das "Self Monitoring" von Exchange im Rahmen von Exchange 2013 Managed Availability geht auf "Fail". Outlook kann sich dennoch verbinden und arbeitet weiter

Unterschiedliche TLS-Konfigurationen auf Exchange Servern

Es ist essentiell, dass alle Exchange Server hier z.B.: hinsichtlich der TLS-Version gleich konfiguriert sind. Seit längerem wird ja schon die Abschaltung von TLS 1.1 und älter empfohlen. Es könnte also sein, dass noch nicht alle Server "identisch" konfiguriert sind.

SSL-Offloading/SSL-Bridging

Damit Extended Protection funktioniert, darf ein vorgeschalteter Reverse Proxy, Loadbalancer etc. zwar die Verschlüsselung aufbrechen aber muss zum Backend ebenfalls mit dem gleichen Zertifikat verschlüsseln. SSL-Offloading ist nicht mögich.Es ist dabei sogar möglich, dass unterschiedliche TLS-Versionen zwischen Client<->HLB und HLB<->Exchange genutzt werden solange es das identische Zertifikat ist.

"Required" statt "Allow" auf /EWS oder /ExchangeServerActiveSync

Die Einstellung für Extended Protection darf auf diesen virtuellen Verzeichnisse nicht auf "required" stehen. Das Konfigurationsskript von Microsoft setzt diese korrekt aber vielleicht haben Sie sich bei der manuellen Anleitung verklickt.

Hybrid FreeBusy und Hybrid Migration

Die Cloud spricht dazu die veröffentlichten Exchange Frontend Servern an. Auf dem "/EWS"-Verzeichnis der veröffentlichten Frontend-Servern darf die Extended Protection aktuell nicht aktiviert sein.

If you are using Modern Hybrid or the Hybrid Agent enabling Extended Protection will cause Hybrid features like Free/Busy and mailbox migration to stop working. To resolve this issue, identify the hybrid servers that are published using Hybrid Agent and disable Extended Protection on the Front-End EWS endpoints for these servers.
Quelle: https://microsoft.github.io/CSS-Exchange/Security/Extended-Protection/

Offen

Ich habe noch keine Infos oder Tests zu den folgenden Konstellationen:

"Enhanced Security" ist ja eine IIS-Konfiguration und gibt es aber auch bei ADFS

3rd Party Programme

Wenn Sie andere Tools verwenden, die sich mit den Exchange OnPremises Servern per HTTP verbinden, dann sollten Sie nach dem Aktivieren von Extended Protection deren Funktion prüfen.

Aktivierung

Microsoft beschreibt auf https://microsoft.github.io/CSS-Exchange/Security/Extended-Protection/#enabling-extended-protection ausführlich, welche virtuellen Verzeichnisse wie zu konfigurieren sind. Es sind pro Exchange Server insgesamt 23 virtuelle Verzeichnisse im IIS mit je zwei Parametern (Extended Protection und SSLFlags) anzupassen. Das ist dann doch arbeitsintensiv und fehleranfällig. Microsoft hilft uns daher dabei, indem sie ein PowerShell-Skript bereitstellen, welches die Änderungen macht

Script
https://aka.ms/ExchangeEPScript
https://microsoft.github.io/CSS-Exchange/Security/ExchangeExtendedProtectionManagement/
https://github.com/microsoft/CSS-Exchange/releases/latest/download/ExchangeExtendedProtectionManagement.ps1

Aussetzungen für den Start des Skript sind:

  • Exchange Management Shell
    Der Start muss nicht auf einem Server selbst gestartet werden. Es muss nur die Exchange Management Shell vorhanden sind.
  • Elevated Shell
    Starten Sie die Shell als "Administrator"
  • "Organization Management"
    Der ausführende Benutzer muss zudem in der Gruppe "Organization Management" sein

Das Skript sucht am Anfang über Internet nach Updates, indem es die Datei "https://github.com/microsoft/CSS-Exchange/releases/latest/download/ScriptVersions.csv" herunterlädt. Wenn dies nicht möglich ist, sollten Sie selbst immer mal wieder nach einem Update schauen.

Achtung
Ältere Versionen des Skripts haben ohne Rückfrage direkt alle Exchange Server in der Organisation "gesichert", die es erreichen kann. Meine Version 22.08.24.1638 fragt vorab zumindest einmal:

Ich hätte das Skript so angelegt, dass es beim Start ohne Parameter nur ReadOnly den aktuellen Status anzeigt und erst bei Angabe eines Parameters die Änderungen durchführt.

Eine andere Rückfrage kann aber auch noch kommen: Das Skript ist digital signiert und wenn Sie auf ihren Server die Ausführung von Skripten beschränkt haben, müssen Sie die Ausführung erst betätigen.

[PS] C:\ExchangeEP>.\ExchangeExtendedProtectionManagement.ps1

Do you want to run software from this untrusted publisher?
File C:\ExchangeEP\ExchangeExtendedProtectionManagement.ps1 is published by CN=Microsoft Corporation,
O=Microsoft Corporation, L=Redmond, S=Washington, C=US and is not trusted on your system. Only run scripts from trusted
 publishers.
[V] Never run  [D] Do not run  [R] Run once  [A] Always run  [?] Help (default is "D"): d

Folgende Parameter sind möglich:

  • [string[]]$ExchangeServerNames = $null,
    Sie können eine Liste oder den Namen eines Exchange Servers angeben, auf den sich da Skript beschränken soll. Damit können Sie z.B. erst mal auf einem Server die Änderungen durchführen, den Sie aus der Verteilung genommen haben und mit Clients und einer HOSTS-Datei die Funktion prüfen.
  • [string[]]$SkipExchangeServerNames = $null,
    Das ist dann die umgekehrte Vorgabe mit der die einzelne Server ausschließen können, z.B. den Hybrid Server
  • [switch]$ShowExtendedProtection
    Damit werden die aktuellen Einstellungen angezeigt
  • [string]$InternalOption
    Microsoft schreibt dazu war nichts, aber im Skript sieht man, dass nur eine Variable "$SkipEWS=$true" gesetzt wird aber zumindest in der Version 22.08.24.1638 noch keine Auswirkung hat.
  • [string]$RollbackType
    Wenn Sie hier ein "RestoreIISAppConfig" angeben, dann versucht das Skript ein Rollback basierend auf vorher angelegten Sicherheitskopien.

Wenn Sie sich unsicher sind, dann würde ich das Skript zuerst mit "-ShowExtendedProtection" aufrufen. Er läuft dann die Server durch und zeigt nur die aktuelle Konfiguration an.

Die Ausgabe ist leider kein Objekt, welches in die Pipeline übergeben wird, sondern das Skript macht direkt die Formatierung als Tabelle und Ausgabe. Hier die fraglichen Zeilen im Code:

Gleiches passiert bei der Ausgabe der Registrierungsändernugen:

Das hat Microsoft etwas unglücklich gelöst. Ich hätte da wenigstens eine Weiche per Parameter angegeben, der eine Ausgabe in die Pipeline erlaubt. Das Skript dahingehend zu ändern ist zwar einfach, aber bricht zum einen die Signierung und überlebt das nächste Autoupdate nicht.

Die Änderungen sind dann wieder unspektakulär und landen erst einmal auf der Konsole.

Wer die Ausgaben protokollieren will, sollte vorher ein "Start-Transcript" machen. Allerdings legt das Skript auch Protokolldateien ab

Wenn Sie das Skript ohne Parameter aufrufen, dann wird die Konfiguration durchgeführt. Allerdings :prüft das Skript zur Sicherheit, ob die Voraussetzungen gegen sind.

  • Exchange Updates noch nicht installiert
  • SSL Offloading konfiguriert
  • TLS 1.2-Konfiguration in NET nicht gesetzt

    Siehe dazu auch TLS 1.2 Enforcement

Nur wenn es keine Blocker gibt, sieht es wie folgt aus:

Leider sieht man auch hier, dass die Ausgaben schon im Skript formatiert und ausgegeben werden.

Die Aktivierung/Deaktivierung von Extended Protection funktioniert ohne Neustart des Server o.ä. sondern wird nahezu sofort aktiv.

Die Änderungen erfolgen auch in der Application.config. Diese wird durch ein Exchange Updates in der Regel nicht überschrieben, d.h. nach einem Update müssen Sie EP nicht erneut aktivieren. Dennoch ist eine Kontrolle ratsam

Kontrolle

Analog zu dem Skript "ExchangeExtendedProtectionManagement.ps1" aktualisiert Microsoft auch das Prüfskript "HealthChecker.PS1". Es ist vielleicht keine schlechte Idee, danach einmal das Skript laufen zu lassen.

Dort wird dann auch direkt rot angezeigt, wenn Extended Protection nicht aktiv ist.

Es gibt also schon viele Hinweise von Microsoft, dass die Aktivierung von Extended Protection erforderlich ist

Weitere Links