The Dark Side of Certificate Transparency
SANS ISC recently posted an article on The Dark Side of Certificate Transparency.
Certificate transparency means that participating certificate authorities will publish all certificates that they issue in a log. This information is public, meaning that you can search it at will.
The article already touches one of the side effects of having this information publicly available. By publishing the information organizations can disclose hostnames they’d rather not be known on the internet.
Passive reconnaissance
There are many ways to conduct passive reconnaissance. As a reminder, passive reconnaissance means that you collect information on a target without actually sending one bit to the target infrastructure.
Penetration testers can use this information to sketch a picture of the network layout or provided services without giving away their intentions.
Typically hosts protected with an SSL certificate might contain something “useful”. Adding a certificate often means that an organization is aware that the host in question is valuable, or at least that it requires some extra attention from their IT department. Of course, there’s always a chance an organization uses these hosts as a decoy.
Note that SSL transparency isn’t a bad thing. It’s similar to having host names registered in the DNS, this is how things work. The information that is in the SSL certificates can be put to use for open source intelligence or passive reconnaissance. Of course, security by obscurity doesn’t work well but you don’t have to make it to easy for attackers to create a footprint of your organization.
The post at ISC got me started on building a Python script to collect the information that is available at Censys on certificates. My main goal was to collect some statistics on what certificates (and host information) was available. But at the same time you can use the similar approach to jump start a penetration test.
Collect SSL information from Censys
I wrote a Python script that collects the SSL transparency information that is available at Censys. The script fetches the information for your query and then puts everything in a sqlite database.
Get the code from cudeso/censys-certif-crawl
You will need to get a Censys API key and put that into the configuration file. The database scheme is straightforward and self-explanatory.
SSL Certificate Transparency Statistics
I ran the query on Censys searching for “.be” data. I stopped the query before it finished because I had retrieved a dataset that was large enough to get some conclusions. Note that although you might expect to see only certificates related to the “.be” space, this dataset also contained other certificates. This was due to the fact the the query also returned results for the certificate authority and not only for .be hostnames.
Number of certificates
The script stored 147900 items for issuer_dn and subject_dn. This resulted in 286058 different DNS names discovered in dns_names. These numbers indicate that 147900 certificates were retrieved, matching up for 286058 alternative DNS names.
For info the issuer specifies the entity that issued the certificate whereas the subject specifies the owner of the certificate, the one who holds the private key.
Top certificate issuer
The top certificate issuer was GlobalSign.
Top organization in certificate issuer
In the database scheme I split the data field by the different fields that were available. This allowed me to retrieve the O, C and CN field. Sorting by O (Organization) field this returned Global sign as the top entry. Some certificates did not had a O field defined.
Top subject certificate information
Next to the certificate issuer the dataset also contained the subject_dn. The subject field in the certificate in general lists the owner of the certificate.
Top organization in certificate subject
Similar to the issuer data, I can also split the subject data per field. When organized per O field found in the subject_dn entry we get this data.
The majority (114981 out of 147900 or 78%) of the certificates did not have an O field set.
The overview also shows that two motor companies, Ford and BMW, issued a lot of certificates with a subject_dn belonging to their organization.
Alternative DNS hostnames
Another statistics that could be draw from the subject_dn field is the number of alternative DNS names that were provided in the certificate. Below is an overview of the sum of how many alternate DNS names were included per certificate. To clarify, this is the query used to generate the statistics
select sum(dns_names_count) as qt, subject_cn from subject_dn group by subject_cn order by qt asc;
Wildcard statistics
Out of 286058 hostnames found there were 31644 that included a wildcard (for example *.myhost.mydomain.com).
Analyzing alternative DNS names in certificates
I started this post with describing how you could use the hostname information from the published certificates. What are the hosts you’d typically be looking for?
These are some of the strings I queried for (notice the dots . , I used this to focus on the more interesting stuff ) :
This set of hosts already provide a good starting point to map the interesting hosts of your potential target when doing a penetration test.
But there’s more information that can be found than only the hostnames. The list above already shows that some of these hostnames might refer to internal hosts. Some certificate data also contained the internal IP addresses of hosts. The certificate information shows that the certificate applies for an external (DNS) address and for an internal (IP) address. This can become very useful in a second stage, after gaining access to the network. Below is an example (hash and domainname edited) of two such certificates.
c274c18a38dc548349148...|remote.___.be c274c18a38dc548349148...|autodiscover.___.be c274c18a38dc548349148...|mail.___.be c274c18a38dc548349148...|owa.___.be c274c18a38dc548349148...|10.68.1.2 c274c18a38dc548349148...|10.68.1.254 c274c18a38dc548349148...|FW1.___.local c274c18a38dc548349148...|SRV1.___.local 5aba235ae894907c1f27d...|remote.___.be 5aba235ae894907c1f27d...|srv1 5aba235ae894907c1f27d...|srv1.___.local 5aba235ae894907c1f27d...|192.168.11.2
Conclusion
Certificate transparency is a good initiative that can make it possible to detect SSL certificates that have been mistakenly issued by a certificate authority or have been maliciously acquired. It also makes it possible to identify certificate authorities that have gone rogue and are maliciously issuing certificates.
You just need to be aware of it existence and the information that it contains. Publicly available information can be used for good but, but when used without caution, can also have unwanted side effects.
