Exploiting the Pass-the-Hash vulnerability is the weapon of choice for most APT attackers. Therefore when Microsoft released a Windows’ update on May 13th titled: “Update to fix the Pass-The-Hash Vulnerability”, it was warmly accepted by IT teams. However, this update was received by the security community with a raised eyebrow, especially due to the fact that just two months before the update was published, a prominent Microsoft researcher claimed that Pass-The-Hash problem could not be fixed. Consequently, a week later, Microsoft had changed the advisory’s title to the more appropriate “Update to improve credentials protection and management”.
Microsoft Security Advisory title change
In this entry we explain why Pass-the-Hash cannot be mitigated internally within the existing Windows environment, what the mentioned Windows Update actually achieves and finally how to use external compensating controls to protect against such vulnerabilities.
Why Windows Update Cannot “Fix” the problem
The vast majority of security issues that are fixed with Windows Update are implementation flaws, such as buffer overflows and insufficient input validation. However, Pass-The-Hash is not an implementation flaw – it’s inherent to the way that the Single Sign On (SSO) paradigm is supported in Windows.
To support the SSO paradigm, the user’s identity and privileges are established through credentials verification on the initial authentication phase. Consequently, an SSO token is created and stored on that machine. For any follow up login activity where the user’s identity and privileges needs to be verfied again, for example when accessing a network resource, it’s done through the SSO token validation. As a result, if an adversary is capable of stealing the SSO token then the attacker is able to impersonate the user. The thing to note is that this issue is not related specifically to NTLM but to every authentication system that uses tokens in a similar manner. For example, Kerberos (NTLM’s successor authentication protocol) is vulnerable to the theft of its token, named Kerberos ticket, where the attack is appropriately called Pass-the-Ticket.
That’s exactly what Microsoft’s expert Mark Russonvich claimed in his tweet (see screenshot below) and in his RSA conference slide deck. To quote Mark’s own words: “Pass-the-Hash == SSO”. In practice, this means that that Pass-the-Hash issues are the other side of the coin to having an SSO experience.
Mark’s Tweet: “PtH==SSO”
This general statement seems to be an exaggeration with respect to ALL possible SSO mechanisms. For example, we can imagine an SSO mechanism that binds the token to the machine, either with hardware or with cryptography, thus making it impossible for the attacker to reuse the token on another machine. While this general statement sparked a heated debate, it seems that there is a consensus that it holds true for the current Windows’s SSO mechanisms. Therefore, it should be clear that no Windows Update can “Fix the Pass-The-Hash Vulnerability”.
What does this Windows update actually achieve?
While the problem itself cannot be fixed with a software update, users can still minimize their exposure to Pass-the-Hash attacks. This current Windows’ update achieves just that: it’s a backport of the new technologies introduced in Windows 8.1 and Windows server R12 to previous versions in order to limit the user exposure to hash and credential theft.
These backported technologies include:
- The hardening of the LSA service that handles the authentication. This limits the stealing opportunities of credentials.
- Support for “Protected users” group. This forces members of the group to use more strict authentication parameters.
- Support for the Restricted Admin mode. We actually discussed the merits and pitfalls of this mode in a previous blog post. Admitting to the pitfalls, Windows chose to backport only a subset of this mode features in order to gain only the benefits of the mode. Accordingly, in this update Windows supports Restricted Admin only for Client mode, and not for the Pass-the-Hash vulnerable server mode. Ironically, this means that Windows 7 users are better protected than Windows 8.1 users.
How to actually fix the problem?
As explained above Windows authentication protocols do not include the option of binding their SSO token to the machine, and so enable attackers to reuse the SSO token on other machines. Windows can solve token theft problems by simultaneously augmenting these protocols to support such binding (or create a new authentication protocol) and disabling the existing vulnerable protocols. Unfortunately, history proves once and again that disabling authentication mechanism takes a lot of time due to backwards compatibility issues. As a matter of a fact, Microsoft has been trying to eliminate NTLM for more than a decade, with a very limited success. Having this outdated authentication mechanism reside side-by-side along with the newer, more secure protocol, often eliminates the security merits of the latter. In the coming weeks we will publish some new revelations on how NTLM’s insecurity is dragging down Kerberos’ security.
If Windows can’t solve the problem, what can be done? The only practical option is to use compensating security controls to bind the SSO token to the machine to prevent its reuse on other machines. Such compensating controls can take the form of a security device that remembers which token was assigned to which machine and can alert or even block the use of that token from other machines.
Read more about Pass-the-Hash in our glossary-http://aorato.com/labs/pass-the-hash/
Read more about Pass-the-Ticket in our glossary-http://aorato.com/labs/pass-the-ticket/