IIS Extended Protection

Mit Exchange 2019 CU14 wurden viele Administratoren aufgeschreckt, weil zur Abwehr der Lücke CVE-2024-21410 die Funktion "Extended Protection" aktiviert werden muss. Die Funktion ist aber Bestandteil des IIS seit Windows 2012R2 und wird von Microsoft nur als Text beschrieben. Ich wollte wissen, was Extended Protection genau ist und wie es nicht nur Exchange sondern auch andere Dienste absichern kann.

Beachte dazu auch CVE-2024-21410 Betrachtung und ergänzend IIS Extended Protection und Exchange Extended Protection

Hinweis: Extended Protection wurde März 2010 als Update mit Windows Server 2003 schon bereitgestellt.

Das Thema betrifft nicht nur Webserver, sondern ist auch mit LDAP (Siehe LdapEnforceChannelBinding) und anderen Protokollen aktiv, die gegen MITM-Angriffe besser gesichert werden müssen.

Worum geht es?

Wenn ein Client auf geschützte Daten auf einem Server zugreift, dann muss er sich Anmelden und um die Anmeldung als auch die Datenübertragung zu sichern, sollten solche Verbindungen per TLS verschlüsselt und signiert werden. Nun kann aber ein Angreifer den Client dazu bringen, die Anmeldedaten über ihn als Zwischenstation zu senden. Der Anwender merkt dies nicht immer und der eigentliche Server sieht nur eine legitime Verbindung des Angreifers. Dass die TLS-Verbindung nicht durchgängig ist, können beide nicht sehen. Durch Extended Protection wird erreicht, das damit kompatible Anmeldeverfahren mit Information aus dem Zertifikat gesichert werden. Da der Angreifer hoffentlich keinen Zugriff auf den privaten Schlüssel des Webservers hat, fällt der Angreifer in der Kommunikation auf, die Anmeldung ist nicht möglich und der Angreifer erhält keine Anmeldeinformationen.

"Extended Protection" ist ein zusätzlicher Schutz, der nur bei TLS-Verbindungen mit der "Windows integrierten Anmeldung (WIA)" möglich ist und vom Webserver erzwungen werden muss. "Extended Protection" gib es seit 2010 aber wurde nie der Default aktiviert oder erzwungen, da auch die Clients dies unterstützen müssen.

TLS allein ist nicht sicher

Eine Kommunikation zwischen einem Client und eine Server sollte immer verschlüsselt, signiert und beim Zugriff auf private Daten auch authentifiziert sein.

Die TCP-Verbindung sichert die Übertragung gegen verlorene Pakete ab und stellt die korrekte Reihenfolge sicher. Die TLS-Verbindung sorgt zum einen für eine Verschlüsselung der Daten aber erlaubt durch das Zertifikat "Zert1" dem Client auch, die Identität des Servers zu prüfen, da die angesprochene URL auch im Zertifikat enthalten sein muss. Es ist natürlich kein Schutz, wenn mit ein Angreifer schon eine "ähnliche" Domain unterschiebt.

Der TLS-Handshake funktioniert derart, dass der Client einen TLS-Hello mit den möglichen Chiffrierverfahren sendet und der Server sich möglichst das sicherste Auswählt und mit der Antwort auch sein Zertifikat mit dem Public-Key überträgt. Damit kann der Client mit einen Channel Binding Token verschlüsseln, den nur der Server mit dem passenden Privaten Schlüssel decodieren kann. So haben beide Endpunkte eine gemeinsamen Schlüssel für die schnellere und billigere symmetrische Verschlüsselung der Daten.

Über den sicheren Kanal kann ich nun sogar unsichere Anmeldeverfahren wie "BasicAuth", "Bearer-Tokens" oder Formulardaten übertragen und muss mich nicht drauf verlassen, dass die Anmeldung über "sichere" Verfahren wie z.B. NTLM oder Kerberos erfolgt. Auch diese Verfahren arbeiten wieder mit Channel Binding Token (CBT), um keine Kennworte zu übertragen.

Problematisch wird diese vermeintliche Sicherheit, wenn Sie die TLS-Verbindung auf dem Übertragungsweg aufbrechen. Dafür gibt es legitime und nicht legitime Gründe.

TLS aufbrechen: Proxy

Firmen möchten oder müssen übertragene Daten auf Angriffe, Malware oder Ziele überwachen. Da aber mittlerweile die meisten Webseiten per TLS erreichbar sind, können Firewalls auf dem Kabel nur noch die verschlüsselten Verbindungen sehen. Ab TLS 1.3 kann eine Filterlösung nicht mal mehr den angesprochenen Servernamen im "Client-Hello" prüfen. Daher setzen Firmen Proxy-Server im eigenen Netzwerk oder in der Cloud (Zscaler, Umbrella etc.) ein. Das funktioniert, weil hier der Administrator die Kontrolle über den Client hat und ihm sowohl den Proxy über eine Konfiguration (Gruppenrichtlinien oder WPAD) vorgeben kann, als auch eine eigene Zertifizierungsstelle als "Trusted" hinterlegen kann.

Der Client verbindet sicher per TCP bzw. TLS mit dem Proxy Server und startet dann einen "CONNECT Zielserver" Der Proxy leitet den Zugriff aber nicht direkt zum Ziel sondern generiert ein Zertifikat für das Ziel über die eigene PKI, die beim Client als vertrauenswürdig eingestuft ist. Die TLS-Verbindung wird beim Proxy Server aufgebrochen und der Server kann die übertragenen Daten sehen, prüfen und ggfls. blockieren.

Was in Firmen legitim ist, kann natürlich auch ein Entwickler mit Tools wie Fiddler auf seinem Computer zur Analyse nutzen. Kriminell wird es, wenn der Anwender auf einem "freien" PC, z.B. im Hotel oder Internet Cafe surft und der Betreiber das gleiche System zur Spionage aufgesetzt hat. Dann kann er auch "sehen", was der Anwender tut und unsicher übertragene Kennworte (BasicAuth, Formulare, NTLM-Hashwerte, Bearer-Tokens) abgreifen. Solche Systeme sind nicht schwer aufzusetzen. Daher gibt es schon länger z.B. DANE - DNS-Based Authentication of Named Entities, worüber Provider die Zertifikate ihrer Webserver veröffentlichen. So kann ihr Browser bei einem unerwarteten neuen Zertifikat sich melden. Dies hilft aber nicht auf fremden Computern.

Hier schützt Extended Protection oder MTLS

TLS aufbrechen: ReverseProxy

Auch auf der anderen Seite vor dem Webserver gibt es einen Bedarf die Verbindungen aufzubrechen. Mehrere Gründe lassen sich hier aufführen 

  • DoS-Schutz, Filterung
    So genannte "Web Application Firewalls" nehmen die guten und bösen Verbindungen aus dem Internet an und terminieren den TLS-Kanal. Die eingehenden HTTP-Anfragen der Clients werden auf diesen Systemen vorgefiltert. Der Reverse-Proxy kann z.B. die URL im Klartext sehen und die erlaubten Pfade eines Exchange Server (/OWA, /EWS, /Microsoft-Server-ActiveSync, /OAB) sind bekannt. Andere Zugriffe auf /ECP oder /PowerShell und Traversal-Attacken auf "../../../../Windows/cmd.exe" können direkt geblockt werden.
  • Portal/PreAuthentication
    Der Client kann auch direkt mit einem Anmeldedialog zur Authentifizierung aufgefordert werden. Viele Firmen veröffentlichen ihre Server über ein Portal, an dem sich der Anwender mit einer starken Authentifizierung anmelden muss, eher er dann auf die verschiedenen veröffentlichten Anwendungen zugreifen kann. Das funktioniert sehr gut mit interaktiven Zugriffen aber nicht mehr so gut mit mit z.B. ActiveSync oder MAPI/HTTP oder der Erreichbarkeit von Exchange für eine Hybrid-Bereitstellung (MRSProxy-Migration, Free/Busy-Zeiten
  • Lastverteilung/Verfügbarkeit nach Benutzer/Session
    Der letzte Aspekt ist die Verteilung der Zugriffe auf mehrere Server über einen Loadbalancer. Natürlich kann das auf Layer-4 (TCP) pro Connection erfolgen. Der Loadbalancer könnte aber auch den Anwender "kennen" und  alle seine Zugriffe über verschiedene parallel Verbindungen zum gleichen Server routen. Wenn er dazu TLS aufbricht (Layer-7) kann er auch weitere Header (X-Forwarded-For) addieren, damit der Backend-Server diese protokollieren kann.

In allen drei Fällen wird die TLS-Verbindung aufgebrochen:

Übrigens gilt dies auch für Reverse Proxy in der Cloud wie den Azure AD Application Proxy

Jegliches Aufbrechen reduziert aber die Sicherheit der übertragenen Daten, da Sie ja nicht wissen, wer da mitliest.

Der Einsatz von Extended Protection mit der Prüfung der Channel Binding Tokens erfordert natürlich den Einsatz von TLS. Unterschlüsselte Verbindungen sollten Sie daher generell nicht mehr erlauben, wenn eine Authentifizierung erfolgt.

So schützt Extended Protection

Sowohl beim TLS-Handshake als auch bei der Anmeldung werden Channel Binding Token (CBT) verwendet, die bislang aber nicht miteinander verknüpft waren. Wenn Extended Protection aktiviert wird, dann erzwingt der Webserver die Kopplung der beiden Schlüssel. Sowohl beim Aufbrechen der Verbindung durch einen ausgehenden Proxy als auch durch einen eingehenden Loadbalancer oder Reverse Proxy wird aber die TLS-Verbindung aufgebrochen.

Da jede TLS-Verbindung seinen eigenen Channel Binding Token zum Verschlüssel verwendet und dieser sogar während der Verbindung geändert werden kann, nutzen der Client als auch der Webserver in diesem Fall unterschiedliche Channel Binding Tokens (CBT). Wenn die Authentifizierung nun ebenfalls Channel Binding Token mit prüfen, fällt der Bruch direkt auf.

Extended protection enhances the existing Windows Authentication functionality to mitigate authentication relay or "man in the middle" attacks. This mitigation is accomplished by using security information that is implemented through two security mechanisms:
1. Channel binding information that is specified through a Channel Binding Token (CBT). This is used primarily for SSL connections.
2. Service binding information that is specified through a service principal name (SPN). This is used primarily for connections that do not use SSL or when a connection is established. For example, this might be in a scenario in which SSL is offloaded to another device, such as a proxy server or load-balancer.
Quelle: Description of the update that implements Extended Protection for Authentication in Internet Information Services (IIS) - Microsoft Support

Extended Protection wirkt bei verschlüsselten Verbindungen über das Channel Binding Token während bei unverschlüsselten Verbindungen der SPN genutzt wird. Da mittlerweile wohl die meisten Verbindungen per TLS verschlüsselt sind, beschränke ich mich bei der weiteren Beschreibung darauf

...Currently, when a client application authenticates itself to the server using Kerberos, Digest, or NTLM using HTTPS, a Transport Level Security (TLS) channel is first established and authentication takes place using this channel. However, there is no binding between the session key generated by Secure Sockets Layer (SSL) and the session key that is generated during authentication. ..

...The solution is to use a TLS-secured outer channel and a client-authenticated inner channel, and to pass a Channel Binding Token (CBT) to the server. The CBT is a property of the TLS-secured outer channel, and is used to bind the outer channel to a conversation over the client-authenticated inner channel. ...
Quelle: Extended Protection for Authentication Overview https://learn.microsoft.com/en-us/dotnet/framework/wcf/feature-details/extended-protection-for-authentication-overview

Der Abschnitt sagt aber indirekt auch, dass eine Anmeldung per BasicAuth, Formulare oder OAUTH-Tokens nicht mit Channel Binding Tokens abgesichert werden.

Das dürfte auch der Grund sein, warum ich einen per Extended Protection gesicherten Exchange 2019 Server über einen Azure AD Application Proxy weiter erreichen kann.

Umgekehrt dürfte eine Anmeldung per Client Zertifikat, Smartcard und damit auch Windows Hello auch ohne Extended Protection als sicher gelten, da hier auch der Client seinen privaten Key nutzt, den weder der ausgehende noch ein eingehender Proxy hat. EP kann aber nur funktionieren, wenn die Verbindung auch per TLS verschlüsselt ist. Sie sollten also einen unverschlüsselten Zugriff direkt unterbinden (Port 80 sperren) oder über einen Redirect umleiten.

Das spiegelt sich auch bei der Aktivierung von EP auf Exchange wieder, wo SSL Offloading erst abgeschaltet werden muss.

EP und Abhängigkeiten

Sie wissen nun, wie EP eine Anmeldung über eine TLS-Verbindung und Anmeldung mit der Kopplung von Channel Binding Tokens besser absichert. Der Einsatz von Extended Protection ist erforderlich, wenn Sie gegen Angriffe bezüglich CVE-2024-21410 abgesichert sein wollen. Dies vorgebliche Lücke liegt nämlich nicht im Exchange Code und kann daher dort auch nicht korrigiert werden, sondern in einer unsicheren Anmeldung mit Replay-Attacken durch NTLM-Tokens.

Ehe Sie aber nun Exchange Extended Protection einsetzen, gibt es einige Vorarbeiten sowohl auf dem Exchange Server als auch der Netzwerkinfrastruktur zu erledigen. Dass Sie eine Mindestversion von Exchange benötigen und weitere Abhängigkeiten mit öffentlichen Ordnern beachten müssen, hat Microsoft ausführlich beschrieben. Allerdings ist Exchange nicht das einzige System, welches nicht nur theoretisch angreifbar ist. Es könnte jede Applikation betreffen, die auf dem IIS aufsetzt, NTLM zur Anmeldung akzeptiert und ein Angreifer von einem legitimen Benutzer ein NTLMHash abgegriffen hat.

Sie müssen also die komplette Kette aus Client, ausgehenden Proxy, eingehenden Proxy, Loadbalancer etc. betrachten, denn wenn Sie auf dem letzten Server die Funktion "Extended Protection" aktivieren, dann kann dies die Funktion stören. Die TLS-Verbindung muss durchgängig vom Client zum Zielserver existieren und darf nicht aufgebrochen werden. Weder auf der Seite des Clients durch einen ausgehenden Proxy Server noch eingehend beim Ziel durch einen Loadbalancer. Nur dann funktioniert eine HTTPS-Verbindung über "Extended Protection".

Ihre Exchange Umgebung hat in der Regel eine der folgenden Konstellationen:

Ausgehender Proxy

Zuerst betrachten wir uns eine Verbindung zum Exchange Server, bei der ein HTTP-Proxy zum Einsatz kommt. Dies trifft im internen LAN meist nicht zu, aber wenn Sie Exchange Online nutzen oder z.B. einen fremden Client in einem Internet-Cafe oder einen "Cloud-Proxy" nutzen, dann kann das durchaus der Fall sein.

Szenario   Extended Protection

Öffentliche IP-Adresse

In dem Fall sollte es keine Probleme geben. Allerdings gibt es nur ganz wenige Clients, die eine öffentliche IPv4-Adresse haben. Bei IPv6 ist das aber der Regelfall

OK

Private Adresse mit NAT

Der Exchange Server ist per TCP direkt oder per NAT erreichbar. Der Client hat eine durchgängige TCP-Verbindung zum Server

OK

Ausgehender Transparenter Proxy

Der Client muss über einen HTTP-Proxy die Verbindung zum Exchange Server aufbauen. Der Proxy bricht die Verbindung aber nicht auf, sondern erlaubt einen PROXY CONNECT und schaltet den TCP-Stream transparent durch. Das ist auch ein Grund, warum Microsoft für einige Dienste ein "Optimization Required" fordert.

OK

Ausgehender Inspection Proxy

Der Client muss über einen HTTP-Proxy die Verbindung zum Exchange Server aufbauen. Der Proxy terminiert die SSL-Verbindung und baut sie selbst auf, um in die Daten reinzuschauen

Fail

Eingehender Proxy/Loadbalancer

Auf der Seite des Servers können unterschiedliche Zugänge denkbar sein.

Szenario   Extended Protection

Öffentliche IP

Firmen verstecken ihre Server gerne hinter privaten Adressen mit eingehendem NAT aber bei Internet Service Providern haben die Server in der Regel öffentliche IP-Adressen

OK

Eingehender L4-Proxy

Vor dem Exchange Server steht ein Loadbalancer oder eine Firewall, die TCP-Verbindungen auf mehrere Backend Server verteilt oder die Verbindung per NAT (Layer-4) umsetzt. Es ist eine transparente TCP-Verbindung

OK

Eingehender L7-Proxy Bridge 1 Zert

Eingehende Verbindungen werden von Web Application Firewall/Reverse Proxy/Loadbalancer mit dem gleichen Zertifikate terminiert, die auch der Exchange Server nutzt und dann zum Exchange Server wieder verschlüsselt.

OK

Eingehender L7-Proxy Bridge 2 Zert

Eingehende Verbindungen werden von Web Application Firewall/Reverse Proxy/Loadbalancer mit einem anderen Zertifikate terminiert, die auch der Exchange Server nutzt und dann zum Exchange Server wieder verschlüsselt. Das ist gar nicht so selten, dass intern auf dem Exchange Server z.B. Zertifikate einer internen PKI genutzt werden, weil sie billiger sein oder z.B. keine PKI einen Namen für eine ungültige DNS-Domain wie "ex01.firma.local" ausstellt.

Fail

Eingehender L7-Proxy Offload

Sie meinen es gut mit dem Exchange Server und ersparen ihm den SSL-Overhead, indem der Reverse Proxy die Verbindung unverschlüsselt weiterreicht.

Hinweis: Diese Konfiguration verhindert auch die Funktion des MRSProxy und damit eine Exchange Hybrid Migration. Für Outlook AnyWhere muss SSL Offloading abgeschaltet werden.

Fail

Abgesehen von noch einigen anderen Abhängigkeiten wie TLS-Konfiguration (TLS 1.2) und NTLMv1-Verzicht (Siehe Checkliste auf Exchange Extended Protection) wird die Aktivierung von Extended Protection nur funktionieren, auf dem Weg von Client zum Exchange sowohl beim ausgehenden als auch bei eingehenden Proxy eine unterstützte Konfiguration vorliegt. Letztlich ist das ja das Prinzip von Extended Protection, dass kein Proxy "reinschauen" und die Daten abgreifen oder verändern kann.

Ich habe noch nicht die Zeit gehabt zu prüfen, ob es es wirklich das "gleiche" Zertifikat sein muss oder ob nur der gleiche Privatekey genutzt werden kann.
In der RFC 5929 steht bei "tls-server-end-point' Channel Binding Type" https://www.rfc-editor.org/rfc/rfc5929.html#section-4, dass das komplette Zertifikat als Hashwerte genutzt wird.

Extended Protection mit Exchange und andere

Die Konfiguration von Extended Protection ist im Grund unabhängig von den verschiedenen Diensten, die auf dem IIS aufsetzen. Allerdings ist es immer sinnvoll auch den Hersteller zu fragen, ob Probleme bekannt sind und die Nutzung von EP möglich ist. Dies gilt insbesondere bei der Einstellung "Require", weil dann alle Clients auch EP unterstützen und Nutzen müssen.

Auch wenn "Extended Protection" schon im Jahr 2010 mit einem Update sogar für Windows 2003 bereitgestellt wurde, und auf jedem IIS7.5 und höher damit vorhanden ist, hat Microsoft erst im August 2022 für Exchange Server nicht nur die Freigabe sondern auch die Empfehlung für die Aktivierung gegeben. Im Februar 2024 wurde das Thema dann wieder hochgespült, weil eine Outlook Lücke oder andere MITM-Attacken damit auf Exchange zielen.

Wenn Sie EP aktiviert haben und die Konfiguration nicht passt, dann bekommt die Anwender mit z.B. Outlook immer wieder eine Kennwortbox, die selbst bei der Eingabe korrekter Anmeldedaten nicht funktioniert.

Allerdings ist das "Problem" einer Man in the Middle-Attacke ja nicht auf Exchange beschränkt, sondern genereller Natur für alle auf dem IIS aufsetzenden Dienste. Dazu gehören z.B. SharePoint OnPremises, WSUS, Skype for Business, ADFS und auch viele 3rd-Party-Lösungen, die als ASP/ASPX/PHP-Seite auf dem IIS laufen und die "Windows Authentifizierung" nutzen. Es betrifft aber auch andere Dienste wie LDAP, die ebenfalls TLS nutzen.

Einen Marktüberblick habe ich hier nicht und so kann ich ihnen nur raten, EP einfach einzuschalten und zu kontrollieren, welche Client über welche Authentifizierung die Dienste nutzen. Achten Sie darauf, dass wirklich auch NTLM zum Einsatz kommt und kein anderes Anmeldeverfahren.

Extended Protection und Clients

Damit Extended Protection überhaupt zum Einsatz kommt, muss die Windows Authentifizierung genutzt werden. Anmeldungen eines Clients per BasicAuth, Digest, FormBased oder Bearer sind nicht betroffen. Daher ist es in den meisten Fällen der Edge-Browser oder Anwendungen wie Outlook, die per HTTPS und NTLM auf OnPremises Dienste zugreifen.

Ich weiß, dass die aktuellen Microsoft Office Produkte und der Microsoft Edge Server auch Extended Protection unterstützen. Leider habe ich noch kein Übersicht zu anderen Produkten oder genauen Versionen gefunden. Aber aus Release Notes habe ich folgendes zusammengesucht.

Client Status Beschreibung und Links

Edge (Chromium)

  • Ich habe keine Quellen aber weiß, dass es funktioniere.

Chrome (Chromium)

 

Thunderbird

Ab Version 41 (2016)

Firefox

Ab Version 11 (2011)

Letztlich kommt es auf einen Versuch an.

Note: The Extended Protection authentication setting on Windows is used to configure Kerberos mutual authentication. In this type of authentication, to prevent a man-in-the-middle attack, the server authenticates to the client and the client authenticates the server. Windows 7 on Firefox doesn't support Extended Protection. If users use this client configuration disable Extended Protection in ADFS.
Quelle: Enabling Integrated Windows Authentication in Firefox  https://help.hcltechsw.com/domino/11.0.1/admin/secu_enabling_iwa_in_firefox.html

Extended Protection im IIS aktivieren

Für Exchange sollten Sie nicht direkt im IIS die Konfiguration ändern, sondern laut Beschreibung von Microsoft zuerst mit dem Exchange HealthChecker ihre Konfiguration prüfen und dann entweder durch die Installation von Exchange 2019 CU14 die Konfiguration anpassen lassen. Alternativ können Sie dies auch durch entsprechende PowerShell-Befehle durchführen.

Für alle anderen Fälle finden Sie die Einstellung im Bereich "Authentication" auf der Webseite und jedem virtuellen Verzeichniss. Von den verschiedenen Anmeldeverfahren ist die "Windows Authentication" und dann "Advanced Settings" zu wählen.

Hier können Sie drei Optionen auswählen:

  • Off
    Der Server bietet EP gar nicht an.
  • Accept
    Der Server bietet EP an und wenn es der Client nutzen möchte, ist es möglich. Ich bin nicht sicher, ob hier ein Proxy das Angebot unterdrücken könnte. Aber Accept ist aus meiner Sicht auch nicht sicher, da es ja nicht erzwungen wird.
  • Require
    Der Server erzwingt, die Verwendung von EP. Der Client muss es unterstützen und Proxy-Systeme dürfen nichts aufbrechen.

Microsoft stellt bei Exchange die EP-Funktion nicht bei allen Verzeichnissen ein, sondern nur solche, bei denen einen Zugriff per Windows Authentication möglich ist. Bei den anderen Verfahren ist es nicht möglich.

Ich habe bislang weder in Fiddler noch im Chromium Debugger einen Weg gefunden zu sehen, ob EP angeboten oder genutzt wird. Da es aber eine TLS-Erweiterung ist, wäre wohl Wireshark der bessere Ansatzpunkt.

Weitere Links