Kerberos Token Bloat, MaxTokenSize and Tokensz

Folks,

Starting July 04, 2016, we're going to start addressing certain matters of cyber security that today have a global impact on the security of a majority of business and government organizations worldwide.

Until then, over the next few days, I just wanted to very briefly cover a few technical aspects.


Kerberos Token Bloat

Today, I wanted to briefly talk about Kerberos Token Bloat, a decade old system technical limitation based issue that continues to linger and distract Microsoft's business and government customers from substantially more important cyber security issues.

[ Begin digression...

By the way, In case you're wondering why this topic merited a mention on a blog to do with Cyber Security, its because not many non-IT folks know that this very topic impacts the cyber security of 85% of all organizations worldwide, and that 1000s of organizations today still struggle to address it.

It is only when they can move on from such basic issues that they can even begin to think about addressing far more important cyber security challenges. Until then, they remain vulnerable, and we remain worried.

...end digression. ]


Speaking of Kerberos Token Bloat, here's a simply picture that conveys its impact -


Kerberos Token Bloat

Given the paucity of time, in this blog entry I'm not going to expound upon the issue of Kerberos Token Bloat, as I've already described it, and 3 helpful tools/scripts in substantial detail over here.

The first time I spent some time on it was way back in 2002 during my Microsoft years.

The short of it is that Kerberos Token Bloat is an issue that can result in users being denied access to corporate systems (i.e. a Windows logon) simply by virtue of the fact that they belong to a large (enough)  number of Active Directory security groups.

For example, consider a random user, say Satya Nadella. When he uses his Active Directory domain user account, such as corp\snadella to logon to his domain-joined Windows Surface device, he could be denied access to the system (i.e. denied a logon) if he is a member of a large enough number of domain security groups.



Logon Denied due to Kerberos Token Bloat

In case the snapshot above isn't clear, here's the message he'll see -

Logon Message

The system cannot log you on due to the following error: 

During a logon attempt, the user's security context accumulated too many security IDs.

Please try again or consult your system administrator.

In many medium and large sized organizations worldwide, this can easily be a major and unwelcome IT problem because many users could be in a situation wherein over the years they been made members of a large number of security groups, and thus potentially run the risk of being denied a logon if their group membership count were to continue to increase.

Domain Admin



To minimize the possibility of users being denied access to the system, IT personnel try to proactively determine Kerberos token sizes of their users, so that they can identify at-risk users and enact adequate mitigation measures.

Over the years, Microsoft has issued guidance, introduced basic tooling, made some enhancements and even made it easier to estimate Kerberos token sizes (via auditing). Still, organizations continue to search for tooling to help them easily determine Kerberos token sizes for all their users, and this problem continues to be unaddressed at so many organizations worldwide.




Its High Time

This issue's been around for over a decade now, and you'd think that by now most organizations would have it under control. After all, there are far greater cyber security challenges (that may very well be in their blind spot) as illustrated here that these organizations need to be addressing today. After all, its 2016, not 2006.

Yet, we find that to this day, every week, IT personnel from so many prominent organizations in the world still continue to search for tooling that can help them estimate Kerberos Token Sizes for all their users. We're not about to disclose their names, but if you too knew, you'd possibly fall of your chair.



Click, Done. (Can we please move on now?)

In the interest of organizations worldwide that are potentially impacted by Kerberos Token Bloat, we'd like to humbly suggest that these organizations kindly address this issue once and for all, and then move beyond it, so that they can address issues that today pose a far greater cyber security threat to them, than the (relatively petty and puny) issue of Kerberos Token Bloat.

Incidentally, here are some terms that IT personnel from these organizations continue to extensively search for in their quest to address this problem - tokensz, Kerberos Token Size Tool, maxTokenSize, CheckMaxTokenSize, Get-TokenSizeReport, tokensz for another user, whoami for another user, TokenSize = 1200 + 40d+ 8s, Warning events for large Kerberos tickets, etc.

So that organizations need not waste anymore precious time trying to dabble with insufficient tooling, half-baked inaccurate solutions or unreliable amateur scripts, we built the world's only professional-grade Kerberos Token Size Tool for them -


Fully-automated, multiple-user Kerberos Token Size Calculator

In essence, with our tooling, if you know how to click a mouse button, you can now instantly and automatically determine the Kerberos token-size of every domain user account in your domain, within hours. By the way, that's only about 1% of what we do, and we only built this because we had a very prominent Swiss Bank request us to build this for them. (More on it here.)




An Associated Denial-of-Service Attack (Just Waiting to Happen)

For most organizations, the scenario of primary concern and the one they wish to address and avoid is one wherein a user ends up being a member of a large enough number of groups, and eventually is unable to logon.

Unfortunately, in most organizations, a malicious perpetrator could actually exploit this very issue to launch a organization-wide denial-of-service attack wherein come Monday morning 9:00 am, no one (including IT personnel) is able to logon, and you have a situation where business comes to a halt.

You can imagine the potential hourly cost to an organization when its business comes to a halt.

When 10,000 employees can't logon, every minute matters, and costs a lot.

So, just how easy is it for a skilled malicious perpetrator to launch a Kerberos Token Bloat based denial-of-service attack?

Turns out, its not difficult at all.

To do so, all the malicious perpetrator would have to do is create a large enough number of security groups in Active Directory, make one a member of just one more group (about 1015 times), and then add a group like Domain Users to the last group (or say in a targeted attack, add a group such as "Executive Users".)

Hacker

Some might suggest out that Active Directory quotas could help prevent this situation. To which, the response would simply be, that coupled with the ability to create just a few domain user accounts, even quotas could be easily bypassed.

Further and actually, the malicious perpetrator need not even possess sufficient effective permissions in Active Directory to be able to create a large number of security groups; if he/she simply had sufficient effective permissions to be able to modify the membership of a sufficient number of existing domain security groups in Active Directory, he/she could use the power of scripting to accomplish the same objective within minutes.

It also pays to keep in mind that unlike ordinary users, a skilled malicious perpetrator would typically use automation (e.g. scripting) to accomplish his/her objectives, and thus could make his/her move very quickly. (A decently skilled perpetrator could accomplish this feat within a matter of minutes.)

Thus, at the very least, to mitigate the risk posed by a Kerberos Token Bloat based denial-of-service attack, today, all organizations operating on Active Directory should ideally, at a bare minimum, be able to answer the following questions -

1. Exactly who can create security groups in our Active Directory?

2. Exactly who can modify the membership of all existing security groups in our Active Directory?

3. Exactly who can create domain user accounts in our Active Directory?

4. Exactly who can modify the default quota settings in our Active Directory?

Incidentally, it used to be that you'd have to be an Active Directory rocket scientist to answer these fundamental questions. Thankfully, today, man has finally landed on this moon too, and such questions can now be answered at the touch of a button.

Today, ideally, every organization operating on Active Directory should, at a minimum, be able to answer each of the following elemental cyber security related privileged user access questions listed in this document.

Alright, time almost up so this will have to end soon.


In Summary

Kerberos Token Bloat is a decade old issue that most organizations should already have dealt with. Unfortunately, to this day, thousands of prominent organizations worldwide still continue to search for basic tooling in their attempts to deal with it.

I suggest they quickly identify at-risk accounts, take adequate mitigation measures, and, at a bare minimum, answer the 4 questions enumerated above, then swiftly shift and elevate their focus on substantially far greater cyber security issues, the business impact of which is described here.

More on which in days to come.

Thanks,
Sanjay

PS: If you found this interesting, you might like reading this too - Our Trillion $ Insight on the OPM Breach

Claim by Israeli Cyber Security Startup Aorato "Critical Design Flaw in Microsoft Active Directory Could Allow Password Change" is Incorrect

Folks,

95% of the Fortune 1000 run on Active Directory, so unless you're living on another planet, you'll want to read this.


95% of the Fortune 1000 Run on Active Directory

As former Microsoft Program Manager for Active Directory Security, and today as CEO of Paramount Defenses, the world's #1 cyber security company focused on Active Directory Security, allow me to share a few thoughts with you on what might very well be a bold yet incorrect claim.

Last week, we received a call from a journalist who wished to request our thoughts on a reported vulnerability related to Active Directory that has been widely reported as Critical design flaw in Microsoft's Active Directory could allow password change and exposed by a company called Aorato. Having never heard of this company before, we asked the journalist to email the details. The journalist then emailed us a link to Aorato's blog, which can be found here.

[Given my role at PD, I don't ordinarily have time to address such issues, but since we had a lot of organizations requesting our take on such a bold claim, I felt it necessary to shed some light on it, and am doing so via this blog entry.]



Aorato's claim that "Active Directory Vulnerability Disclosure: Weak encryption enables attacker to change a victim’s password without being logged" is incorrect.

With utmost respect to Aorato, I'd like to unequivocally state that, based on our assessment of their claim -

From a technical perspective, THIS IS NOT AN ACTIVE DIRECTORY VULNERABILITY at all.

Let me repeat that - technically speaking, this is NOT a vulnerability in Active Directory AT ALL. It is at best, a potentially exploitable weakness in Microsoft Corporation's implementation of Kerberos that has been known for years. Technically speaking, the only relation this has to Active Directory is that Kerberos uses Active Directory as its account database.

In my humble opinion, it may thus have been irresponsible to make such a bold yet technically incorrect claim, because doing so can result in a situation wherein thousands of organizations worldwide could panic, and incorrectly assume that their foundational Active Directory deployments are vulnerable, when in fact this is not the case.

I'm happy to demystify their claim and explain why this is not an Active Directory vulnerability (and I've done so below) but before I can do so, allow me to share a few thoughts with you.



A Little Knowledge is a Dangerous Thing

By claiming that their find is a vulnerability in Active Directory, Aorato may have demonstrated how much/little it may actually know about Active Directory Security, and as goes the old saying - a little knowledge is a dangerous thing.

I also have to admit that in my 15 year professional career, I've come across many Cyber Security companies, but I've never come across a company whose mission statement reads -

"At the core of Aorato’s founding was the acknowledgement that Active Directory is exposed – by default and by design. The consequence of which, is that the entire organization is at risk."

Now that's a first. A cyber security company at the core of which is the acknowledgement that one of the world's most robust and highly securable technologies, Microsoft's Active Directory is exposed - by default and by design.

In reality, of course, nothing could be farther from the truth. If you truly understand Active Directory security, you know that it is one of the most securable technologies in the world. It is neither exposed by default, nor in design. So such a claim only makes you wonder how much (or how little) this company might actually know about Active Directory security.

(If anything, an Active Directory deployment can be exposed to the risk of Active Directory Privilege Escalation, but that is neither by default nor by design. It is only because after years of delegating access in Active Directory, organizations do not have the means to reliably assess who is delegated what administrative access in Active Directory, and this exposure too can be reliably eliminated.)

Anyway, while browsing their website, it was a little unsettling to come across assertions/statements such as -

• "Your Active Directory is exposed. Protect Active Directory and your organization from advanced attacks"
• "Is your Active Directory under attack? We’re here."
• "Windows Update to Fix Pass-the-Hash Vulnerability? Not!"

The most insightful one was on their Labs Page - "Your Knowledge Center for all Active Directory Security-Related Research"

I felt it was insightful because it only covered 4 technical topics - Pass-the-Hash, Pass-the-Ticket, Kerberos and NTLM. Microsoft has an entire 100 page+ white paper on Active Directory Security because it is an ocean of a subject, and these 4 topics at best comprise about 1% of the contents of the white paper, so to call it "Your Knowledge Center for all Active Directory Security-Related Research" seemed to provide valuable insight into how much/little they may actually know about Active Directory Security. (A better description could have been "Our Knowledge Center for Kerberos and NTLM Weaknesses Related Research.")

Perhaps they could benefit from an Active Directory Security 101 primer.



Active Directory Security 101 - A Demo of How Someone Could Actually Easily Compromise Virtually Any Active Directory Deployment in the World within Minutes

Folks, at Paramount Defenses, we actually do know a thing or two about Active Directory Security, yet out of respect for organizations worldwide, we have never demonstrated the impact of our knowledge to the world.

However, today, solely to help folks learn about the real risks to Active Directory security, and to help journalists who spin out sensational headlines without an inherent understanding of the technicals, allow us to share with you a little snippet of our knowledge - A Demo of How a Trusted Insider Could Easily Compromise any Active Directory in Minutes.


You see, if you truly understand Active Directory Security, you know that virtually any Active Directory deployment in the world can be compromised within minutes, without so much so as having to compromise a single machine, let alone having to carry out sophisticated PtH type attacks -

Active Directory Privilege Escalation

Anyone still working with techniques like Pass-the-Hash etc. is trying way too hard, for there are far easier ways to obtain administrative access in Active Directory,  so they may want to learn a thing or two about Active Directory Security.

Again, here's the link - A Demo of How a Trusted Insider Could Easily Compromise any Active Directory in Minutes


With that out of the way, here's our 2c on the vulnerability Aorato seems to have demonstrated.


The Vulnerability - A Potential Design Flaw in Microsoft's implementation of Kerberos, Not in Active Directory

If you truly understand Windows and Active Directory security, you'll most likely agree that the headline should have read - "Potential Design Flaw in Microsoft's Kerberos Implementation Could Allow Password Change" as this has everything to do with choices that Microsoft made when implementing Kerberos in Windows 2000 and nothing to do with a vulnerability in Active Directory.

Here's why...

Technically speaking, Active Directory is essentially an enterprise-grade, fault-tolerant and highly available (multi-mastered) directory service, which in addition to serving as a central directory service, can be (and is) leveraged by various components of Windows management, such as Kerberos, Group Policy, Exchange, PKI etc.

A vulnerability in Active Directory would have to do with one of the numerous components of the directory service itself, such as, but not limited to the database itsef, the Schema, its replication protocols, the LDAP protocol etc.

For instance, if someone had found a way to modify DC-to-DC replication traffic such that the data in transit could be tampered with, resulting in the inbound replication of modified tampered data at the receiving domain controller, that would constitute an Active Directory vulnerability.

The vulnerability described by Aorato has nothing to do with either of these components of Active Directory.

It only has to do with the the choice of encryption algorithms used by Microsoft's implementation of Kerberos to encrypt a Kerberos security principal's credential i.e. his/her password, the hashed version of which just happens to be stored in an attribute in Active Directory, because Microsoft's implementation of Kerberos uses Active Directory as its account database.

(For instance, consider a 3rd party application that leverages Active Directory and extends the Schema to introduce a new custom attribute that is used to store some application-specific data in Active Directory, and lets say that the manner in which that application uses the data (stored in that custom attribute) results in a potential security vulnerability. In such a situation, it would absolutely not be an Active Directory vulnerability. It would simply be a vulnerability specific to that application. In this case, that application just happens to be Microsoft's implementation of Kerberos. As far as Active Directory is concerned, there's just a blob stored in an attribute on a class of objects in it.)

Thus, it should be reasonably apparent to those of ordinary skill in the art, that this is NOT an Active Directory vulnerability. Consequently, the following claim, as made by them is factually incorrect - "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."

For the last time, I'll say this again - this vulnerability is NOT an Active Directory flaw at all, LET ALONE alone it being a critical Active Directory flaw. With this fact out of the way, I'm happy to focus on the issue at hand.


A Potential Design Flaw in Microsoft's Implementation of Kerberos?

The issue at hand here is rather simple.

As many of you may know, there are two authentication protocols in Windows environments - Kerberos v5.0 and NTLM.

Kerberos is the default authentication protocol in Windows 2000 and beyond, and relative to NTLM, it offers various benefits such as more efficient authentication, mutual authentication, delegated authentication, simplified trust management, and of course interoperability.

I'm not about go into the details of how Kerberos and NTLM work, as you can find the details online, such as here. I'll assume that you have a decent understanding of these protocols work, so we can get to the heart of this issue.

What is commonly referred to as a "domain account" is technically a Kerberos Security Principal, and what is commonly referred to as a "domain" is technically a Kerberos realm. At the heart of Kerberos is the Key Distribution Center Service, the KDC, which happens to run on Domain Controllers (DCs) since it leverages the Active Directory as its account database.

Now, every domain account, whether it be a user account or a computer account, has a password associated with it, which is (ideally) known only to the account holder itself, and of course the KDC has access to a hashed version of the password. It is this (hashed version of the) password that is a shared secret between a Kerberos security principal and the KDC, and the KDC happens to share a unique secret with every Kerberos security principal, whether it be a user account or a computer account, and as a result, it is this set of shared secrets that enables Kerberos to facilitate secure access between two Kerberos security principals, and that is the fundamental basis upon which Kerberos works.

Now, when a user authenticates using Kerberos, he/she demonstrates knowledge of the password to the KDC during the Kerberos Authentication Service Request (KRB_AS_REQ) by encrypting pre-authentication data with the user's key, which is derived from the user's password. Since the KDC has a copy of the same user's key, it can decrypt the pre-authentication data, and authenticate the user.

As you may know, there is a fair amount of encryption involved in the inner workings of Kerberos. For instance, the authenticator requires encryption, as do tickets and session keys. In order to facilitate encryption/decryption, Kerberos allows a KDC client and the KDC to negotiate the encryption types to be used i.e. the actual encryption algorithms and checksum types to be used by a client and server to encrypt authenticators, session keys and Kerberos tickets.

For instance a client requesting a TGT from the KDC can during the KRB_AS_REQ inform the KDC about the encryption types and key lengths it can work with, and the KDC will generally pick the strictest encryption type that both the client and the KDC support, assuming it can work with the one of the requested types. (There can also be situations where in the KDC will be unable to use a specific encryption type, and in such cases, will issue an error to the client.)

Microsoft's implementation of Kerberos supports the following encryption types, (; their key lengths in parentheses)  -

1. AES-256-CTS-HMAC-SHA1-96 (256 bit) 
2. AES-128-CTS-HMAC-SHA1-96 (128 bit)
3. RC4-HMAC (128 bit)
4. RC4-HMAC-EXP (EXP stands for exportable, and is 56-bit)
5. DES-CBC-MD5 (56-bit)
6. DES-CBC-CRC (56-bit)

(There are also about a dozen checksum types that it supports such as CRC32, SHA1 (Unkeyed) etc.)

Anyway, the core point to note is that over the years Microsoft's implementation of Kerberos has supported multiple encryption types ranging from the weak DES-CBC-CRC to the strong AES-256. It is also worth noting that not all the encryption types have been there all along, and not all encryption types will be supported all along. For instance, AES-256 wasn't supported until recently and DES which was introduced in Windows 2000 is now off by default in Windows 7 and beyond.

The one common encryption type that has been consistently available is RC4-HMAC. It has been available since Windows 2000 and it is still supported in Windows Server 2012, although starting Windows Server 2008 R2, it can NOW be disabled on all domain controllers. (However, this requires a minimum of a Windows Server 2008 domain functional level and an environment where all Kerberos clients, application servers, and trust relationships to and from the domain must support AES. Support for AES was introduced in Windows Server 2008 and Windows Vista.)

The issue at hand has to do with the key used for RC4-HMAC. Since it was introduced way back in Windows 2000, and (apparently) because Microsoft wanted to make the upgrade from Windows NT to Windows 2000 seamless, (it appears that) a decision was made that the key to be used for RC4-HMAC would the same as the existing Windows NT key (NT Password Hash) for compatibility reasons.

Now it turns out that the NT Password Hash is the same as the NTLM Hash, and thus what Aorato appears to be claiming is that if an attacker can gain access to a user's NTLM Hash by using appropriate tooling that can extract/copy hashes from memory, theoretically, since the attacker has the user's NTLM hash, he/she could potentially use it in an attempt to obtain a Kerberos ticket if the KDC can be made to support the RC4-HMAC as the encryption type to be used during the exchange.

Interestingly, here is where Aorato's description/claim starts to get murky, because they tangent out to claim that since "KAdmin" i.e. the module that handles password changes, essentially operates in a similar manner, theoretically, the NTLM hash could be used to request a password change operation via "KAdmin" and once the password can be changed to one of a value set by the attacker, the attacker could then additionally also obtain access to resources that require an interactive logon (i.e. the use of a clear-text password), examples of which include Remote Desktop RDP) & Outlook Web Access (OWA).

That's where their claim ends.

PtH attacks have been in use for some time now, and their exploit methodology is generally well understood by most folks. One key aspect of such PtH attacks is that password hashes can only be used for network logons, so for instance, you cannot use a password hash to obtain access to a resource that requires that you enter a clear-text password.

In light of this limitation, hypothetically it would be additionally advantageous if one could leverage a copied hash to somehow learn of the existence of a user's clear-text password. The next best thing to learning of the user's current clear-text password is to be able to change it to one of your choice, and what they're saying is that it appears that one can use the NTLM hash to carry out a password change request, thereby additionally gaining the benefit of being able to now also access resources that do require the entry of a clear-text password, examples of which include interactive logons as well as to access other services and features such as Remote Desktop.

Now, the fact that the key used for RC4-HMAC is the same as the existing Windows NT key (NT Password Hash) has been public knowledge for years now, and thus it is only logical that theoretically, anyone with access to the NTLM hash could potentially use it to try and use it to obtain a Kerberos ticket, and along the same lines, use KAdmin to try and enact a password change.

(Its been public knowledge because RFC 4757 states very clearly that - "The key used for RC4-HMAC is the same as the existing Windows NT key (NT Password Hash) for compatibility reasons.")

If something is theoretically possible, it is generally only a matter of time, before someone can build sufficient tooling to enact the scenario out. Aorato seems to have invested some time to demonstrate this in a proof-of-concept scenario, and although they don't provide any verifiable proof to the general public other than a claim that they have demonstrated a proof-of-concept to Microsoft, it is certainly possible to build such tooling.

For example, up until a few years ago, tooling just did not exist to carry out Pass-the-Hash based attacks. Today of course, it is commonly available to virtually the entire world.

It appears they brought this to Microsoft's attention, and in response, Microsoft simply issued a simple statement, a snippet of which follows -

"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."

In other words, according to Microsoft there's nothing novel here.

However, Aorato wishes to contend that there is indeed something novel here, because an NTLM hash can be used to perform a password change operation on the victim's account, and thereby additionally gain access to other resource types that explicitly require clear-text credentials i.e. knowledge of the password.

I will certainly give them this much - the fact that this is theoretically possible has been known for years; the fact that they seem to have put in a lot of effort to try and demonstrate it in a proof-of-concept definitely validates the theory, and yes, if based on an NTLM hash, you can obtain a Kerberos ticket, and/or change a user's password via KAdmin, there is arguably something novel about it. But this is NOT an Active Directory flaw, so  in that regard i.e. this being a "Critical Design Flaw in Active Directory", they are incorrect.



4 Realistic Barriers to Success when Using this Attack Vector

This might appear to be high-impact, but in reality, its utility is rather low, for the following reasons -

1. The attacker can only compromise those accounts that happen to logon to the machine he/she owns. If 99% of users never logon to that machine, the attacker can sit there and wait and grow old, but he'll never get anywhere, because no one logged on to his/her machine

2.  Accounts that are not in active use either because they are disabled, or because they have expired cannot be used, because even if you change the password of these accounts, unless an admin enables or unexpires them, you cannot use that account even if you know the password.

3. Accounts that are active can only be targeted for a short duration of time, because the next time around that the victim proceeds to authenticate him/herself, the password known to him/her will not work, and a call to help desk will most likely result in a password reset.

4. With minimal effort, a notification system can be put in place, such that whenever a user's password is changed, he/she instantly receives a notification. A password change not made by the user him/herself will instantly alarm the user, and allow the organization to take reactive measures.

One cardinal difference between the Pass-the-Hash attacks and an attack in which the perpetrator changes the victim's password is that the use of a hash cannot generally be easily detected, whereas a password change on a victim's account can be instantly detected.

The fact that it can be instantly detected implies that a user can instantly detect a password change not carried out by him/her, and consequently, the perpetrator can be very quickly either apprehended or his efforts can be rendered useless.


The Insufficient Auditing Claim

Aorato claims that the resulting audit entries do not have sufficient information to inform IT personnel that something "fishy" might be going on i.e. it fails to show the pertinent attack information.

It appears that the reason auditing entries fail to show pertinent attack information, is because until recently, this was simply theoretical, so it was most likely not on the list of possible scenarios, and thus log/audit support may very well not be there for such a scenario. Of course I don't speak for Microsoft anymore, but you get the drift.

In this regard, unfortunately, there is some not-so-good news for Aorato. Before I share it, I wanted to take a minute to share another thought with you. So hold this thought for a minute.

If you read the blog carefully, there is a snippet that reads -

"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."

Now, lets stop for a minute and consider what it is Aorato actually does. If you browse their website, you'll find that they're in the business of developing and offering a "Directory Services Application Firewall" which can monitor all Active Directory related network traffic and try and help organizations detect suspicious activities such as the one involving this attack.

It thus only appears logical that it would be in their research interest to uncover additional attack vectors, the use of which, during attacks, would constitute suspicious activities that their firewall could detect, thereby potentially increasing the need for a product designed to detect such attacks.

The not-so-good news for them is that there are far easier ways for insiders to easily and completely compromise an organization's Active Directory, than having to carry out such sophisticated, expertise-reliant attacks. About a 100 times easier. And the swiftness with which they can be enacted can render virtually all security measures, including their detection by any such firewall, completely useless.

(Any organization that wishes to see a real demo in their environment can contact us. We'll be happy to demonstrate the enactment of this attack vector. In fact, its so easy that literally anyone with a domain user account can enact it today. )

But I digress.

The other not-so-good news for Aorato is that although Kerberos related auditing may not detect something fishy, with just a little bit of coding, Microsoft, or any 3rd party tool can have an alert (via email, text, voicemail etc.) issued to users that their password has changed. This is rather easy to do, and is one of the easiest ways of helping organizations combat the occurrence of such an attack.

The benefit of having end-users know that their password has changed, as opposed to having IT admins know, is that an end-user will be able to instantly identify a suspect password change, and take appropriate action, such as informing IT personnel, who could then investigate the incident.

Finally, perhaps Aorato might wish to know that anytime a user's password is changed, the PwdLastSet attribute is updated, so a malicious password change can be instantly detected.


One Important Point - 0wning a System

Folks, much has been made of hash exploitation related attacks, but one has to understand that in order to carry out such an attack, the attacker has to gain ADMINISTRATIVE control over a machine, and for someone who already has administrative control over a machine, with just a little imagination and social engineering, there are far easier ways to capture a user's clear-text password than to have to go through all this trouble.

There is nothing super heroic about being able to extract hashes from the memory of a computer when you are the Admin of that computer, because in effect, as the admin, you control the Trusted Computing Base (TCB) of that computer.

Secondly, it should again be apparent to those of ordinary skill in the art that once you control a domain-joined machine, and you spawn a process in System context on the machine, it automatically goes across the network as the domain computer account, so you already are an Authenticated User across the entire forest. I'm not about to shed light on interesting things you can do with this, but those who're smart will get the drift.

Of course if this computer account happens to be trusted for (unconstrained) delegation, well, ...


Is this Much Ado About Nothing?

As I mentioned previously, it has been a well-known fact for 8+ years now that the RC4-HMAC uses the Windows NT key (NT Password Hash), and any proficient IT security professional will agree that if its the same as the NTLM Hash, theoretically, with sufficient skill/tooling, it can be used to encrypt the pre-authentication data in a KRB_AS_REQ request and the negotiated use of RC4-HMAC as eType.

What Aorato seems to have done is demonstrated this theory in a proof-of-context, and that's worth something because it demonstrates that tooling to exploit this design flaw can be built.

Their finding may very well have led Microsoft to issue this recommendation - http://technet.microsoft.com/library/9111e6f0-fb7f-4340-b87a-ab941978efe1.aspx

In reality though, for Microsoft's customers, implementing this recommendation is not that easy. Interestingly, this recommendation from Microsoft could certainly catalyze Windows Server upgrades from Windows Server 2003 to Windows Server 2008 and beyond.

However, as I indicated above, in reality, because a password change can be instantly detected, in reality, the use of this attack-vector will almost always result in the perpetrator being caught red-handed.

Although they may have demonstrated how someone could exploit the design flaw in Microsoft's implementation of Kerberos, they unfortunately seem to have incorrectly characterized/sensationalized it as a "critical design flaw in Microsoft Active Directory."

From a quick review of their website and blogs, it appears that such a characterization may most likely have been based on their lack of in depth knowledge of Active Directory and Windows Security.

It also appears that as they work towards increasing their level of Windows and Active Directory security knowledge, they may uncover more weaknesses, some of which may be well-known and a few of which may be novel.

Here's why...

Consider a scenario wherein a beginner is introduced to a new subject. As he learns more and more about the subject, his level of expertise advances from beginner to intermediate and eventually to expert. Somewhere alone the post beginner stage, he learns something new, that to him appears to be cutting-edge, but of course to others, is something logical and well-known. Anyway, all excited about this new discovery, he builds a little proof-of-concept, and claims a huge breakthrough.

For instance, if you read Aorato's blog, a few weeks ago, they seem to have made a big deal about "a Windows authentication flaw that allows deleted/disabled accounts to access corporate data." Technically speaking, all that this refers to is that the lifetime of a TGT is 10 hours, so once you have a TGT, you're good for 10 hours, irrespective of whether the account is disabled or expires. If you read their blog, its a big deal!

If you ask others, such as most folks who've been working with Windows authentication technologies for over 14 years, since Windows 2000 came out, this is just basic knowledge. After all, its just the way Microsoft's implementation of Kerberos works.

But 14 years after Windows 2000 came out, as Aorato begins to learn more about the workings of authentication technologies in Windows, they seem to have had this profound revelation that this 10-hour TGT lifetime related issue is a Windows authentication FLAW.

Their relative newness to the subject is indicated by the following comment made in regards to that blog entry -

"We are all for responsible disclosure. However, as the quoted Microsoft's official documentation shows, they were quite aware to the consequences of their implementation choice. So there's nothing to disclose to Microsoft they did not already know. The needed responsible disclosure is for the rest of us, that were under the false impression that when we disable/delete a user account the disabled user access rights are revoked immediately."

Anyone who knows how Kerberos works in Windows knows that a TGT once issued is (by default) good for 10 hours, and by implication, that it can be used to request a service ticket during that time. The only way one can be under the "false impression that when we disable/delete a user account the disabled user access rights are revoked immediately" is if one is not (yet) decently familiar with how Kerberos works in Windows, which can happen if you're new to the subject, and find this to be a startling discovery.

My genuine well-intentioned suggestion to Aorato would be to take the time to actually understand Windows Security in-depth. In the spirit of sharing, not just for Aorato, but for anyone who wishes to be a Windows Security / Active Directory Security Expert, here's a list of some topics brain-dumped in no particular order, you might wish to read up on -

Distributed Security, AuthN, Authz, Auditing, Winlogon, Kerberos, NTLM, Digest, SSPI, SPNEGO, Logon Sessions, Windows Stations, Profiles, LUIDs, Access Tokens, SDs, ACLS, ACEs, Privileges, Rights, SMB, Lan Manager, NULL seessions, Names Pipes, COM, SSL, TLS, SChannel, SAM Server, Federation, DCs, DS Repl, Trusts, SID Filtering, LDAP, DPAPI, SAML, Effective Permissions, PKI, Name Mappings, GCs, DNTs, DC Locator, ADAM, ADFS, Azure, SID History, TDOs, TLNExclusions, ANR, Cross Refs, msDsQuotas, DFS, FRS, LVR, Credman, PAC, Windows Integrated Auth, DBDump, userAccountControl, Constructed Attributes, PDC Chaining, SAML, ADAM, RODCs, Certificate Services,  Token Bloat, Password Resets, Active Directory Privilege Escalation, and about 50 other topcis that come to mind.

For starters, to help figure out just how easy it is for a user to determine whether his/her password has changed WITHOUT even having to look at an audit log, here's one thing to look at - the pwdLastSet attribute on user accounts..

The point is that Windows / Active Directory Security is an ocean of a subject, and the more you learn, the more you realize how much more there is to learn.


Wrapping it Up

Folks, the key point I wanted to make here was that purely technically speaking, this so claimed "critical design flaw" has nothing to do with "Active Directory" per se, and everything to do with someone finally being able to demonstrate that it is possible to take advantage of a potentially exploitable weakness resulting from a decision Microsoft made 15 years ago, in regards to deciding which key to use with the RC4-HMAC encryption type.

In the spirit of fairness, as I have indicated above, the ability to demonstrate how someone could exploit this design flaw, is worth something. However, in this case, the realistic opportunity to use the resulting attack vector is low because it requires a) the attacker to gain control of a machine, b) the victim to logon to that machine and c) a password change which can be instantly detected.

In comparison, when there are far easier ways to compromise virtually any domain user account without so much so as having to gain administrative control over a machine, let alone having to pass hashes, organizations have much bigger problems to solve.

Speaking of bigger problems, in reality, in a majority of the 95% of the Fortune 1000, virtually NO one has ANY idea as to EXACTLY who has what administrative powers in their Active Directory.

(When you have no idea as to exactly who has what administrative in your Active Directory, worrying about advanced attack vectors such as this one, is akin to a kingdom wherein the Defense Ministry has no idea as to exactly who has the keys to which palaces, chambers, residences and gates, but is worrying about what to do about the possibility of an outsider having entered one little hut in the kingdom possibly trying to enter another hut, when in reality, the entire populace of the kingdom, can with the right tools, instantly find out exactly who has the keys to which door across the entire kingdom, including of course to the King's chambers.)


One Final Question -

Here's a question to any company that claims to have expertise in Active Directory Security -

Q. Can you help 95% of the Fortune 1000, answer (even any 1 of) the following 5 fundamental cyber security questions? -

(Each one of these questions have everything to do with Active Directory Security.)

1. Exactly how many people can reset the password of any one of their Domain Admins, Built-in Admins, Enterprise Admins etc. to instantly take over their Active Directory, and thus potentially completely control their entire IT infrastructure?

2. Exactly how many people can reset the CEO's, CFO's, CIO's or the CISO's password to instantly login as him/her and obtain access to everything he/she has access to?

3. Exactly how many people can modify the group membership of any or every security group that they use to control access to the entirety of our organization's IT resources, to in effect gain, grant or revoke any individual of one's choice the ability to access any resource of one's choice?

4. Exactly how many people can delete mission-critical IT resources such as user accounts, computer accounts, security groups, OUs etc, in effect causing substantial and almost always irreversible damage to the organization?

5. What is the easiest path to go from being just an ordinary user account holder (e.g. a contractor working half way around the world) to being a Domain Admin / Enterprise Admin within minutes?

If you can't, please don't be too hard on yourself, because even the Dells, Hewlett-Packards, Ciscos, McAfees, EMCs, Tripwires, CAs, BAHs, Symantecs, Lockheed Martins, FireEyes, Centrifys, CyberArks and Checkpoints of the world can't.

We can (answer all of them, at the touch of a button.)


Best wishes,
Sanjay