Risk to the Active Directory overall structure through the EDITF_ATTRIBUTESUBJECTALTNAME2 flag

In net circulate unfortunately much at many Instructions (also the big players are not excluded from this, not even Microsoft itself or the Grand Master Komar), which fatally recommends that the EDITF_ATTRIBUTESUBJECTALTNAME2 flag should be set on the certification authority - supposedly to be able to issue Subject Alternative Name (SAN) extension certificates for manually submitted certificate requests.

Unfortunately, this approach is not only unnecessary, it also has some unpleasant side effects, which in the worst case can help an attacker to take over the entire Active Directory forest.

Background

Is the setting required for issuing certificates with SAN extension?

Clear no!

If the certificate request already contains a SAN extension, this can also be issued by the certification authority when the request is submitted manually. For this purpose, the object identifier for the SAN certificate extension is already set in the certification authority's policy module in the default setting under "EnableEnrolleeRequestExtensionList" registered

The reason why most cases described on the Internet and in the relevant literature advise activating the flag is that the certificate signing request (CSR) sent to the certification authority does not have a SAN extension, but this is desired.

So the real problem the authors are trying to solve is to add the SAN extension to the certificate request after the fact. However, they cannot modify the certificate request directly without rendering its signature unusable.

In fact, after setting the flag, when submitting the certificate request one is able to any attributes - among other things also the SAN extension - but this has a Very high price.

What does the EDITF_ATTRIBUTESUBJECTALTNAME2 flag do?

If the EDITF_ATTRIBUTESUBJECTALTNAME2 flag is set, a requester can pass additional attributes to the certification authority via a name/value combination while sending the certificate request to the certification authority.

Usually, the certification authority decides on the content of the issued certificate based on the settings set in the certificate template. This decision is made by the Policy module of the certification authority.

However, if the EDITF_ATTRIBUTESUBJECTALTNAME2 flag is set, the related settings in the certificate template will be ignoresif different information is received with the certificate request.

In plain language, this means that anyone who has the right to request certificates from the certification authority ("enroll" authorization), can specify any Subject Alternative Nameswhich are then written unchecked by the certification authority into the issued certificate.

Since many applications and protocols (among others HTTPS, see RFC 2818) prefer to form the identity via the Subject Alternative Name, this circumstance makes it possible for an attacker, assume the identities of any other users - including administrators.

Depending on the certificate types offered by the certification authority, an attacker can use this to perform various unauthorized activities, for example:

Falsifying the identity of a web server (SAN type "DNS Name")
Sending signed e-mails in the name of another user (SAN "Type RFC 822 Name")
Adopt the entire Active Directory forest (SAN type "User Principal Name")

The latter case will be described in more detail in this article.

The attack

Identify Interesting Certificate Templates

To adopt the Active Directory forest, a certificate template is required that enables logon via smart card.

The following requirements must be met for this:

The environment must allow smart card logins, which should be possible in most cases.
The user must be able to request a certificate from the template (have enroll permission).
The issued certificate must contain either the Extended Key Usage for Smart Card Logon or (with a little trick) for Client Authentication.
The user needs a smart card together with a smart card reader. The smart card middleware must be installed on a domain computer. Alternatively, the Kerberos credentials can be can also be generated without a smartcard.

The following security measures can be bypassed:

The setting in the certificate template to form the identity of the enrollee from the Active Directory can be overridden by the presence of EDITF_ATTRIBUTESUBJECTALTNAME2 by the enrollee, at least for the Subject Alternative Name part.
The setting in the Certificate template not to mark the private key as exportable can be overridden by the requester.
The setting in the certificate template that a certificate request can only be checked by a certificate manager will probably still lead to a result because the change is not made at the Inspect the certificate request but only in the View Attributes/Extensions dialog in the certification authority management console (certsrv.msc). An unaware certificate manager will thus most likely release the certificate request.

Request a certificate

The attacker could also bring along a completely finished certificate request and then only send it to the certification authority with the user's identity. For reasons of simplicity and comprehensibility, the path via the existing on-board means is described here.

First, we need a certificate request as a text file. This can be generated via the certificate management console (certmgr.msc). To do this, right-click on Personal – Certificates clicked and All Tasks – Advanced Operations – Create Custom Request... selected.

You will be prompted to specify the certificate template.

In this example, the certificate template is configured to use a smart card, so the key pair is generated directly on the smart card.

If the certificate template instead requires a software-based Cryptographic Service Provider (CSP) or Key Storage Provider (KSP), then these the private key is set as exportable and the resulting certificate then be imported to a smart card.

The certificate request is now saved as a file.

In the next step, the certificate request is sent to the certification authority using the -attrib argument, a Subject Alternative Name is specified in the form of the User Principal Name (UPN) of the predefined Enterprise Administrator account.

certreq ^
-submit ^
-config "CA03.intra.adcslabor.de\ADCS Labor Issuing CA 2" ^
-attrib "SAN:upn=Administrator@intra.adcslabor.de" ^
test.req ^
test.cer

If the certificate request is configured to have a certificate manager verify the request, this is not visible in the saved certificate request, but only in the "View Attributes/Extensions" dialog in the Certificate Authority Management Console.

At first glance, the issued certificate does not seem to have any noticeable features, since in this case the subject of the certificate is filled with the identity of the enrollee, as expected.

However, if you look at the Subject Alternative Name extension, you will see that the UPN of the predefined Enterprise Administrator account is entered here.

After the certificate has been retrieved from the certification authority, it can be installed using the following command.

certreq -accept test.cer

Again, there is no indication of the deviating UPN.

Perform registration

Now the user can log on to a client with the smart card. As soon as the smart card reader and the inserted card have been recognized, a corresponding selection should be available.

In this dialog you can see the divergent identities - the Subject at the top, the Subject Alternative Name at the bottom.

As you can see, a login with the predefined Enterprise Administrator account should now take place.

A check reveals that we now have "Enterprise Administrator" permissions.

What is the trick to use certificates with Client Authentication Extended Key Usage?

Provided that the user has administrative rights on the computer he is logging on to, he can apply a local group policy that disables the restriction to the Smart Card Logon EKU for Windows logon dialog.

The setting can be found under Computer Configuration – Administrative Tools – Windows Components – Smart Card and is named "Allow Certificates with still extended key usage certificate attribute".

After that, certificates that do not include smart card logon extended key usage can also be used. Such certificate templates are much more common, and often without the requirement for a smart card.

Why do domain controllers accept certificates that do not include Smart Card Logon Extended Key Usage?

The group policy described earlier simply causes certificates that do not include Smart Card Logon Extended Key Usage to be offered for selection for logon on the client where the smart card logon is performed.

Conversely, this means that the domain controllers do not check the extended key usage of the enrolling certificate. This is indeed the case in the default setting, see the article "Domain controller does not check extended key usage on smart card login„.

The solution

The flag EDITF_ATTRIBUTESUBJECTALTNAME2 should be set on every online certification authority. Never activatet resp. be urgently deactivated. If possible, certificate requests should always be made in such a way that they already include the SAN extension. Although it is sometimes not possible to generate such a certificate request directly, there is also a safer alternative for such cases.

How can I check if the flag is set?

A list of all flags on the certification authority is obtained with the following command line command. If EDITF_ATTRIBUTESUBJECTALTNAME2 is not in brackets and not indented, the flag is active.

certutil -v -getreg Policy\Editflags

How can I disable the flag?

The flag can be removed with the following command line command:

certutil -v -setreg Policy\Editflags -EDITF_ATTRIBUTESUBJECTALTNAME2

The certification authority service must then be restarted for the changes to take effect.

How can I securely add the SAN extension to a certificate request after the fact?

The ideal way, of course, would be for the Certificate request directly including a correctly filled Subject Alternative Name. However, this is not always possible.

Colleague Vadims Podans has written an excellent guide for when a SAN extension needs to be added to a certificate request after the fact: How to add FQDN to HP iLO request.

The TameMyCerts Policy Module for the Microsoft Certificate Authority as of version 1.3 supports the automatic transfer of any DNS names or IP addresses found in the commonName of a certificate request to the Subject Alternative Name of issued certificates if they are missing.

Active Directory forest compromised by EDITF_ATTRIBUTESUBJECTALTNAME2 flag