Certificate Transparency Part 3— The dark side
This post is third in a series of technical posts about Certificate Transparency(CT). Part1 and Part2 here.
We introduced the concepts and gave an overview of CT in an earlier post, if you are new to this we suggest that you read the first part of the series.
In the second post we discussed the security use cases and advantages of CT with its focus on tackling the rogue certificate problem.
If you are reading the part 3 (this post) first, please note that we will be mentioning a bunch of technical words like SSL/TLS, PKI etc in this article. We recommend that you start by reading the SANS/GIAC The Idiot’s Guide to Public Key Infrastructure
In this post, we will look at the dark side of Certificate Transparency(CT). We’ll look at how attackers can leverage CT logs to conduct reconnaissance and also attack an organisation’s infrastructure.
The side effect of Certificate Transparency
CT logs by design contain all the certificates issued by a participating CA for any given domain. These logs are available publicly and anyone can look through these logs.
An SSL/TLS certificate usually contains domain names, sub-domain names and email addresses. This makes them a treasure trove of information for attackers.
By looking through the CT logs an attacker can gather a lot of information about an organisation’s infrastructure such as internal domains, email addresses.
The scary part is that all of this information gathering happens in a completely passive manner.
Let’s look at how attackers look through Certificate Transparency logs
There are various search engines that collect the CT logs. We can easily search through them just like how we can Google anything.
At Appsecco, we refer to the following search engines when we are trying to conduct OSINT on targets passively whenever we start an Application Security Assessment.
- https://crt.sh/
- https://censys.io/
- https://developers.facebook.com/tools/ct/
- https://www.google.com/transparencyreport/https/ct/
A quick search using crt.sh for an organisation’s primary domain revealed some interesting sub-domains:
We created few scripts to search through known CT logs to extract sub-domains for a given domain name. The scripts yielded interesting results when we ran them against few organisation’s domains, a sample result can be seen below. We demonstrated these scripts as part of our conference talk at Bugcrowd LevelUp . You can find the scripts in our github repository —
From an attacker/penetration tester point of view, each sub-domain enumerated increases the potential attack surface.
Attacking Content Management Systems using Certificate Transparency
When setting up popular Content Management Systems(CMSs) like Wordpress, Joomla and others, there is a window of time where the installer has no form of authentication. These days, a lot of web hosting providers support HTTPS by default so the domain name will end up on a CT log, depending on the CA this might happen in near real time or with a few hours of delay. If an attacker can search through CT Logs and find such a web application without authentication then he/she can take over the server.
This attack has been demonstrated by Hanno Böck at Defcon 25. He claimed to have found 5,000 WordPress installations using CT logs over a period of 3 months that he could have potentially taken over.
HD Moore also discussed this technique in his talk at BSidesLV 2017.
How can you secure your domains now?
- You can avoid having SSL/TLS support so that your internal hosts won’t get listed in the CT logs. This approach is definitely not recommended. It is a bad idea to not have SSL/TLS if you are dealing with sensitive information.
- By using wildcard certificates you can have a single certificate that is valid for all your sub-domains, in turn not revealing the sub-domain names in CT logs. Having one wildcard certificate to protect multiple domains could prove to be a single point of failure and thus not recommended. RFC 6125 specifically advices not to use wildcard certificates on security grounds.
- Accept the fact that all your SSL/TLS protected domains/sub-domains will get listed in a public CT log file. Secure your servers and application end points better.
Anything that is not meant to be public must be behind authentication.
- You can deploy your own Public Key Infrastructure(PKI) in your organization. This will avoid your internal hosts from getting listed in a CT log maintained by a public CA. Running your own PKI comes with a lot of overhead though
- CloudFlare has an interesting project, CFSSL, to build an internal CA infrastructure. They also have a project, certmgr, to automate certificate management using a CFSSL
- Some CAs offer an option for their customers to opt out of CT logs. Opting out of CT logs might sound like a safe idea but you’ll miss out on all the security benefits that CT provides
- There is consideration to redact sub-domain information from CT logs. If your CA supports name redaction then you have a choice to hide your sub-domain information in a CT log. Although name redaction is better than opting out of CT, it would still make it hard for you to keep track of fraudulent certificates. Redacted domain names will not be recognized as conforming to the CT Policy by Chrome
Certificate Transparency — Security checklist
We created a simple checklist for domain owners to understand CT work-flow to find rouge certificates and publicly exposed domains. This checklist is created using a Github gist, feel free to fork, customise the checklist — https://gist.github.com/yamakira/f9562dbc9e3eef5fe1e8e3f0be5ea77b
Closing remarks
Although CT is a fantastic idea, it comes with some significant privacy and security risks but considering what CT offers in terms of tackling the age old problem of rogue certificates, we think it’s a fair trade-off to adopt CT as a security mechanism.
References
Thank you for reading this article. If you enjoyed it please let us know by clicking that little clap icon below.
At Appsecco we provide advice, testing, training and insight around software and website security, especially anything that’s online, and its associated hosting infrastructure — Websites, e-commerce sites, online platforms, mobile technology, web-based services etc.
If something is accessible from the internet or a person’s computer we can help make sure it is safe and secure.
