Today Cyber Security plays a paramount role in global security. On this blog, the CEO of Paramount Defenses shares rare insights on issues related to Cyber Security, including Privileged Access, Organizational Cyber Security, Foundational Security, Windows Security, Active Directory Security, Insider Threats and other topics.


July 2, 2016

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 - tokenszKerberos 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

No comments:

Post a Comment