Policy module allows honkeypot certificates without SAN to be successfully issued

[gnugnug]

I'm unsure if this is an issue or a discussion item, but since the discussions feature is disabled for this repository, I'm going to post it here.

The policy file allows certificates without a Subject Alternative name extension but with an arbitrary commonName in the subject to be successfully issued. The documentation explains "This prevents malicious use while still allowing users to create certificates for themselves", however to me this looks like a needlessly dangerous configuration.

1. Why should users be able to request certificates from a honeypot? Those certificates serve no purpose and just trigger false positive alerts.
2. If the attacker is able to modify the altSecurityIdentities attribute of an account he can create an explicit mapping between the issued certificate and that account.

[balthasar-m]

Thanks for testing the tool and providing your input!

Regarding 1:
It allows to differentiate between "suspicious" behaviour (account using the template) and clearly "malicious" behaviour (specifying a SAN).

I agree that in environments where the suspicious case rarely happens, it makes sense to prevent issuance completely and raise a critical alert on someone trying to use the template.

For environments where there are false positives for the suspicious use (too noisy to trigger a critical alert), I think it makes sense to have the differentiation. Otherwise an attacker could just try to get a certificate for an account they control (not specifying a SAN) to make sure everything works before they perform real exploitation.

I think this could be a future parameter, so that you can decide on roll-out which option you want.

Regarding 2:
Can you explain the abuse vector you see here in a bit more detail?

[Sleepw4lker]

I hope it is OK to somewhat capture this discussion.

First of all, I think there maybe still is some confusion about which attacks are detected.

• ESC1 abuses a certificate template that is configured with the "Enrollee supplies subject" setting enabled (also called an "offline" template because the identity is provided by the requestor, as opposed to an "online" certificate template where the certificate identity is built from AD based on the enrollee's logon information). The adversary would have to submit a certificate request containing a "malicious" Subject Alternative Name certificate extension.
• ESC6 abuses a certification authority that has the EDITF_ATTRIBUTESUBJECTALTNAME2 flag globally enabled. An adversary would submit an arbitrary certificate request, regardless if is is an "offline" or an "online" one. Whilst submitting, he would specify an additional request attribute (which essentially is a key-value kair) with a key named "san" and a value of "upn=theaccountname". The CA would the construct an according Subject Alternative Name extension and put that into the issued certificate.

(the difference between online and offline certificate templates is described in the TameMyCerts documentation btw.)

To mitigate ESC1 with the TameMyCerts policy module, it'd be sufficient to configure the policy file to literally deny everything (if intended so). This should be possible with just an empty configuration file as the default logic is to deny everything that is not defined - thus everything will be denied if nothing is defined.

(btw. I would advise to alert on any request being denied by TameMyCerts as this usually should not occur in a production environment)

For detection of ESC6, I was thinking of implementing additional logging into the policy module:

Currently, it denies any certificate request (only) if both of the following conditions are given:

1. The CA has the EDITF_ATTRIBUTESUBJECTALTNAME2 flag set and
2. The request attribute table for a certificate request contains a "san" key

IIRC, the EDITF_ATTRIBUTESUBJECTALTNAME2 flag cannot (at least with default permissions) queried remotely by an adversary. So IMO chances are the adversary might try his luck with a hit or miss approach. So we could log simply based on the second condition, even if the flag is not enabled on the CA. Would such an event occur, chances are we spotted an adversary trying to abuse the flag, but no malicious certificate would be issued.

Any opinions on this?

[balthasar-m]

@Sleepw4lker Thanks for providing the clarification.

Yes, we focused on ESC1 so far because it can be easily "discovered" by attackers (as opposed to ESC6 where they just have to try).

Still, I think monitoring for ESC6 abuse attempts does not hurt and it's cool if TameMyCerts would have such logs. We could include an additional SIGMA rule for an alert once the logs exist.

If there is a honeypot, the attacker would likely try ESC1 abuse before attempting ESC6 into the dark. Therefore I think ESC6 abuse attempt monitoring would make a bigger difference for setups where TameMyCerts is used in normal production without honeypots.

[gnugnug]

Thanks for the quick response, however I wasn't refering to ESC6 but to using explicit certificate mappings via the altSecurityIdentities. Explicitly mapped certificates do not need to include a SAN extension to be used for authentication.
That means an attacker who is able to modify the altSecurityIdentities attribute of another account is able to use the Esc1Honeypot template to issue certificates with EKU Client Authentication without manager approval from an offline template on a CA in the NtAuth store and use this certificate to logon as the said account. In my opinion a honeypot should never allow attackers to escalate their privileges, not even if it fires an alert while doing so and not even under uncommon circumstances.

However maybe there is a reason for allowing certificates without a SAN to be successfully issued by this honeypot. If so I'd interested into learning about it.
From my understanding an attacker cannot tell whether the template would deny every request or whether it allows requests under certain conditions (except by trying to actually issue a certificate, at which point he triggers the alert). So it seems like a needless loophole to me to allow less dangerous certificates to be issued.

[balthasar-m]

Hi, I tried to elaborate on that in my first answer in this thread. Agree that in environments where any attempted use of the template is low-noise enough for a critical alert, it makes sense.

Regarding risk for abuse: do I understand it correctly that your abuse scenario with altSecurityIdentities works with every certificate template where users can get a certificate for themselves?

Because such a template exists in almost all environments I have seen so far. I.e. there would be no additional risk through the honeypot.

Still, agree that it's nice to create the option to prevent all issuance so people can decide for themselves depending on their environment.