Posted on 12/15/2015 1:41:21 PM PST by dayglored
Security researcher @dfirblog has discovered what he calls a devastating flaw in Windows' Kerberos authentication system.
The flaw cannot be fixed and the only solution is to introduce and use Microsoft's Credential Guard program to prevent passwords from being stored in memory, according to his extensive blog post.
The flaw results from how the third-party authentication system creates secret keys: by using the password associated with a disabled username (krbtgt). That password is rarely changed, making it possible to bypass the authentication system altogether and allow an attacker to grant themselves admin privileges, as well as create secret passwords for existing users and new users that don't exist.
Although some of the entry points are time-limited - the system will seek to validate accounts after 20 minutes - because it is possible to create fake users without limit, it is possible to access a system incessantly.
Kerberos is a default authentication protocol in Windows networks and authentication clients and servers. A flaw in the system noticed last year, for example, would enable an attacker to compromise an entire network, including installing programs and deleting data. This flaw appears to be very similar.
Kerberos, or Cerberus, is a mythical three-headed dog that guarded the underworld. He was outfoxed a few times, sometimes through brute strength, but Orpheus managed to lull the fearsome dog to sleep by playing his lyre before sneaking past. Access all areas
Dfirblog notes that the secret keys are generated to avoid having to send passwords across the network to authenticate users and are derived from user passwords and stored in memory.
But the secret keys are not salted and use the NT LAN Manager (NTLM) hash of the user as a key, so are relatively easily retrieved. The krbtgt user is created when the system is first installed and is inactive, so it can remain untouched on a system for years - providing ready access to a hacker.
The post then goes into some detail about what can be done once into the system, including adding new users, producing secret second passwords for existing users, and downloading files on the systems to review later.
Dfirblog notes: "Mitigation of most of these attacks is not possible, as this is simply how Kerberos works in the Windows environment ... For the most part, you need to focus on protecting privileged accounts at all costs, because this is what attackers are after and protecting everyone is not possible. The most effective mitigation at the moment seems to be Protected Users group and Credential Guard."
Update: A Microsoft spokesperson has told us in response to the flaw: "We are aware of the Golden Ticket and Pass-the-Hash techniques and encourage customers to follow our guidance at www.microsoft.com/pth to help protect themselves. It is important to be aware that only organizations that already have a fully compromised domain controller are vulnerable to this technique.
What would you say to someone who breathlessly announced they had found a fundamental flaw in the Linux OS that gave you complete control of the machine, but only if you're logged in as Root?
1. If there's a security vulnerability due to a design flaw or implementation error, and the story we hear is that it's only available for exploitation when one is already logged in as root, then yes it is serious and yes it has to get fixed, just as if it didn't require already being root.
2. That is especially true if that story comes from the same outfit that made the error in the first place. What level of reliability should one place on a glib dismissal of risk made by the same outfit that didn't know enough to catch the error when it happened?
3. Being logged in as root does not give you complete control of the machine. Being root has limits: for example, root can't decrypt strong encryption or a good password hash. If a security vuln allowed root to do more than they could without it, then it obviously needs to get fixed, not excused.
If that’s your take on it, then you need to go shut down all of your Windows servers. Now.
The "fix" is to install Credential Guard.
Windows stores passwords for service accounts and interactive logins in memory. Programs like MimiKatz running under local admin authority can read them. The "vulnerability" this researcher claims to have found has been known about and discussed by Microsoft and various people in the security community for quite some time.
Agreed.
I don't have that option. We have some mission critical applications that only run on Windows Server.
So instead of shutting them down, I do what's possible to protect them from intrusion and compromise. For example, none of my Windows machines -- servers, workstations, any of them -- are reachable directly from outside the LAN (which itself is securely locked down and monitored). The machines that face the outside are hardened Unix and Linux. Granted, nothing is perfect, but I prefer to depend on *ix at the outer perimeter.
You may recall that about a decade ago, Microsoft's Jim Allchin, who was a central figure in the development of Windows Server and the building of Microsoft's server business, wrote:
"I think our teams lost sight of what bug-free means, what resilience means, what full scenarios mean, what security means, what performance means, how important current applications are, and really understanding what the most important problems our customers face are."Have things changed? Sure. In my opinion, Windows Server has many strengths and has come a very long way in the direction of serious security, but it's still got a way to go, and a sysadmin who puts Windows on their outer perimeter today is taking unnecessary chances.
Nonetheless, there's no need to shut them all down. Just protect them. :-)
Part of that is knowing what the weaknesses are so you know what to concentrate on. Your reaction to the article seems to indicate you didn't know about this one.
What I can’t belive is that they are still using ntlm. That has been known for years to have serious unfixable flaws.
Astounding.
I had heard about it but I'll plead guilty to not paying it much attention, as my professional concentration has nearly always been *ix -- Windows servers have been a pain in my ass whenever I've had to deal with them professionally (which is since NT4 in the mid-90's). I have great respect for guys who choose to become serious, experienced Windows admins -- it's a hell of a row to hoe. It's not a path I would choose.
So since I've been fortunate (so far) and there's been an experienced Windows admin on my team wherever I've worked, I've only had to know a little about Windows, relative to my knowledge of Unix and Linux, which has been my concentration. And there's plenty there to be concerned about, security-wise, too.
Create a bootable Linux Live USB stick and boot your Windows computer. You can see, access, change or delete any file on the hard disk with NO password required. A janitor with a Linux Live USB stick could look at every file on every Windows computer in your office.
That's why most of them are VMs without USB or CD/DVD, and the metal instances are physically inaccessible without (physical hardware) keys.
There are numerous safeguards to protect against this.
Use the “Protected Users” group in AD
Turn off Kerberos delegation for privileged users (protects against PTH as well)
Use fine-grained password policies for privileged users and require 15+ character pass phrases
Use attribute-based access control for privileged resources such as domain controllers
You can also change your krbtgt account password on a regular basis. We have ours scripted as a scheduled task that runs weekly. It’s as secure as salting your password hashes.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.