This month, Microsoft is releasing several non-security updates that implement Extended Protection for Authentication as a mechanism to help safeguard authentication credentials on the Windows platform. These new updates are not security bulletins, but non-security updates that allow web clients using the Windows HTTP Services, IIS web servers and applications based on the HTTP Protocol Stack (http.sys) to use this feature, which was initially released in August of 2009. After release, developers and administrators still need to take action to configure the feature. More information can be found in Security Advisory 973811.
Extended Protection for Authentication helps protect authentication credentials when using Integrated Windows Authentication. Practically, they prevent an attacker that is able to get access to these credentials through another attack, for instance by soliciting a client to connect to him through social engineering, to use these credentials to log into another server to which the client has access.
These types of attacks are not new, but can pose a risk in specific deployment scenarios. Hence, this month as well, we released Security Advisory 974926, which documents how these attacks work, and the different steps Microsoft has taken to help administrators prevent them from being exploited. These include various updates we and our industry partners have released in the past, and the release of the Extended Protection feature that hardens authentication credentials.
This blog aims to clarify what this new feature really does, and how an administrator can start using it.
Why Extended Protection for Authentication?
Microsoft released Extended Protection to allow applications to better safeguard the use of authentication credentials being transferred between a client and server when using Integrated Windows Authentication (IWA). IWA allows a client to authenticate to a server without exposing the user’s password to any potential eavesdropper, typically by using NTLM or Kerberos authentication protocols.
A certain type of attack, known as credential relaying, is possible when using IWA as deployed in certain scenarios. If an attacker manages to elicit a client to connect to him, that attacker could take advantage of the authentication mechanism and use it to authenticate against a third party server on which the client has an account with identical credentials. In addition, the attacker could even authenticate against a service running on the client itself. However, an attacker could never learn the user’s password.
What does Extended Protection for Authentication do?
Extended Protection for Authentication aims to prevent this type of credential relay. It does this by implementing a protocol based on RFC 5056, “On the Use of Channel Bindings to Secure Channels”.
EAP creates the ability for a client’s authentication to be tied to an outer security channel so that the client authentication only happens under the protection of that same outer channel. To see how this works, suppose the client wants to authenticate to a web site. Here we can establish an outer TLS channel. EAP enables a connection to this channel in such a way that the client authentication won’t occur unless the outer TLS has been successfully established.
To see how this helps thwart credential relaying attacks, let’s take a look as an example. Let’s say that an attacker would manage to impersonate a server and succeed at having a client connect to him instead. The client would believe he is connecting to e.g. “webmail.contoso.com”. The attacker would take the credentials, set up a connection to another server on which the client has an identical account, for instance “fileserver.contoso.com.” He would then authenticate against that server.
At that point in time, if the server has Extended Protection for Authentication enabled, it will validate whether the authentication request was really intended for him, which it is not. In addition, if a TLS channel is present, it will validate whether the credentials were transferred over the same TLS channel. As the client initiates a TLS connection with the attacker, and he subsequently set up a new one with “fileserver.contoso.com,” this will also not match and the server will fail the authentication attempt.
How do I deploy Extended Protection for Authentication?
Deployment of Extended Protection for Authentication must happen on both the client and server for any given application. If only one side supports the feature, the connection will not benefit from the additional protection offered.
Below, we will provide a brief example on how to configure Extended Protection for a scenario that involves Internet Explorer and the Internet Information Services (IIS) web server.
The following prerequisites apply:
· On the client, KB968389 must be installed, which enables the Extended Protection feature in the Security Support Provider Interface (SSPI). This feature is automatically present on Windows 7 and Windows Server 2008 R2 machines;
· On the client, Internet Explorer cumulative update MS09-054 must be installed to enable Internet Explorer to use the feature;
· On the server, both KB970430 and KB973917 must be installed, which deploy this feature to HTTP.sys and the IIS web server.
An administrator must now enable the functionality offered by these updates:
· On the client, enabling Extended Protection is a machine-wide setting. It will apply to all applications that opt-in to the protection mechanism and use the SSPI for authentication. On Windows 7 and Windows Server 2008 R2 machines, the feature is enabled by default. On older platforms, upon installation of KB968389. Extended Protection must be enabled by setting the value of the registry key HKLM\System\CurrentControlSet\Control\LSA\SuppressExtendedProtection to 0. In addition, administrators should validate that the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel key is set to 3. This means that the client will only use NTLMv2 authentication, and will use NTLMv2 session security if the server supports it. This is important because Extended Protection for Windows authentication only protects NTLMv2 and Kerberos authentication, not NTLMv1.
· On the server, enabling the feature is a per-application setting. In order to protect the IIS web server, Extended Protection must be enabled as well. The instructions differ per IIS version, and more detailed configuration information can be found in KB973917. On Internet Information Services 7.5, follow these guidelines to enable Extended Protection for Authentication in IIS:
1. On the taskbar, click Start, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.
2. In the Connections pane, expand the server name, expand Sites, and then site, application or Web service for which you want to enable Extended Protection for Windows authentication.
3. Scroll to the Security section in the Home pane, and then double-click Authentication.
4. In the Authentication pane, select Windows Authentication.
5. Click Enable in the Actions pane.
1. Click Advanced Settings in the Actions pane.
2. When the Advanced Settings dialog box appears, select one of the following options in the Extended Protection drop-down menu:
a. Selecting Accept will enable a connection terminating on the IIS server to benefit from Extended Protection if the client has been configured to support it. Clients that have not enabled the feature will still be allowed to connect, but will not benefit from the additional protection.
b. Selecting Required will require clients to use Extended Protection. If they do not support it, any authentication attempts against IIS using IWA will fail.
- Click OK to close the Advanced Settings dialog box.
If a user enables Extended Protection for Authentication, and attempts to connect to a server that does not support the feature, that authentication attempt will still succeed.
Can I support Extended Protection in my application?
This depends on the protocol. Many protocols can be protected, but some cannot. For instance, RPC does not support Extended Protection for Authentication, but can also be protected by enabling confidentiality/integrity.
Applications implementing other protocols, such as HTTP, can definitely benefit from this feature. We encourage developers to implement this feature. If your application uses the WinHTTP or WinINET programming interfaces, then you are indirectly already benefiting from this protection, as updates for both APIs are now available. Developers can find the SSPI headers for Extended Protection here.
Thanks to Mark Novak, Larry Zhu, Paul Leach and Paul Miller for their design and implementation work on this feature. Thanks also go out to Andrew Roths from the MSRC Engineering team for his technical feedback on this blog post.
-Maarten Van Horenbeeck, MSRC Program Manager
*Posting is provided “AS IS” with no warranties, and confers no rights.*
12/8/09 Update: Updated the links to security advisories 973811 and 974926.
7/28/21 Update: Updated the links to security advisories 973811 and 974926 and MS09-054.