Windows' authentication 'flaw' exposed in detail Security researcher "dfirblog" has forensically examined what he calls a "devastating" flaw in Windows' Kerberos authentication system. The vulnerability cannot be fixed, and the only solution is to use Microsoft's Credential Guard program to prevent passwords from being stored in memory, according to his extensive blog post …
Indeed, they think this ancient flaw is worth commenting on, but have nothing to say about this http://www.theregister.co.uk/2015/12/15/joomla_vuln/ 8 year old sql injection bug in one of the most popular open source CMSs...
You hack it by changing your user agent? By the reaction here you'd think it's easier to get admin on a windows domain than to spoof your user agent.
Wait your honestly comparing a friggin operating system user authentication massive hole (mainly for enterprise no less) to some totally optional userland component probably found on less than %5 (being very generous) of the installs out there? Carry on. (For the record yes there have been some pretty major security lapses in open source as well but this is a relatively lame example).
I imagine the difference that accounts for the equivalence, is exposure.
The first step in exploiting a vulnerability is obtaining access via the required vector.
Joomla web sites are... well... web sites. Usually very accessible, being on the web and all.
The flaw in the Windows authentication system on the other hand (as far as I can tell from the register coverage at least) would seem to require physical access to the machine (the contents of memory being involved).
Could be wrong tho.
CMS web sites are the diseased prostitutes of internet servers in general. Wordpress is even worse. A big bag of hurt that makes even Java and Flash look secure by comparison. I do see your point how context matters but being as I am not responsible for any internet facing servers I tend to be much more worried about desktop security (mostly mine).
So, the final paragraph essentially is saying, "Upgrade to Microsoft's latest desktop OS and Server software, trust us, enable these new untested doohickies and pray". Stuff starts hitting the fan pretty shortly...
Man, I'm getting tired of this... Between crap security patches and crap protocol implementation, I'm glad my other system is a Linux box... Time to give Winders a vacation, perhaps retirement.
In Windows Kerberos is a requirement only if Active Directory is enabled - otherwise it just uses NTLM for authentication which is even worse. Anyway, even in Linux as soon as you have more than three machines and users you need to setup something to authenticate without just relying on local passwd files...
"Kerberos on other OSes is unaffected."
That would be on other OSes thatdon't have disused or disabled accounts, and clear key hashes from memory.
On the bases of repeated reports over the last 5 years, BSD and Linux based systems have been very slow to maintain proper memory sanitation (clearly due to the fact that Windows was forced into attempts at memory sanitation much earlier).
And chances are high the many people have disused or disabled accounts.
So although this particular account is a Windows account, generically it's the kind of fault you'd expect to see on many *nix systems.
Except, of course, that most *nix system don't use network authentication, so they don't use Kerberos, so the "password/key recovery from memory" failures we've seen in the last couple of years have been in local authentication.
When Windows 2000 came out with Active Directory, would you be saying, "Oh look, of course Microsoft's answer to the unmanageability of multiple and large domains is to upgrade to their latest desktop and server, trust us, enable these new untested doohickies and pray"? Every OS version has added new management tools and new security protections, I don't know why that's such a hard concept to grasp.
But the paragraph "by using the password associated with a disabled username (krbtgt). That password is rarely changed, making it possible to bypass the authentication system altogether" seems to suggest the mitigation is that you just change the password for this secret user to something other than default
Is this not the case or would this break authentication across the whole directory?
It's not a one-click process, but Microsoft has a tool to do all the hard work for you:
https://blogs.microsoft.com/cybertrust/2015/02/11/krbtgt-account-password-reset-scripts-now-available-for-customers/
You have to reset it twice, but if you do that, it won't replicate; the script just waits until everyone's on the same page to do it again. You could conceivably set this to run every so often during lulls.
Article title:
"'Devastating' flaw found in Windows' authentication system"
The flaw:
"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."
Opening of final paragraph:
"Dfirblog notes: "Mitigation of most of these attacks is not possible, as this is simply how Kerberos works in the Windows environment"
Ouch! So it works on Windows by automatically installing a backdoor? Who insisted on that feature, I wonder?
Who knew? Practically everyone that actually worked with Kerberos.
Kerberos was never intended to be an authorization service. Not designed for it, and was never implemented that way... Until MS broke the protocol and tried to make it an authorization service.
And still using the insecure NTLM passwords... Guess what, no security.
Just, you can get a visa without a passport (Visa is a credit card, BTW - sometimes money help to get a visa, though...).
Authorization in Windows is much more complex - it relies on Active Directory, local security and objects ACLs... just, before being able to match a user agains the auth data, you need to ensure the user is authenticated.
I'll take a two day drive in a vehicle I know over the nonsensical bread-and-circuses check-in horseshirt, baggage limitations and need to hire a car at the other end (c/w Orlando's ridiculous views on airport tax zones) every single time.
You are free to wander shoeless through the x-ray machine with one checked bag included in the ticket price, and deal with the shuttle bus if you want.
Me, I'll vote with my feet and do my part to drive the airlines and airport management vendors into sense-inducing bankrupcy.
Not denying flying sucks donkey balls but so does that drive and pretty much all travel around the northeast corridor of the US which is why I say most of the people that live there have never lived anywhere else. Their ancestors never wandered far from the boat that dropped them off and so now they are genetically disposed to live in overpriced tiny houses/apartments/studios with millions of other similar disposed ants.
Itzman: "That takes a Visa,"
LDS: "Visa is a credit card,"
AC: "Comical, looks like you never left Royston Vasey, try getting out in the World."
Capital "V" visa, except if the first word in a sentence, is incorrect when referring to the stamp put on your passport. That "visa" should never, in English, be capitalized unless it's the first word of a sentence.
The credit card "Visa" needs to have an upper case "v" no matter where it occurs in a sentence.
LDS made the mistake of putting "Visa" as the first word of the sentence, where all forms of the word must be capitalized; so part of his point concerning incorrect capitalization and its somewhat humorous result was lost.
"Comical, looks like you never left Royston Vasey, try getting out in the World."
Try being literate. (And that should be a lower case "w" in "world". And your second comma should have been a semi-colon.)
Actually, it's most of the *nixes authorization schemes that is a utterly unable to cope with actual needs, still being designed for needs of forty years ago... when computer had a few highly vetted users and a few processes running... it's no surprise that the more modern ones are much more alike the Windows one. A complex world needs a complex solution....
"in the same vein that setting the localtime into the hardware clock"
The connection here is completely lost on me, unless you felt that case sensitivity was a little too debatable for your rhetorical needs and so you needed to hitch your argument onto a more blatant straw man.
"The connection here is completely lost on me"
Same vein. Mindspace neighbours. They were argued by the same people in the same places with the same mindset with the same justifications.
"a little too debatable for your rhetorical needs and so you needed to hitch your argument onto a more blatant straw man."
Interestingly violent labelgun reaction to an observed truth. So, "F00" vs "foo", and hardware clock/OS DST parity - where do you stand?
"setting the localtime into the hardware clock during DST changes"
I can only guess, given that this is the comment section of "The Register", that you think that comment somehow applies to something like Windows or OSX or some Linux distribution.
But it doesn't. Not to Windows, not to OSX, not to any common Linux distribution.
"But it doesn't. Not to Windows, not to OSX, not to any common Linux distribution"
This argument is old and dusty, and where one was argued the other was argued, and yes, Windows most certainly did this, as my GMT dual-boot Linux repeatedly attested.
Yesterday I *genuinely* caught someone accidentally changing something to use an O instead of a 0. They were annoyed. Why does it matter?!
Ooops, I wanted to write "you CAN'T get a visa without a passport" (usually, some exceptional cases may exist) - meaning you can't get authorization without being authenticated first - that's what Kerberos does in Windows - to be matched against any authorization mechanism you need first to present a valid Kerberos ticket which can be verified, than the login will be matched against any authorization backend the application uses (as long as it is integrated with the Kerberos system). RADIUS for example can be integrated with Kerberos for SSO logins - but Kerberos does only the authentication part, authorization is handled by the RADIUS database. Same for Active Directory.
Article: "Security researcher @dfirblog has discovered what he calls a devastating flaw in Windows' Kerberos authentication system."
oldcoder: "Who knew? Practically everyone that actually worked with Kerberos. Kerberos was never intended to be an authorization service."
That's untrue, but oldcoder played the "everyone knows this" card and then switched terminology, so I'm going to explain.
First, this exploit is with authentication. Kerberos tickets are used to authenticate. The Kerberos Ticket Granting Ticket (tgt) is a function of the Kerberos Authentication Server. Authentication means "are you really that person you claim to be?" Authorization means "is this person allowed to do X?" Just because I can authenticate that I'm a city resident, that does not necessarily authorize me to park my car in the middle of City Hall.
Second, Kerberos manages both Authentication and Authorization. You can authenticate as a valid user in that realm. You can request authorization on a certain client computer (maybe to login over ssh, or to sudo). These are all handled by the KDC.
Explanation of Authentication, Authorization, and Auditing (AAA) https://www.pingidentity.com/en/resources/articles/authentication-authorization-audit-logging-account-management.html
Kerberos overview: http://www.kerberos.org/software/tutorial.html
Having administrative access precludes the need to use this attack vector in the first place. The question is: what other methods can be used to access memory to get this key/value to THEN be able to crack the code and start creating accounts, etc.That is what I would be on the look out for.
Having administrative access precludes the need to use this attack vector in the first place.
This is taken from my early-morning-on-a-bad-day-on-the-road reading of the article...
The way I understood it is that once you have high enough access on one machine within the system, you have the ability to get admin access on any other machine in the network, allowing you to download data, install software and so on..
So I'm an admin on a domain controller or other relevant system on a Windows-based network (sorry if my terminology is off, I do not work on these sorts of things), which happens to also be used by the CEO's machine. This access would allow me to take any data I wish from his machine undetected, even encrypted data that is way beyond my paygrade. I can also install keyloggers so any passphrase or other "access code" is easily retrieved by me.
If I got out of bed far too early then please excuse my brain for still being in pre-coffee idle!
Icon : Good fix for most of your security and all of your privacy woes!
"Any server can be compromised, but does MS have to be so insistent on being the easiest?"
Hacking / defacement stats of internet facing web servers indicate that Linux is the easiest - about 4 times more likely to be successfully attacked than a Windows Server box (that's allowing for relative market share).
"Hacking / defacement stats of internet facing web servers indicate that Linux is the easiest - about 4 times more likely to be successfully attacked than a Windows Server box (that's allowing for relative market share)."
Being an AC and failing to post citations/evidence puts that in unsupportable tosh from the Windows community bucket, alongside NTLM, the decision to allow NTLM to survive beyond 1996 and by association pretty much every product that MS has released that makes use of it...
The good news is that Satya seems pretty happy to disrupt stuff so there's a better chance of NTLM being consigned to oblivion where it deserves to be. I'm hoping for that outcome. :)
"the decision to allow NTLM to survive beyond 1996"
NTLM has been deprecated since pretty much that time. If you are complaining about support for it, may I be the first to point out that samba also supports it and therefore any system that can run samba (which I think includes all the BSDs as well as Penguins) is necessarily a piece of shit.
Or have I mis-understoof your logic.
Samba is all userland though I believe which means it only gets root if compromised if you are dumb enough to run it as root. That said Samba is probably one of the riskier software packages in general you can install on *nix box (Linux distros tends to include it by default which says a lot about Linux but I digress).
Wow look at this
https://access.redhat.com/security/cve/CVE-2015-0240
As I said risky to put in a base system and even worse it looks like most Linux distros run smbd as root after all. Yuck. Proving once again Linux is more like Windows than it likes to admit.
Edit: wow Samba is an even bigger POS than I realized.
Running Samba is slightly different to running apache or mysql.
When you connect to the web server all processes are run as user www-data, when you connect to mysqld all processes are run as user mysql.
But when you connect to samba a new process is forked with your user credentials. Only root can fork processes as other users.
It is correct that samba is running as root.
"Edit: wow Samba is an even bigger POS than I realized."
Easy to say - hard to write secure code. If you want to do the things that Samba needs to do on a computer system, you have to have the privileges needed to do so. That means root.
You do realize we continuously test with Coverity static analysis, Codenomicon protocol fuzzers, and work with Linux vendor security Teams to issue CERT alerts when vulnerabilities are found ? I'd hold up Samba security practices as best-in-class against any vendor, Open Source or proprietary.
Ok I admit not nice to throw poop and I will be the first to admit you have an impossible job, to make it secure to access Microsoft protocols and plumbing. I also understand this a necessary evil for many people but it sure doesn't mean much like the swiss cheese code that is bash, Samba isn't yet another piece of software I am removing from any *nix box I touch. Ports 135 to 139 are like the glory holes of tcp/ip. Being a Samba developer is probably like being a condom maker forced to used latex that has been in the sun too long.
The reason Windows has support for NTLM (v1) authentication is for backwords compatiblity with systems which have no support for anything more modern. For years, this was primarily SAMBA installation: (Win98 had an update available) SAMBA itself was, naturally, late to support Kerebos and NTLMV2, distributors were later, and users were even later.
When MS turned off default support for NTLM authentication, there was /outrage/ from the community of SAMBA users (I don't speak for the developers).. M$ had /deliberately/ broken compatibility with Open Source community!!! Windows was /incompatible/ with Open Source software!!!
The fact that SAMBA still has support for NTLM authentication suggests that they still have users with clients other than Win95/98/SE/2K/2K3/XP/Vista/7/8/10 that are unable to authenticate using other protocols.
And for Windows, the reason is the same: NTLM (v1) authentication is still supported for use with old versions of non-Windows clients.
None of this, of course, has anything to do with the memory-capture flaw described here, which relates to the use of a stored hash, not NTLM authentication, and not even particularly the hash method: since the stored hash is captured from memory, it could have been hashed by any modern hash/encryption method, and the flaw would still exist.
"When MS turned off default support for NTLM authentication, there was /outrage/ from the community of SAMBA users (I don't speak for the developers).. M$ had /deliberately/ broken compatibility with Open Source community!!! Windows was /incompatible/ with Open Source software!!!"
That wouldn't surprise me in the least, but I haven't seen any evidence that Microsoft left the option in to keep the Linux fanbois happy. OTOH I do recall MS using Samba interoperability as evidence that they were playing nice with the competition in anti-trust cases...
NTLM is not deprecated (older versions are, not the whole protocol), because that's how non-domain-joined machines authenticate - also it is used if you access machines via its IP address and not the dns name (many forgot or don't know this situation...) in a domain.
One good reason to setup a domain even for small LANs is exactly to increase security switching from NTLM to Kerberos.
Latest versions of NTLM are more secure than the old ones - you may need to disable fallback features in some OS (or use passwords longer than 15 characters...), ensuring unsupported OS are not in use.
"Being an AC and failing to post citations/evidence"
Not hard to find an example:
http://zone-h.org/news/id/4737
Anyway - this isn't exactly news - Windows has had fewer vulnerabilities than commercial Linux distributions like Redhat and SUSE (and OS-X) that were on average patched faster every year for the last decade.
"Not hard to find an example:
http://zone-h.org/news/id/4737"
That example doesn't back up any of the OP's claims (or the claims made in your post), it's 5 years out of date, and many of the vulns it focusses on are nothing to do with the OS anyway.
"Anyway - this isn't exactly news - "
That's true, A.C.Shillingworths are two a penny and they pop up in el Reg's forums on a regular basis, so we do tend to see the same unsupported assertions over and over again. It's funny how so many A.C.s come up with the same opinion - it's almost as if it's actually originating from a single source - perhaps a malign marketing department with a track record of FUD...
"Windows has had fewer vulnerabilities than commercial Linux distributions like Redhat and SUSE (and OS-X) that were on average patched faster every year for the last decade."
You claim the evidence is "not hard to find", yet you provided no evidence to support any of the claims in the original post or the post I am replying to. If you had evidence, and were willing to stand by it, you wouldn't be posting as A.C.Shillingsworth.
By the way "OS-X" has nothing to do with Linux, that really is something you should be aware of if you are commenting on the relative merits of OSes with respect to their vulnerabilities.
Krbtgt represents the secret key that underpins the Kerberos infrastructure.
For those interested in more details, the name is an abbreviation of "Kerberos Ticket-Granting Ticket", which is a central component of the Kerberos protocol. Any (decent) Kerberos reference will have more information on it.
Kerberos tickets are temporary credentials that users can supply to authenticate themselves to services. TGTs are tickets used to authenticate to the ticket-generating service itself.
Regarding this latest report: I haven't had a chance to review the blog post. Based on what's in the article, I don't see anything that's not part of the classic Golden Ticket vulnerability, which has been well-documented for a while. See for example this SANS article from November 2014.
As other people have posted, probably the best mitigation for this issue is to change the krbtgt password twice, using the script supplied by Microsoft.
Disclaimer : it's early morning and pre-caffeine.
My reading of the article seems to indicate that there is some new attack. My reading of the blog post describes the established Kerberos attacks (ticket forgery and 'golden ticket'). The new stuff to me are the techniques to help detect such an attack.
Am I missing something?
Seriously, no OS is really secureNo OS is inherently secure, but with a few simple steps one can secure any computer:
RACF can be bypassed with a vulnerability in any APF authorized load module
Indeed.
zOS with RACF or one of the other SAF providers (ACF2 or Top Secret) isn't even designed to be especially secure - even APF-authorized modules and application errors like storing credentials in vulnerable locations aside. RACF is only TCSEC B1 certified. In TCSEC ("Orange Book") terms that's stronger than e.g. Windows and typical UNIX systems (C1 or C2), but there are exotic OSes which have been certified at A1 (Honeywell SCOMP and Boeing SNS), which requires formal proof of secure design, among other things.
And there's a semi-formal "Beyond A1" level, though I don't think anyone's claiming to have an OS that meets it.
Even A1 OSes aren't "perfectly" secure, of course, because that idea is nonsense.1 A machine can't determine all possible consequences of an action, so it can't be a perfect oracle in deciding whether to allow an action. So under any sufficiently complete definition of "secure",2 there's no possible decision procedure which gives the "correct" answer when evaluating every request for access.
And of course in practice we know that people aren't capable of designing and implementing complex systems with no errors. And it's impossible in general to mechanically prove complex systems don't have errors (it's isomorphic to the Halting Problem), and doing it even for specific cases is non-trivial.
All that said, the post that started this sub-thread - the "no OS is secure" commonplace - is not responsive to the OP's question about what's new in the particular blog post that inspired this article. As I noted above, though, I haven't had a chance to read that blog post and see what it has to offer that we didn't already know about Golden Tickets.
1And TCSEC criteria aren't the only way to evaluate the security of an OS, because that idea would also be nonsense. "Secure" is only meaningful as an evaluation of relative costs under a threat model, and both of those things vary by application.
2Such as this one: A secure system does everything it's supposed to do, and nothing else.
There's no point in making Windows secure since the first thing it does is upload c:\ to numerous Microsoft servers anyway. Running Windows is like leaving your front door open and going on holiday. All you can hope is that your neighbour's house is more attractive.
You've been given enough warnings. If you still run Windows now, you only have yourself to blame.
Now now.
As much as I'm not a not a fan, sometimes you don't have the choice what you're expected to work on or deal with.
You could certainly level similar sentiments about the earth. It's not very secure against stellar objects, and itself can throw up a major fault on a fairly regular basis and wipe out parts of the system, but we don't have a viable alternative, and certainly not much in the way of backups.
Thanks for listing all of those Active Directory alternatives. BTW, by far the most common alternatives are Samba and ApacheDS... which are vulnerable to this as well, since they're compatible with Windows AD. Pretty much all of the Linux alternatives are Windows AD compatible in fact! Novell eDirectory is about the only exception, and that's deader than a doornail, incredibly limited compared to newer software, and still requires occasional critical security patches.
One of the issues with Linux is it never delivered a "standard" authentication/authorization method accepted by most distros and easy to use. Sure, you can setup different Kerberos and LDAP services yourself, but the lack of a "common accepted implementation" (and easy to use) lead to the fact that Windows AD became so widespread even Linuxes and Apple had to become compatible and offer similar services like in Samba.
IMHO one of the roadblocks of Linux adoption is exactly the lack of such services in a easy to use fashion. Setting up and managing a complex LAN with proper centralized authentication and authorization in Linux requires a level of expertise which is beyond most business but the largest, or very dedicated ones.
But Samba and other AD implementations may not be vulnerable - it all depends on how they designed and implemented their KDCs.
"IMHO one of the roadblocks of Linux adoption is exactly the lack of such services in a easy to use fashion. Setting up and managing a complex LAN with proper centralized authentication and authorization in Linux requires a level of expertise which is beyond most business but the largest, or very dedicated ones."
FWIW, it looks like FreeIPA is picking up some steam.
@MattPi
"Setting up and managing a complex LAN with proper centralized authentication and authorization in any operating system requires a level of expertise which is beyond most business but the largest, or very dedicated ones."
But its a lot harder for ones who are trained by just one organisation who likes to pretend computing is easy.
Computing has also to be "easy enough" for your business needs.
You can't ask every business to hire very highly skilled (and very expensive) personnel, when their computing needs are not so high and not their core business - especially since it's not a one time setup you can hire "consultants" for, you also need those who will have to maintain it.
If you do expect everybody is ready to learn "arcane and esoteric" way of doing things, or will hire someone able to do it, you're wrong, they will look for something simpler and easier. Just like most people prefer smartphones to take photos instead of a view camera... or just like most people prefer to play an mp3 instead of playing an instrument...
Which, being a RedHat sponsored project has good chances to be rejected by some "purists" like the Debian graybeards... although probably that's one of the reasons they built in on many already accepted software, although keeping tight and coherent all that stuff developed independently may be not easy...
"Only if it's Adolf the Red Nosed Reindeer."
No, that's Commissar Rudolph who worked in the Moscow Meteorological Office. His English wife complained it was snowing, he looked at the thermometer and replied "No, Rudolph the Red knows rain, dear."
Is it possible to get any further off topic?
"Is it possible to get any further off topic?"
It might be off-topic but not off-accompanying-photograph, as in (with apologies to Roky Erickson): "Three-headed dog, Three-headed dog, I've been working in the Kremlin with a Three-headed dog!"
If so then if I have that level of access to a DC, all I have to do is code up a DLL in C that hooks into the Windows LSA API, drop it on a DC, hook the DLL into the registry and it'll start spitting out clear text names and passwords every time a user changes their password!
It's a "must have dumped domain credentials (at least for krbtgt)" thing. Full domain admin privileges are sufficient, but not necessary. This is an elevation of privilege: an attacker might manage to get krbtgt's key without having admin, for example by getting hold of a memory dump, and then leverage it (Golden Ticket) to gain full privileges.
If I'm reading the linked blog post correctly, this isn't as bad as it sounds surely? To get the krbtgt account password, you need admin level access to a DC, remotely or otherwise. Also, to read cached tickets of other users on same machine, you need admin level access again - local machine or otherwise.
Whilst a problem admittedly, in a network where there are only one or two admins anyway, then as long as their accounts are not compromised, this attack can't happen. Am I right?
Right...
Can someone please wake me up when they find:
0- Something actually new.
1- Something that works from a random domain member with a regular user account. Or, worse yet, without a user account.
...?
Thank you.
PS. Note to Reg Editorial staff: Google is your friend.
PPS. Unless, of course, you were going for sure-fire click-bait. In which case: well done!
In the olden days, it was not necessary to explain the Lyre/Cerberus reference because people were actually taught about Greek mythology because of the relevance of ancient Greeks to the formation of civilisation.
At least someone in El Reg was able to sneak in a quick lesson in the article. Well done!
How exactly is this new? Surely this is what mimikatz et al have been doing for ages, even the links on his blog point to posts from last year about these issues and it was demonstrated at BlackHat at least a couple of years ago if memory serves. The point is that you need access to a DC in the first place (not that that's necessarily that hard to do), once you have that you can do what you like anyway.
In the 60s we were presented with the hilarious scenario in 'Get Smart' when Agent Smart would insist the Chief bring down the Cone of Silence. The subsequent disfunctional conversation reminds me of the effects of Security Measures upon many OSs.
Constant diligence of network and user activity, quotas, and applying known patches go a long way to thwarting exploits.....but they require resources that are often considered to be not cost effective.......until they are.
(From a post I made to samba-technical@lists.samba.org):
Hmmm. Doesn't look real as far as I can see
(the article is full of hyperbole).
It's got lots of phrases like:
"So, if we have an access to the key.."
"if we’re able to steal those tickets and somehow
insert them into our own system"
"It’s just an account in domain controller
database, so your obviously need access to DC or it’s data."
So looks like a "if we can break the security
then we've broken the security" article :-).
very funny because just today the US gov is saying they're going to force the OS makers to make their operating systems unlockable to a warrant..
truly hilarious that all Windows enterprise networks are unlockable with a publicly known static key.
There's your back door, fellas, any other requests?
The updated quote ends with:
"It is important to be aware that only organizations that already have a fully compromised domain controller are vulnerable to this technique."
I claim only minimal knowledge of Kerberos & co, but that quote basically makes this article a case of "if you are already 100% compromised, more bad stuff can happen"?
Or is the truth something else?
This whole krbtgt debacle is usually misunderstood. Same as the last two Reg articles about the same 2 years old+ "new" vulnerability.
This is mostly a persistence mechanism. After a DC is popped the access can be regained unless krbtgt is changed.
(Over-)Pass the hash is even older technique.
Basically if you have superuser access to a machine you can nick another users credentials, well big woop. I can criticise Windows more than the next man but any system can steal credentials if you are superuser (e.g on Unix steal tgt from /tmp or memory, or on another auth system, straight from memory)
Then if you are superuser you can pretend to be a DC (KDC). Also no huge surprise there. Best practice on a MIT KDC was to put on a single function box, either with no remote access or at least not authenticated by Kerberos to try to reduce this risk. But on all modern Directory services being an integrated solutions (combined with LDAP, DNS etc is more important and makes life easier but does increase your attack surface.
Add to this a healthy dose of don't use ntlm and rc4 (who knew). Probably best to turn off all ntlm and just use Kerberos in AD in pure AES, though this hasn't been the easiest thing to do in AD (MS should have ditched ntlm fully years ago and Still haven't and is still crap even v2).
No criticism of the original paper just the slightly alarmist tone of this article.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
