Establishing a secure channel for communication is an idea that dates back more than 100 years. Today, secure methods of data transfer are integrated into most technologies so deeply that the greater public has no idea how it works. A Public Key Infrastructure (PKI) is one of the primary methods for establishing a secure communication channel. A PKI is a framework that uses digital keys and certificates to assist in securing communication and verifying identities.
In this post, we will break down Microsoft’s implementation of a Public Key Infrastructure – Active Directory Certificate Services – and what you need to know about detecting and securing common vulnerabilities found in this important communication and authentication service.
What is Active Directory Certificate Services?
Active Directory Certificate Services (AD CS) is one of the server roles Microsoft introduced in Windows Server 2008 that enables even the smallest enterprises with the ability to issue and manage PKI certificates. At its core, Active Directory Certificate Services consists of a certificate authority (CA). A CA is in charge of signing and issuing certificates to objects in Active Directory (AD). A successful PKI is built on trust. When a CA signs a certificate, it provides its stamp of approval. Any entity that trusts that CA can therefore be certain of the certificate’s authenticity. That is, unless the CA has been compromised.
In the last few years, there has been an uptick of attacks targeting Active Directory Certificate Services. These attacks leverage misconfigurations that allow for privilege escalation that may result in full AD compromise. Do not fear, it isn’t time to pull the plug on your certificate authority. AD CS can be hardened to withstand attacks and service your enterprise in a secure method.
Requirements and use cases for Active Directory Certificate Services
Active Directory Certificate Services does not require a Microsoft license beyond what’s needed to run the Server Operating System (OS). AD CS is simply a Windows Server role that can be added through the Server Manager Dashboard. The AD CS Role consists of multiple different service offerings. The previously mentioned CA is the first of these services and is often synonymous with AD CS itself. Additional services include web enrollment, policy-based certificate enrollment, and even TPM key attestation.
Enterprises may utilize AD CS to issue certificates to internal services such as intranet sites, email, code signing, encrypting file systems, smart card authentication, etc. Many third-party services offer integration options for a managed PKI. Hypervisors such as VMware ESXi allow for integrations that create a subordinate (child) CA that issues certificates on behalf of your AD CS infrastructure. Virtual Private Network (VPN) and wireless vendors offer similar integrations. These integrations must be carefully configured so as not to create vulnerabilities. Regardless of whether you’re looking to deploy a new PKI using AD CS or if you just found out you have one, there are a number of security risks to be aware of.
Common AD CS security risks
The security risks associated with AD CS can be primarily attributed to dangerous defaults and misconfigurations. Before digging into these risks, it’s important to understand how attackers are using certificates to attack AD.
Put simply, AD uses the Kerberos protocol for authenticating users. AD can use certificates issued by its own CA to secure the Kerberos authentication process. Given the right configuration, an attacker can leverage these Kerberos tickets to authenticate to AD without needing to know account passwords. Will Schroeder and Lee Christensen authored what has become the authority on abusing AD CS. You can check out more specifics of these attack strategies here.
Template settings and permissions
The majority of Active Directory Certificate Services problems stem from dangerous CA template settings and permissions on those templates. Typically, users are only able to request certificates for themselves. However, a common certificate template misconfiguration allows for users to request certificates on behalf of any other user including administrators. This configuration is present when the subject name can be supplied in the certificate request.
Given a certificate in the name of an administrator, an attacker is able to request a Kerberos ticket and authenticate to AD as the administrative account. Extrapolating this problem, if users are able to make modifications to certificate templates, then these dangerous configurations can be applied to any template and exploited using the same method described above.
Default settings and misconfigurations
Beyond certificate templates, there are two common misconfigurations related to AD CS itself. These misconfigurations are default settings when installing AD CS. The first is utilizing a single-tier infrastructure. Microsoft recommends implementing a multi-tier deployment, which includes building multiple servers and maintaining an offline root CA. Deploying a multi-tier infrastructure with an offline root CA creates a more secure environment that protects the integrity of the service. Should a subordinate CA become compromised it can be more easily replaced than that of a root CA. Microsoft provides more information regarding this best practice in their documentation.
Reduce your AD attack surface.
The second dangerous default is the lack of auditing. Beyond constantly scanning and fixing dangerous misconfigurations, the only method of detecting threats lies within the built-in AD CS auditing. Unfortunately, many sysadmins don’t even know these exist, as during the GUI installation of a CA, there are no options to enable auditing. This configuration is accomplished on the CA servers after certificate services are installed. Microsoft explains that auditing can be configured through the CA snap-in GUI or on the command line using certutil.
Detecting misconfigurations and securing Active Directory Certificate Services
With so many opportunities to fail, there is still hope. Schroeder and Christensen released PSPKIAudit two years ago to assist in the detection of these issues. Since then, Jake Hildreth has been performing consistent updates to his tool, Locksmith. These tools are both freely available to the community.
The power of Locksmith really shines on the flexibility it offers when detecting and remediating AD CS misconfigurations. You heard it right this tool will remediate AD CS issues. Running Locksmith with “mode 1” will output all detected vulnerabilities as well as the corresponding code to fix each item. There are also fully automated options, but this method should be safe to run in any environment.
Conclusion
Active Directory Certificate Services is a valuable tool in most enterprises. Its integrations with AD and other products provide valuable benefits requested of a PKI. However, it comes with the trade-off of leaving AD potentially vulnerable. Luckily, the misconfigurations associated with AD CS are easily identified and mitigated. These security risks must be continually detected and monitored to maintain a healthy AD CS infrastructure. As a spider once said, with great power comes great responsibility.
