-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Policy module allows honkeypot certificates without SAN to be successfully issued #1
Comments
Thanks for testing the tool and providing your input! Regarding 1: 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: |
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.
(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:
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? |
@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. |
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. 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. |
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. |
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.
The text was updated successfully, but these errors were encountered: