This week, my colleague Jim Rapoza asked if I would comment on a recently reported critical design flaw in Microsoft Active Directory (AD).
The original disclosure was made by Aorato, a Tel Aviv-based start-up that provides an application firewall for AD.
As I mentioned in last week’s blog, understanding the details sometimes takes me a while. Here’s the most orderly summary I can manage, in simple, declarative sentences:
- Nearly all organizations have Microsoft deployments.
- Nearly all Microsoft deployments use Active Directory.
- Active Directory authenticates user credentials (e.g., passwords) at login, assigns access privileges based on roles (e.g., xxx), and enforces policies (e.g., installing or updating software).
- Methods for authenticating user credentials supported by AD include:
- NTLM: “NTLM credentials are based on data obtained during the interactive logon process and consist of a domain name, a user name, and a one-way hash of the user’s password. NTLM uses an encrypted challenge/response protocol to authenticate a user without sending the user’s password over the wire. Instead, the system requesting authentication must perform a calculation that proves it has access to the secured NTLM credentials.”
- Kerberos: “The Microsoft Kerberos security package adds greater security than NTLM to systems on a network. Although Microsoft Kerberos is the protocol of choice, NTLM is still supported. NTLM must also be used for logon authentication on stand-alone systems.” In Kerberos protocol, clients obtain “tickets” from a key distribution center; these tickets are the client’s network credentials and are presented to servers and applications when connections are established.
- Both NTLM and Kerberos have well-known vulnerabilities related to user authentication:
- NTLM is vulnerable to Pass-the-Hash: if an attacker somehow obtains a valid username and the one-way hash of the user’s password, they can authenticate to any server or application that uses the NTLM challenge/response authentication protocol – the hash is the functional equivalent of the cleartext password itself. (See my blog on Salt With Your Hash = Better for You (Your Passwords, That Is) for more details on passwords and hashes.)
- Kerberos is vulnerable to Pass-the-Ticket: if an attacker someone obtains a user’s Kerberos ticket, they can authenticate to any server or application that uses the Kerberos authentication protocol – after a successful initial authentication based on their username and password, Kerberos tickets are used to provide users with the convenience of “single sign-on” to other services.
- So far, none of the points summarized above represent new information. In a paper on mitigations for the Pass-the-Hash vulnerability, Microsoft notes that:
- NTLM will not be enhanced; Microsoft encourages customers to deploy the Kerberos protocol.
- At the same time, however, Microsoft acknowledges that use of the Kerberos protocol itself is not a mitigation for the vulnerability in NTLM: “While we encourage customers to use the Kerberos protocol, certain services still rely on NTLM and addressing application compatibility can be challenging. In mixed environments, password hashes are still available to an attacker. The Kerberos protocol alone is also susceptible to similar attacks, such as Pass-the-Ticket attacks, and exploit tools to perform such attacks are already available to attackers.”
- Consequently, Microsoft recommends the following mitigations: (1) restrict and protect access to highly privileged domain accounts; (2) restrict and protect access to local accounts with administrative privileges; and (3) restrict inbound network traffic.
So what’s the news here? If you read deeply enough in Aorato’s disclosure, you’ll find that:
- To support an easier transition from NTLM to Kerberos, Microsoft added support in Kerberos for an older encryption algorithm, RC4-HMAC.
- But for compatibility reasons, the key used for RC4-HMAC is the same as the NTLM password hash.
- This means that if an attacker can gain access to a given user’s password hash, they can use it to receive a new, legitimate ticket from Kerberos – and can subsequently impersonate that user as they use that Kerberos ticket to authenticate to other servers and applications … including, for example, remote logon and Outlook Web Access.
- Moreover, because this impersonation is based on a valid Kerberos ticket, the subsequent access to enterprise resources is not noted as anomalous in log files … the implication, as Aorato points out, is that “log-based SIEMs and big data security analytics solutions are useless against these kinds of attacks.”
So there we have it – the law of unintended consequences rears its ugly head once again, as a decision made for the convenience of backwards compatibility and easier forward migration leads to a potentially serious security vulnerability, that won’t even be detected by some of the most common approaches that companies have put in place.
The real question is: what to do next?
Clearly, as a security solution provider, Aorato would like to make the enormous number of organizations that use Active Directory aware of this vulnerability, and generate interest in their application firewall solution for Active Directory – the classic marketing technique of making the customer aware of a headache, and then selling them the aspirin.
The first matter at hand, however, is for each organization to assess the risk – in the specific context of their IT infrastructure (endpoints, servers, applications, data), what is the likelihood that this vulnerability could be exploited, and what would be the potential business impact of a successful exploit?
These questions are easy to frame, but not always so easy to address. Identifying what services rely on NTLM would be a good place to begin … but given the complexity of today’s infrastructure, summarizing that information presents its own set of headaches. Maybe stocking up on that aspirin is not such a bad idea, after all.
For more research and insights on the topic, visit Aberdeen’s IT Security research practice