Reflecting on NTLM Reflection
Posted by Takehiro Takahashi on December 17, 2009 at 2:51 PM EST.
Since late 2008, Microsoft has been releasing updates for ‘NTLM reflection attack’ which allows an attacker to use a victim's NTLM credentials in order to gain access to the victim's shared resources. These updates correct programs’ behavior to use Microsoft’s protection mechanism against the reflection attack. Here is a quick list of applications fixed in last 12 months:
|MS08-068||SMB remote code execution|
|MS08-076||Windows media component remote code execution|
|MS09-013||Windows HTTP Service remote code execution|
|MS09-042||Telnet remote code execution|
After reviewing MS08-076, we spent some time auditing other applications that support the NTLM authentication protocol, and discovered Mozilla Firefox, Opera and Google Chrome were all vulnerable to the reflection attack. As of 12/17/09, all three vendors have already released updates for their products, and a security advisory has been published from Mozilla.
Unfortunately, none of these patches, as pointed out by H D Moore, protects users from reflection attacks when multiple victims are involved (i.e. attacker’s server relays VictimA’s credential to VictimB). This happens because the scope Microsoft’s NTLM reflection attack protection is local only, and the NTLM protocol provides no provision for protecting users from the reflection attack. One can imagine any Active Directory based networks are seriously affected by this issue.
In this article we discuss the internals of NTLM authentication in detail in order to understand the full extent of the problem. For readers’ convenience, we refer to two types of reflection attacks as two-party reflection attack and multi-host reflection attack. In a two-party reflection attack, attacker uses a stolen credential against the same victim, where as in a multi-host reflection attack, the credential is forwarded to a host other than the original victim. Last but not least, IBM ISS customers have been protected against both types of reflection attack by NTLM_MultiProto_Reflection since April 14, 2009.
First, let us briefly provide a high-level overview of the NTLM protocol. NTLM is actually a suite of security protocols that offers authenticity, integrity, and confidentiality to users. While Kerberos has replaced NTLM as the default authentication protocol in an Active Directory based single sign-on scheme, NTLM is still widely used in many scenarios where a Kerberos server (Domain controller) is unavailable or unreachable (i.e. remote web authentication). Due to a number of security updates in the past, the following protocols, ordered in increasing security, exist in NTLM: Authentication: LM (LAN Manager), NTLM, and NTLMv2. Integrity and Confidentiality: NTLM Session Security and NTLM2 Session Security. Regardless of the protocol used, NTLM authentication always establishes a session using three messages as illustrated in Figure 1. These messages are often referred to as Type 1 (negotiation), Type 2 (challenge), and Type 3 (authentication) messages. By default, Windows Vista/7 uses NTLMv2 authentication which achieves a higher level of security by computing an authentication token using HMAC-MD5 with both user and server challenge. Other versions of Windows such as 2000, XP, and 2003 use NTLM authentication which only uses server challenge. The protocol selection depends on Group Policy, or a registry key
HKLM\SYSTEM\CurrentControlSet\Control\LsaLmcompatibilityLevel) by both the server and client. Although NTLMv2 successfully protects Windows hosts from password brute-forcing with a rainbow table, it gives no protection from a reflection attack.
On the other hand, NTLM Session Security and NTLM2 Session Security uses a session key established during the authentication phase in order to provide data encryption and integrity check. Unfortunately, this additional security feature makes no contribution to preventing a reflection attack.
Let us also mention another popular authentication protocol, Kerberos. Kerberos is the most preferred choice for authentication due to its higher security and efficiency, and is used in all domain services by default. Since both client and server must be authenticated to a KDC (Active Directory server in most cases) in order to retrieve a session key, a reflection attack is not possible. The downside is that both parties must have access to the Kerberos server which is less likely for external users trying to authenticate to services such as Exchange OWA. Microsoft also implements Negotiate which is a wrapping protocol for Kerberos and NTLM. It lets communicating parties use Kerberos by default, while allowing them to fall back to NTLM whenever necessary. This protocol is recommended over NTLM by Microsoft.
Now, we turn to the internals of the NTLM authentication. A client implementing NTLM calls the following Win32 API repeatedly in order to generate NTLM blobs until the authentication finishes:
SECURITY_STATUS SEC_Entry InitializeSecurityContext(
__in_opt PCredHandle phCredential,
__in_opt PCtxtHandle phContext,
__in_opt SEC_CHAR *pszTargetName,
__in ULONG fContextReq,
__in ULONG Reserved1,
__in ULONG TargetDataRep,
__in_opt PSecBufferDesc pInput,
__in ULONG Reserved2,
__inout_opt PCtxtHandle phNewContext,
__inout_opt PSecBufferDesc pOutput,
__out PULONG pfContextAttr,
__out_opt PTimeStamp ptsExpiry
InitializeSecurityContext, implemented in secur32.dll, takes a server message as a user input (pInput), makes several Local Procedure Calls (LPC) to the Local Security Authority Subsystem Service (LSASS) to process authentication, and returns a client blob in pOutput. LSASS, whose executable name is known as lsass.exe, sets up a public LPC port (\LsaAuthenticationPort) and takes the first DWORD of LPC message as an index for undocumented functions. LpcAcquireCreds, LpcGetUserName, LpcLogonSessionData, and LpcLookupAccountName are examples of these functions. The LSASS is responsible for a variety of tasks such as retrieving/verifying users' credentials, keeping track of logon sessions, or digesting/generating authentication blobs. It also implements a local reflection attack protection by checking an incoming NTLM challenge against a splay-tree full of active challenges currently in use. If the LSASS sees a duplicate challenge, it returns an error. In other words, any client application which implements NTLM should use InitializeSecurityContext or the application is vulnerable to the reflection attack. Also, one must make sure that the third argument pszTargetName points to a proper service principal name (SPN) used to uniquely identify an instance of a service - the reflection attack protection is not enforced otherwise. For example, Opera was using a null pszTargetName when we first audited. Finally, these active challenges are not shared among network hosts, explaining why token forwarding in an Active Directory based network works.
The first call to InitializeSecurityContext produces a blob used in message 1 of Figure 1. The message merely declares the host/domain name of the client. The subsequent reply from the server has a blob which contains the server challenge, and is passed to the second call to InitializeSecurityContext. The LSASS validates the incoming messsage, extracts the challenge message, and generates a challenge response seen in message 5 of figure 1. The type of NTLM challenge response generated is based on GroupPolicy.
On the other hand, a server implementing NTLM calls the following Win32 API repeatedly in order to process user authentication:
SECURITY_STATUS SEC_Entry AcceptSecurityContext(
__in PCredHandle phCredential,
__inout PCtxtHandle phContext,
__in PSecBufferDesc pInput,
__in ULONG fContextReq,
__in ULONG TargetDataRep,
__inout PCtxtHandle phNewContext,
__inout PSecBufferDesc pOutput,
__out PULONG pfContextAttr,
__out PTimeStamp ptsTimeStamp
The function works very similar to InitializeSecurityContext - it takes a client message as user input (pInput), makes several LPCs to the LSASS, and returns a server blob in pOutput. The server challenge is checked against an active challenge table once the server receives the challenge response.
In conclusion, we have brought the following points to readers’ attention:
1) The two-party NTLM reflection attack can be prevented by using the API correctly
2) The multi-party NTLM reflection attack is still possible against any products
As of late 2009, NTLM remains a popular authentication protocol for many users, and the multi-party reflection attack problem continues to exist as a result. It is likely that the protocol needs another revision such as implementing a mechanism to verify the origin of NTLM messages (i.e. include an IP address of a sender hashed with a session key) in order to fully address the issue. Nevertheless, we would like to reiterate that IBM ISS customers have been protected from both types of reflection attack since April 14, 2009.
 Squirtle http://code.google.com/p/squirtle/
 Metasploit http://www.metasploit.com/