Root Causes 236: Active Directory Patch Knocks Out Non-MS Identity Consumers

Hosted by

Tim Callan

Chief Compliance Officer

Jason Soroko

Fellow

Original broadcast date

August 4, 2022

A recently revealed vulnerability in Active Directory made it possible for an attacker to escalate privileges inappropriately. Microsoft's responded with a patch in May 2022, which unfortunately has forced a difficult workaround for many common software components beyond Active Directory that will otherwise be incapable of working with AD identities. In this episode we explain what his happening, how it came about, and the broader lessons for PKI owners.

Podcast Transcript

Lightly edited for flow and brevity.

Tim CallanWe want to talk about an interesting story that has been developing for a few months now involving a patch from Microsoft.

Jason SorokoWe’re talking about a patch that happened on a good old fashioned Patch Tuesday, on May 10, of earlier this year, 2022 and we really want to talk about it because I think for those of you who utilize Microsoft Active Directory, especially Microsoft Active Directory Certificate Services, you really need to understand what’s going on in that world, what Microsoft’s intentions are and to get maybe a bit of insight for how Microsoft, themselves, thinks about that system.

Let’s get into a little bit. So, let’s start with an old story, which is for those of you who have ever used Active Directory before, which is probably most of you, I hope, or if any of you come from a traditional enterprise environment, you’ve probably dealt with it in some way, shape or form. And don’t know if you know this, of course, but if you’ve ever attached yourself to an Active Directory environment, in other words, attached into a domain controller, you can call your computer whatever you want. So in other words, your DNS Host Name, if you want to get technical about it, the chance of collision between computer names in the Active Directory world is high, but nobody really worried about it too much. And certainly, until May 10 of this year, Microsoft made really no attempt within Active Directory to stop the collisions from happening. So, some really smart white hats took a look at this and decided, specifically for systems that where the domain controllers are basically authenticating with certificates and where other computers are authenticating through certificates as well using Active Directory Certificate Services are there certificate profiles such that you can name your computer whatever you want rule and basically then, escalate your privileges from a low privileged computer account up to something that is maybe all the way up to a domain controller, a domain administrator.

Tim CallanSo, by giving my computer the right carefully crafted name, I can actually give myself God privileges? That’s a problem.

Jason SorokoThat’s a problem. So in other words, we’ve got to be really careful. This is not a remote control zero day type of bug. This is effectively an escalation of privilege. The bad guy would have to already be on the network. But, unfortunately, bad guys are on networks. So this is a real problem. So, and trust me, there’s a lot to this story. Even about, adding a dollar sign to the end of the computer name to be able to specifically get log-in information and a certificate issued with it to your computer name to be able to impersonate an actual domain controller account somewhere else. There’s a lot to it, but I’m trying to keep this a little bit over-simplified. So then a knowledge-base got released, and I’m going to read this out pretty much directly: Before the May 10, 2022 security update, Certificate-Based Authentication would not account for a dollar sign at the end of machine name. This allowed related certificates to be emulated spoofed in various ways. So that’s right out of their knowledge base. So, what Microsoft decided to do in a very, very, very Active Directory centric way of thinking, Microsoft then decided in the May 10 Patch to force a new OID to the certificates which contains the Object SID which is essentially a security identifier of the Active Directory computer account. So, instead of you being able to choose how you are issued out within a certificate that is issued out by Active Directory Certificate Services your certificate will contain this OID which regardless of how you name your computer, would now identify you very specially how Active Directory sees you uniquely.

Tim CallanThat prevents me from, changing my identity ‘cause I am what Active Directory says I am.

Jason SorokoExactly. So, ultimately, this is a decision by Microsoft; can no longer make the DNS Host Name the main identifier of the computer. That’s great. So in a world where every single issued certificate from Active Directory Certificate Services, the computers log in, through the main controller, then that completely makes sense. There probably would be very few exceptions. Well, there is a bit of a problem. So, the problem with the May 10 Patch, and I’m going to read this about word for word from the Tweet that came out of Microsoft, the root cause is the subject name is incorrectly used to map the cert to a machine account in Active Directory rather than a DNS Host Name in the subject alternative name on domain controllers that have installed the Patch. So what the heck does that mean?

Microsoft issued a Patch to fix the Patch and whenever you get into that kind of thing, Tim, you know what that’s like. That’s a snowball of hot patches, warm patches, mild lukewarm patches. It’s just a nightmare. And so, domain controllers themselves, Tim, were being mapped incorrectly, so the Patch for the Patch helped to fix that. So, that’s great. That at least means that your domain controllers can come back online that were authenticating with Active Directory Certificate Services certificates, but then the problem became what about anybody else who was sending their certificates to be used offline. In other words, things that were not essentially attaching to Active Directory, you were just using the certs. Wwe’re talking about offline systems and I’m going to name off a bunch of acronyms, and actually state what acronyms are, and Tim, the reason I’m going to go through this list is I want to show you how extensive these certificates are used in systems that are not necessarily Microsoft stacked technologies or logging into Active Directory and that includes the Network Policy Server, NPS; Routing and Remote Access Service, RRAS; Radius Extensible Authentication Protocol, EAP; you guys probably, anybody using that for logging in through WiFi access points you know about that one. So if you’re using certs for that and the Protected Extensible Authentication Protocol, PEAP which has been around. All of those things can consume Active Directory Certificate Services certificates and not necessarily have a direct mapping between this Object SID, the Security Identifier from Active Directory, and the machine itself. How in the world when you’re using the cert is that OID, what would you map it too. What to you map it to. What do you map it to. So, in other words, Microsoft seems to have completely forgot about PKI used outside of Active Directory. If you really want to put a sentence to it, that’s the sentence.

Tim CallanAnd this is still the case today?

Jason SorokoWell it is. And so, Microsoft work-around, Microsoft does have a work-around which is, okay, well we will allow you to use a specific attribute within the certificate. You can actually go ahead and say explicitly within Active Directory this particular machine I want to identify in a different way. And so you can use essentially an alternate identity within Active Directory. The problem is that it has to be done manually. Now what a lot of consultants have said and even the first thought that came to my mind was well, I would probably program something in PowerShell to automate some of the that. The problem is, Tim, how much BYOD devices are out there?

There’s a ton. There might even be a lot of stuff you don’t know about. What a nightmare to have to reissue certificates. You have to manually figure out, alright well what is my identifier going to be? I have to specifically put the settings for every one of these devices. So, real problem. Ironically, anybody who chose to do Active Directory Certificate Services certificates as part of their authentication scheme, thinking well this is making me more secure. Well, it probably is. The problem is that you’re dealing with a PKI that is so fundamentally ensconced inside of Active Directory. I think that, Tim, if we were to come up with, as you always ask me for, a pithy conclusion, a pithy definition, I think what it comes down to is when you’re choosing your PKI, even though you can pump a cert, ask yourself whether that cert pump, meaning Active Directory Certificate Services, is playing nice with the types of things that you are using your certificates for. In the Microsoft world they are so, so focused on Active Directory that even though they have given their customers ample ways to use those certificates any way they like, you should ask yourself, should you? Should you in the future use those things any way you like? And the answer to that probably is what, if I’m using certificates for non-Microsoft stack technologies I probably should not be using legacy Active Directory Certificate Services.

Tim CallanI was just going to ask. I was going to say, so what’s the path forward? What’s the path forward, cause it sounds like this is far from solved and a good amount of time has passed. What’s the path forward for Microsoft and what’s the path forward for like an individual enterprise that’s trying to deal with this?

Jason SorokoUnfortunately, at the moment for the people on the ground, you’re probably, if you haven’t experience PowerShell manipulating Active Directory Certificate Services yet, and we talked about that. You and I already had podcasts about basically enumerating your configuration settings in Active Directory Certificate Services in order to make sure that you’re not configured in such a way that it’s easy for the bad guy to do bad things to it. That’s PowerShell. PowerShell has been often used to enumerate, diagnose perform all sorts of diagnostics and also even test for, hey can I act like the bad guy and basically PIN test myself? PowerShell can be used for a lot of that. I would say that for the immediate, the immediate concern, definitely patch the Patch. But be careful about understanding what each of those patches is doing and not doing at this moment. In fact, I think even SISA has issued some statements about what to do and what not to do. They have some advice on this. So please do your due-diligence. Do your searching. But I think your question, the spirit of it is what’s after the initial blast of oh my goodness, I have systems down. I think what it comes down to, Tim, is there are vendors in the PKI community who will augment your Active Directory Certificate Services and also give you a path forward to eventually replace it so that you can enter the current real world of you will be using technologies that are not just Microsoft stacked. I don’t know of any enterprise that is 100% anymore. There may have been a day back in the past, but I don’t think that really is likely anymore, and so therefore, I think the path forward is augmentation and eventual replacement. That’s to me the way to really think about it.

It is a crazy story, and God bless the people at Microsoft. Good people. Always well intentioned. The thing is, what an oversight. Forgetting that you had usage for your PKI outside of Active Directory. I just have to shake my head because when I finally read through it, that was my conclusion and I just couldn’t believe what I was reading.

Stay informed with expert insights

Subscribe to Root Causes for engaging discussions on PKI, digital security, and best practices for protecting your organization's critical assets. Don’t miss an episode!