Update ( July 24 2014): We had published an FAQ page
Nearly all advanced targeted attacks involve stolen credentials and identity theft. As part of our ongoing research on advanced attacks, we expose a critical Active Directory flaw which enables an attacker to change the victim’s password. This attack can be performed despite current identity-theft protection measures.
Since 95% of all Fortune 1000 companies have an Active Directory deployment, we consider this vulnerability highly sensitive.
Using the new password, an attacker can fully impersonate the victim to access various enterprise services which require the explicit use of the victim’s password such as Remote Desktop Protocol (RDP) Logon and Outlook Web Access (OWA).
The worse part? Logged events miss the vital indication of an identity theft attack. The attacker can perform this activity unbeknownst to event logs, making log-based SIEMs and Big Data Security Analytics useless against these kinds of advanced attacks.
We have provided Microsoft a full and responsible disclosure of this episode. In fact, Microsoft recognized our findings to be valid but confirmed that this is a “limitation” that cannot be fixed as it stems from the design of the authentication protocols. Additionally, since these protocols’ specifications are publicly available, Microsoft considers this “limitation” to be “well known”.
This is where we disagree:
Since we consider this issue a “by design” flaw, it also requires its own set of mitigation measures which we provide at the end of this entry.
Additionally, the Microsoft official statement is provided in its entirety at the bottom of this blog.
For the techie readers who are already familiar with NTLM and Kerberos: feel free to skip this section.
To understand this vulnerability, let’s first take a look at the protocols behind Active Directory’s Single Sign On (SSO) authentication – NTLM and Kerberos. SSO is what allows users to provide their password only once even though they access various services – whether in the corporate network or in the Cloud. As mentioned, the underlying SSO authentication protocols are NTLM and Kerberos. NTLM is the older Windows’ authentication protocol which, although still enabled by default due to backward compatibility reasons, suffers from security issues and so has been superseded by the Kerberos protocol.
Both the NTLM and Kerberos protocols are based on using the user’s password as a proof of the user’s identity. The key difference between them is the way they use of the user’s password:
It’s important to stress is that Kerberos supersedes NTLM due to security issues. Accordingly, there shouldn’t be a dependence of Kerberos on NTLM.
The thing is that Windows supplemented the Kerberos standard with an encryption method that allows users to obtain a ticket with… the older NTLM hash.
Microsoft’s reasoning? To support a slick upgrade from strictly NTLM supporting versions (Windows NT 4.0 and lower) to Kerberos supporting versions (Windows 2000 and thereafter).
Technically, this upgrade was achieved by adding support in Kerberos for the encryption algorithm named RC4-HMAC.
And herein lies the problem: the RC4-HMAC encryption algorithm uses the NTLM hash as its key.
This fact is explicitly stated in section 2 of RFC 4757: “The key used for RC4-HMAC is the same as the existing Windows NT key (NT Password Hash) for compatibility reasons.”
Other than the RC4-HMAC encryption, Kerberos supports other stronger ciphers such as the AES encryption (or more formally: “AES256-CTS-HMAC-SHA1″), which is the default encryption for Kerberos in Windows. The stronger encryption methods do not accept the NTLM hash as their key.
The side-effect of this vulnerability? Attackers can obtain a valid Kerberos ticket if they are able to obtain a user’s NTLM hash.
The reason is that they can change the encryption settings from the default, stronger, AES encryption to the weaker RC4-HMAC and use the stolen NTLM hash as the Kerberos’ password encryption key. As a result, attackers can prove their identity to Active Directory and in turn, receive a valid Kerberos ticket.
As opposed to other attacks which relied on the direct use of the stolen NTLM hash such as Pass-the-Hash (PtH), in this attack the attackers can obtain a fresh, legitimate Kerberos ticket with by the stolen NTLM hash. This fact changes the main tactic used by targeted attacks, namely carrying out an attack using PtH.
Unfortunately, many mitigation and solutions to counter Pass-the-Hash are based on allowing only Kerberos authenticated users or detecting anomalous NTLM authentication. However, as demonstrated, an attacker using this vulnerability can create a valid Kerberos ticket and authenticate to various systems by impersonating the victim whose NTLM hash was stolen. Consequently, these anti-PtH techniques are rendered useless.
The dire consequence? Attackers can use the stolen NTLM hash to change the victim’s password to one of their choice.
To see how, let’s first take a look at the Change Password mechanism. Naturally, changing the password is an ultra-sensitive operation. In fact, as opposed to all other activities that can be executed by anyone who has access the computer, changing the password requires knowledge of the older password to prevent attackers who have already gained temporary access to the computer from making the access persistent.
Technically, the password change functionality is achieved by supplementing Active Directory’s regular authentication module (named “Krbtgt”) with a dedicated module that handles authentication requests for password changes (named “Kadmin”). Kadmin module is very similar in operation to the Krbtgt module and most importantly to our case, uses the same Kerberos logic and hence is exposed to the same flaws.
As a result, using the above techniques of using an NTLM hash as the RC4-HMAC key for Kerberos authentication against Active Directory’s Kadmin module, attackers are able to change the password of their victim to an arbitrary password of their choice.
In fact, we had validated this behavior with a Proof-of-Concept tool we had built.
The immediate consequence is that an attacker can leverage an NTLM hash in order to change the victim’s password to that of their own. As a result, the attacker can access interfaces that require explicit use of the password, such as Remote Desktop (RDP) Logon and Outlook Web App (OWA).
Using this vulnerability, Anti Pass-the-Hash solutions and mitigations that are based on allowing only Kerberos authenticated users or detecting NTLM authentication are rendered useless.
The defensive side should not lose hope, though. After all, indication of an attack can seemingly be indicated by the use of the encryption algorithm, Rc4-HMAC. Unfortunately, users relying on Windows internal log system (Event logs) are in for a bitter disappointment.
One of the inherent shortcomings of logs is that they are a summary of the information. During the process of summarizing some information is bound to get “lost in translation”. Therefore, building a security system and strategy to rely on logs rather than on the actual traffic means that they are built on some shaky foundations.
This case is not different. Although Windows had created a relatively verbose Kerberos event logging system, it fails to show the pertinent attack information. As a result, the logs lack indication of something fishy going on.
The lack of log activity is demonstrated through the following series of screenshots.
In the first screenshot you can see the relevant Event Log (Event ID 4768), generated by Aorato’s attack’s Proof-of-Concept tool. The only information related to encryption, “Ticket Encryption Type”, is not the field which the attacker uses. (For those readers who are intrigued by this value, note that it is 0×12 which represents the AES encryption. As mentioned, it is irrelevant to this attack scenario – its value remains the same even when the RC4-HMAC encryption algorithm is used. For a list of all possible values of the field refer to the table in http://blogs.technet.com/b/askds/archive/2010/10/19/hunting-down-des-in-order-to-securely-deploy-kerberos.aspx)
Unfortunately, the log of password changes presents a worse picture as the event log for a successful password change does not include ANY Kerberos information, let alone the needed encryption information.
Since there is no inherent solution, full mitigation must be provided externally. Measures include:
We would like to raise the reader’s attention to the fact that Microsoft provided in its response two additional measures: the first is to use a smart card authentication and second, to remove the weaker encryption (i.e. RC4-HMAC) from the systems. However, we do not see either as viable and practical solutions:
Read more about Kerberos in our glossary: http://www.aorato.com/labs/kerberos/
Read more about NTLM in our glossary: http://www.aorato.com/labs/ntlm-network-authentication-protocol/
“This report is about a limitation in the Kerberos Network Authentication Service (V5) standard (RFC 4120), that is well-known within the industry, whereby an attacker can authenticate as a user, or change that user’s password, if they know that user’s secret key. Possession of a user’s password-derived secret keys (RC4 and AES by default) is validated during the Kerberos password change exchange per RFC 4757. The user’s plaintext password is never provided to the Key Distribution Center (KDC) and Active Directory (AD) domain controllers do not possess a copy of plaintext passwords for accounts by default. If the Domain Controller (DC) does not support a Kerberos encryption type then that secret key is not allowed to be used to change a password.
In Windows, there are three ways to block changing passwords when using Kerberos with RC4 secret keys:
We are excited to inform you that we have been acquired by Microsoft.
At our core, Aorato has always been focused on strengthening enterprise security, by giving customers deeper visibility into their Active Directory and identity infrastructure with an emphasis on user behavior intelligence and analytics. Joining Microsoft gives us a unique opportunity to pursue this vision, and help customers at the broadest possible scale.
With this acquisition, we will cease selling our Directory Services Application Firewall (DAF) product. As part of Microsoft, we will share more on the future direction and packaging of these capabilities at a later time.
Thank you to all who have supported Aorato.