Using Certificate Transparency as an Attack / Defense Tool

Published: 2018-09-18
Last Updated: 2018-09-18 12:00:47 UTC
by Rob VandenBrink (Version: 1)
2 comment(s)

Certificate Transparency is a program that we've all heard about, but might not have had direct contact with.  We do hear about it from time to time, for instance when Google (or someone else) busts a CA for generating certificates that should not exist  (which is what eventually led to the Symantec CA implosion event ..).  I kinda knew about mostly from mentions in the ISC Stormcast.

Anyway, the Cert Transparency program has Certifficate Authorities keeping a transparent log of EV certificates since Jan 1, 2015, and logs for DV and OV certificates as of May 2, 2018 (more here: https://www.certificate-transparency.org/ ).  This means that there are central, queriable repo's for all SSL certificates.  As soon as I hear "central database" and "API", I tend to ask "how can I use that for other purposes" - for instance, how I use that in Penetration Tests?

One of the truisms of of pentests is that you can only test/attack hosts or services that you know are there - that's what the recon phase of your pentest is all about.  Certificate Transparency logs gives you a whole new method of assembling a list of targets during recon.

Let's take a look at a few of the vendor interfaces to the data.  Starting with Comodo's CT interface - making a query https://crt.sh/?q=sans.org gets us a nice list of certs:

Though that API approach is very simple to use, I found this GUI interface a bit clumsy to navigate to the info you really want.  The Entrust interface at https://www.entrust.com/ct-search/ is a bit easier to navigate, but doesn't have that easy ability to translate a browser based query to a curl or other script based approach.

SSL mate allows you to monitor for any new certificates in your list of domains - which is handy if you've maybe got a marketing group that's active in AWS but isn't telling IT everything that's going on over there :-)

Whatever interface you use, clicking on anything on a results page will get you more and more (and more) detail. What can we use in these listings?

First, start with the domain that you know about.  Query that, and you'll get the list of all certs issued to that domain.  How can you use that?  Grab the CN's (Common Name) for the certificates, and you'll have a starter host list.  Add the SAN fields (Subject Alternative Names) and you'll generally have a longer list of hosts.

What do do next?  Look at the "not after" list for expired certificates.  Why those you ask?  Well, if you have an expired certificate for a host, and a valid cert isn't in the list, I'll always start with these.  If the host still exists, this is a great indication that it's not well maintained - maybe it's a forgotten lab or dev machine for instance, or part of a marketing program that has run its course.  In either case, it's likely not well patched and is often easy pickings for the penetration tester.  Look for any outliers - if all certts were issued by one CA, look for any certs that were issued by a different CA for instance.  That's another indicator of "credit card IT" practices (often by non-IT or non-infosec folks).

So we have a host list, and a list of hosts that are either no longer active or are perhaps easily exploitable.  Are we done yet?  Nope, let's pivot through this information to get MOAR information - look a the "O" (Organization) field.  This should be the same for all the certificates in the domain.  Query using the contents of that field, and you'll get all the **other** domains that the organization has certificates for.  Use the exact, full contents of the field, then repeat by removing any  trailing periods, then try removing any "Corp" or "Inc" words.  Now repeat the entire process for any new domains that you've found, you'll now have anywhere from 1-4-5-or more domains worth of hosts and possible easy target hosts.  If you're lucky, some of these will have been stood up by interns, coop students or other "good with computers" folks who didn't neccessarily follow IT's procedures in building or maintaining hosts.

Where else can you find a decent interface to a certificate transparency feed?  So far, I've been using:
https://sslmate.com/certspotter/howitworks
Nice API, with lots of examples
https://crt.sh
This one is very complete.  I can't seem to find "O" records, but that's easily obtainable from any of the certificates once you have some hostnames.
https://www.entrust.com/ct-search/
This gives you pretty much everything, including the ability to download the certificates themselves, export to excel or csv.
https://transparencyreport.google.com/https/certificates
Of course there's a Google interface to search certificates.  And of course it's extremely complete - if there's info to find, it'll be easy to find in this one!
https://developers.facebook.com/tools/ct/search/
Yup, there's a Facebook iterface too!  Authentication is required so I don't use it so much.  It does allow you to pull the PEM for each certificate if you want to do some offline information mining (using OpenSSL or CertUtil or even PowerShell for instance).

Every CA has their own interface.  It's all the same data (or it's supposed to be anyway), so poke around and see which one suits your style of searching best.

With all of these tools at your disposal and some good red-team approaches, what about the blue team?  the SSLmate interface allows you to monitor for new certificates being issued to your domains - - perhaps certificates requested by folks in your organization that you don't want purchasing certificates.  Or perhaps attackers that have social engineered their way into purchasing a certificate.

With some creative coding, you can also use certificate transparency to monitor for typosquatting or punycode attacks against your domains - track for "0 for o", "1 for l", but then also add some of the other unicode "look-a-like" alternatives for o, a, i etc.  Also add a few "typo" alternatives - "gooogle" for "google", or try a version of your domain name that uses an adjacent key - "amazom" for "amazon" for instance.

The more I type, the more that this sounds like a project or two - Look for code in the next few weeks.  Or if you know of folks who have gone further down this path of coding to use Cert Transparency for either attack or defense, please share in our comment form!  Or if I've missed a really nice CA interface, API or an attack/defense method using this data, please also share!

===============
Rob VandenBrink
Compugen

2 comment(s)

Comments

Hi,

Effectively, some projects already answer to your questions about the usage of the CT technology with a blueteam mindset.

With a colleague of the security team of the French Public Healthcare system, we have developped CertStreamMonitor : https://github.com/AssuranceMaladieSec/CertStreamMonitor/

Pitch:
- the daemon part of the tool monitors the CT flow of publicly signed ceertificates, looking for specific strings inside CN and Subject Alternatines Names and if triggered, stores the certificate in a DB.
- Then the alerting part notifies you (through json file generation) when a hostname stored in DB appears to be online and so, you can engage the takedown of the malicious web server.

Good use and happy to see you back for issues/PR/comments :)
Christophe
The certificate transparency module of recon-ng is a great way to get subdomains for a domain and the streaming phish project at https://github.com/wesleyraptor/streamingphish uses this information to identify phishing sites as they're set up. Certificate transparency is one of the best security tools around.

I'm blue team for a large organization and it's one of my favorite tools - it's sometimes the only way to tell if marketing has set up a remotely hosted website.

Diary Archives