'Devastating flaws' in Kerberos authentication protocol
Security watchers warn of authentication and authorisation flaws in Windows network environments
Kerberos is designed to provide strong authentication for client/server applications by using secret-key cryptography.
With the rise of Software Defined Networking (SDN), cloud and data centre network technologies driving more of our front end mobile computing experiences, concerns over the legitimacy and robustness of our ‘back end' have arguably never been higher. In this regard, new fears have surfaced relating to the Kerberos network authentication protocol.
Kerberos is designed to provide strong authentication for client/server applications by using secret-key cryptography. A free implementation of it has been made available by the Massachusetts Institute of Technology (MIT), although Kerberos is available in many commercial products too.
Kerberos is used by default in Windows networks and provides mutual authentication and authorisation for clients and servers. It does not require the use of a password or a ‘hash on the wire'; instead it relies on a trusted third party for handling.
MIT itself specifies that Kerberos was created by as a solution to network security problems. This protocol's cryptography is supposed to ensure that a client can prove its identity to a server (and vice versa) across an insecure network connection.
“After a client and server has used Kerberos to prove their identity, they can also encrypt all of their communications to assure privacy and data integrity as they go about their business,” says MIT.
According to Computer Security Incident Response Services (CSIRT) hackery, incident response & forensics blogger @dfirblog, “Although, it is considered a secure protocol, it [Kerberos] has some flaws in Windows environments with devastating consequences.”
In order to follow this story, we need to define a handful of key acronyms:
- KDC (Key Distribution Center) – a central entity responsible for all authentication tasks.
- Ticket-Granting Ticket (TGT) – a ticket is granted by the Authentication Server (AS) for user after initial authentication and is necessary to request service tickets.
The root of the attack
So asks @dfirblog, how do we prove to the KDC that we who we are and request a TGT?
“Well, we just encrypt current timestamp with our secret key. That's what a normal process looks like. So, if we have an access to the key – we can repeat this process on behalf of the user and gain legitimate Kerberos tickets and thus access. Essentially skipping the part of Kerberos authentication, where user secret key is created from his password,” he asserts.
Writing in a BlackHat.com white paper dedicated to protecting Kerberos monitoring, authors Tal Be'ery, sr. security research manager at Microsoft and Michael Cherny, sr. security researcher also at Microsoft say that we know that Golden Tickets are Kerberos TGTs forged by attackers.
“The attacker can control every aspect of the forged ticket including the Ticket's user identity, permissions and ticket life time. Attackers typically set Golden Tickets to have an unusually long lifetime, which allows the possessing entity to keep using them for a long period without renewal. In addition to the lifetime, other important attributes of the ticket are typically forged to achieve other nefarious goals, such as assigning very high permissions, impersonating other users and even using non-existing user names,” write Be'ery and Cherny.
Fraser Kyne, principal systems engineer, at Bromium told SCMagazineUK.com that trying to protect the Operating System (OS) from within relies on the integrity of all the security layers you put in place – from encryption to access controls, via protocols and everything in-between.
“Vulnerabilities in any one of these areas becomes the weak link in the security chain; and a compromise in a single component can be fatal,” said Kyne. “Instead of just ‘defence in depth”, wise CISOs are considering ‘defence in diversity' whereby they de-risk their reliance on each link in the chain. This is manifested in an increasing focus on isolation. Networks are isolated and systems are isolated from each other. We're seeing vendors like Microsoft (and ourselves at Bromium) moving towards isolation on the endpoints themselves by using hardware virtualisation. Microsoft can use Credential Guard to stop the successful compromise from stealing the credentials stored on the system; and Bromium can use microvirtualization to isolate the initial attack to stop the compromise in the first place,” he added.
In summary then, @dfirblog claims that, “Mitigation of most of this attacks is not possible, as this is simply how Kerberos work in Windows environments. For the most part, you need to focus on protecting privileged accounts at all cost, because this is what attackers are after and protecting everyone is not possible. Otherwise you will lose control of your network really fast. The most effective mitigation at the moment seems to be Protected Users group and Credential Guard.”
The protocol itself was named after the Greek mythological character Kerberos (or Cerberus), a ferocious three-headed guard dog or hellhound who lived in Hades.