Public key infrastructure (PKI) is a foundational technology for most enterprises when it comes to maintaining security. But it’s also a technology that’s all too easy to deploy and run in the background without giving much thought to updates or ongoing improvements.
So how do you make sure PKI continues to perform up to evolving standards? And what can go wrong if you don’t take this proactive approach?
That was the premise behind our conversation with Chris Hickman, Keyfactor’s Chief Security Officer, and Will Schroeder and Lee Christensen, technical architects at SpecterOps, an adversary-focused cybersecurity provider that helps defend against advanced attacks.
Most recently, Will and Lee brought light to this concern when they published a new whitepaper based on research they did about Microsoft Active Directory, including a wide gamut of common misconfigurations in Microsoft’s PKI implementation that can be exploited. Here are some of the highlights from our discussion.
What are some of your key findings from the report?
Lee: Something that really stuck out to us with Active Directory Certificate Services is that it’s very ubiquitous in enterprise networks. But it’s also old and not very well understood. Overall, there’s not a lot of security considerations around it even though it’s used everywhere and is key to authentication and how the network is run. That makes it a ripe target for attackers.
Will: What’s interesting with this research is that, because Active Directory Certificate Services is so expansive and so integrated in Active Directory, it wasn’t just one flaw or one way to escalate. We broke it into a variety of ways that people could steal certificates or maliciously enroll certificates for the purposes of credential theft and machine persistence. We ended up codifying everything into credential theft, domain escalation and domain persistence, which are all very expansive and interesting all in their own right.
Lee: The domain escalation issue has also become very timely recently. At the end of July, there was a lot of news about a new type of NTLM relay attack called PetiPotam. The root vulnerability in that attack is Active Directory’s Certificate Services allowing an unprivileged user to escalate to domain admin rights over the Windows network.
Another big thing is looking at how an attacker can obtain or persist in a network using Active Directory Certificate Services. A good example of this is when you log in to a Windows network with your username and password. When you have Active Directory Certificate Services, you can now log in using a certificate that’s completely separate from your password. But a lot of network defenders don’t actually know about this. In that case, even if they wipe the machine or reset a compromised user’s password, if the attacker has that user or that computer certificate, they can still log on as that user or access that computer. This is a major blind spot on the detection and the incident response side of things of which defenders need to be aware.
How does the fact that many organizations don’t necessarily realize they’re using certificates in so many different places impact these vulnerabilities?
Will: Certificates are everywhere, and if people don’t understand and grasp the security implications, it’s extremely easy to have one bit flipped in one certificate template that compromises the entire network. What we’ve seen is an overall lack of familiarity with Active Directory Certificate Services.
Lee: The other thing to note is that Active Directory Certificate Services came out in 2001, and it’s been chugging along over the years. Since it’s been in organizations for so long, it’s easy for a misconfiguration to happen or for things to be enabled that may cause an insecure configuration. It’s important for teams to do maintenance on it and see how things are looking.
What are some of the risks tied to that lack of familiarity with the program?
Chris: What we’ve seen is that people make configuration changes out of necessity. They find a knowledge article about how to do it, and it works; but they don’t fully understand the downstream implications, and these seemingly minor changes impact the trust you put in that infrastructure over time. It opens up a Pandora’s box of vulnerabilities.
Will: We like the term misconfiguration debt. Those small changes made by someone who’s just trying to do their job build up over time. We have a lot of empathy for system administrators, because it’s very easy to accidentally misconfigure these systems in a profound way.
Chris: From my experience, we have to put things in context. Active Directory Certificate Services is a CA. A PKI is an entire infrastructure that involves a CA and many different other things. It’s like having an engine, a steering wheel and four tires — that doesn’t necessarily make it a car. It’s how all those systems work together that give you the confidence to drive at speed.
A lot of people look at Certificate Services and say it’s as good a PKI as any other, when, in fact, the full infrastructure isn’t there to make it the right system for an organization. It doesn’t have all the safety features and compensating controls that you need to recognize the technical debt you’re building and, more importantly, the risk debt behind that.
Are there any trends you see that lead to these situations where Active Directory Certificate Services is overlooked or misconfigured?
Will: We often find there’s not enough cross-pollination between security teams and the other teams that manage Active Directory, which makes it easy to overlook these issues. Or if organizations have never led a PKI assessment, they might not know what the issues are.
Lee: Surprisingly lots of vendor documentation has led to these vulnerabilities. Several products have suggested enabling subject alternative name (SAN) settings that can lead to a very insecure state of PKI. It’s complex, and even vendors don’t realize exactly what they need to do.
It’s also very hard in Active Directory environments, and large networks generally, to understand the implications of changes. What happens if I alter this one setting or add a user to this one group? Will that allow someone to escalate their privileges? Our goal is to increase that visibility.
Chris: I agree visibility is a huge part of it. That’s one of the reasons why Keyfactor’s Command platform provides visibility into what certificates are deployed and why they’re deployed, so you can find those anomalies and apply policy consistently across every certificate that’s issued. That way you can catch vulnerabilities or misconfigurations before they become an issue.
The other point I’ll add is that when you’re implementing something free, it’s hard to explain to leadership that there’s a cost associated with managing its complexity long term. Most organizations are just not equipped to look after what PKI becomes at the end of the day.
Looking at where a PKI can go wrong, is there anything that you come across often?
Chris: The biggest mistakes are sometimes the easiest to make. In this case, that’s something like flipping a switch that allows you to put alternate names arbitrarily into certificates. Overall, the research really highlights some of the dangers based on the fact that Active Directory Certificate Services was configured 20 years ago and has not necessarily moved at the same speed or with the same security alacrity as some other products have.
Will: There was one particular misconfiguration that we cover in the report that we called escalation eight. The first seven are issues where people had to misconfigure things post-install. Escalation eight is something that’s stock that we wish Microsoft would fix.
Lee: In that case, there’s an additional server role that is often enabled with Active Directory Certificate Services that allows you to request a certificate using HTTP.
If this is enabled, which we often see it is, anybody can request a certificate using the HTTP protocol. The problem here is that it uses NTLM for authentication by default. There’s an attack called NTLM relay that allows attackers to impersonate a user. If Will tries to connect to my machine, I can impersonate Will, and then connect to Active Directory Certificate Services and request a certificate as him. Or there are some tools like PetitPotam or SpoolSample that allow me to coerce an arbitrary computer in the network to connect to me. Then I can impersonate that domain controller using NTLM relay and request a certificate from Active Directory Certificate Services from that HTTP in point. I can obtain that certificate and then log on as a domain controller, giving me access to users’ passwords and their hashes.
This can be used to compromise a network, going from low privilege all the way to forest administrator. It’s a vulnerability that we see in environments all the time.
It’s not just theoretical. You’ve been able to compromise using this methodology?
Will: That’s right. Vendors and organizations are sometimes hesitant to go through the efforts to fix issues that are regarded as theoretical. This gets into the realm of releasing proof of concepts or offensive tooling, which we try to do ethically, but we found that change doesn’t really come about unless people can see that the attacks are real.
Lee: We’ve used all of the escalation scenarios we identified, and even all of the trade craft that we identified. This is actual stuff that bad guys can do in your network. In response, we came out with a defensive tool set so people can start getting their eyes on this stuff. One of those tools is PSPKIAudit, which can identify these issues with Active Directory Certificate Services.
We also have a product called Bloodhound that has an open-source version and an enterprise version. We’re actively working to incorporate the detections of these vulnerabilities into that as well so people can get their eyes on it and can fix it in their environments.
What are your recommendations for PKI architects to address these vulnerabilities?
Will: Tools like PSPKIAudit will enumerate the misconfigurations we know about and then allow you to try to fix them, but keep in mind there’s no just “fix this one thing.” You have to understand what settings are there and why they’re being used so you don’t break existing functionality.
On top of that, it’s important to think about certificate services from an instant response security standpoint, meaning if someone does compromise an account or a system, do you have a way to identify which certificates were issued from that user? That’s a very hard problem for many organizations to actually answer, because the implementation of Active Directory Certificate Services doesn’t have really good management features.
Chris: The other thing to note is that it’s really hard in PKI to go back once you establish trust. If you have certificates out there with arbitrary SANs and no way to find and revoke them, you could turn the configuration setting around, but that doesn’t necessarily remediate the issues. It’s difficult to put the horses back in the proverbial barn.
Interested in learning more about the vulnerabilities in Active Directory Certificate Services and what your organization can do in response? Click here to watch the full panel discussion with Chris, Will and Lee.
