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.
High-Level Anatomy of an Attack
- Attacker uses a publicly-available free penetration testing tool (such as WCE or Mimikatz) that steals an authentication component, named NTLM hash, from the employee’s device. The NTLM hash resides by default on all devices that connect to enterprise resources.
Since this authentication component is known to be a security hazard which leads to identity theft attacks, through the notorious Pass-the-Hash (PtH) attack, protections have been placed to prevent its misuse. For example, many enterprises try to limit the use Active Directory’s older – yet still enabled by default –authentication protocol (i.e. NTLM). In other scenarios, enterprises log and audit NTLM activity. - The attacker forces the client to authenticate to Active Directory using a weaker encryption protocol. At this stage, the attacker uses the Active Directory flaw where the encryption protocol relies on the NTLM hash.
This activity is not logged in system and 3rd party logs- even those that specifically log NTLM activity. As a result, no alerts, or forensic data, ever indicate that an attack takes place. - The attacker proves its so-called legitimate identity to Active Directory using the weaker authentication protocol. Consequently, the attacker is able to:
- Authenticate themselves to restricted services
- Change the password of the victim
- The attacker uses the changed password to fully steal the identity of the victim and access all of the victim’s enterprise resources.
Following Responsible Disclosure
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:
- We consider the fact that attackers can change the victim’s password by only knowing the NTLM hash to be a flaw. If this flaw is by design, this simply makes it a “by-design” flaw.
- While Microsoft considered the protocol’s design limitation public and “well known”, it is the combination of the different aspects which makes this revelation novel. In fact, each piece of the protocol within itself is indeed public knowledge, appearing in various public documents. However, the actual correlation- and its dire consequence – when placing the pieces together has never been investigated before.
- The fact that this behavior is not logged has not been addressed by Microsoft.
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.
Technical Details
The Protocols behind Active Directory: NTLM and Kerberos
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:
- The NTLM protocol computes a relatively weak cryptographic hash function based on the user’s password to create the NTLM hash. From that point on, the protocol uses that NTLM hash as a replacement for the user’s password in order to authenticate to various services.
- Kerberos works by exchanging the password for a ticket (formally known as the TGT – Ticket Granting Ticket). This time around, Kerberos uses safer cryptographic methods than that of NTLM’s. The Kerberos ticket contains all of the user’s relevant authentication and authorization information. This information enables the KDC (i.e. the Key Distribution Center. Consider it as the Kerberos’ “key master” which grants specific access to other organizational services) to rely solely on the ticket information for the user’s authentication and authorization.
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 Active Directory Vulnerability: NTLM’s Hash is Kerberos’ RC4-HMAC Key
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.
(in)Security Side-Effect: Attacker Can Access Sensitive Enterprise Resources albeit Protection Measures
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 Security Impact: Attacker Can Change the Victim’s Password
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.
Read more at source - http://www.aorato.com/blog/active-directory-vulnerability-disclosure-weak-encryption-enables-attacker-change-victims-password-without-logged/
0 comments:
Post a Comment