Editors Note: This blog post was written a few months ago. Since the extraordinary number of sites exposed by this flaw, Cygenta tried to contact as many of the companies as possible. Given the length of time that has now passed, we believe that companies have had enough time to respond or fix this issue (surprisingly, many did not accept it as a problem).

Since the change by Google to mark those sites that still serve data over the normal HTTP method as insecure, there has been an amazing amount of traffic on social media about how everyone should secure everything with a certificate. I agree that it is no longer a technical issue but an issue of perception by the public, everyone should encrypt everything end of discussion.

Well, sort of. I often go in to clients and notice that they try hard to do security correctly but can actually end up causing unintended insecurity because they don't have experience and training in this area (afterall, they are generally not a security firm).

So, now we have a billion people forced to install certificates onto their company website and do it in the cheapest and easiest way possible. What could go wrong?

The important thing to remember here is that people are just trying their best, but how does installing a certificate cause unintended insecurity? Let's take a look at a certificate:

Screen-Shot-2018-11-10-at-12.14.48-1

This is how a certificate should look. Plain and boring, to be honest.

Now, let's look at a poorly configured certificate, one that someone has tried their best to do as quickly as possible:

Screen-Shot-2018-11-10-at-12.20.12

Whoa there, wait, let's look at this properly. They have taken all the urls they own and bunched them under one certificate rather than multiple certificates. This results in a whole heap of urls that probably shouldn't be public, being listed here on the main website.

I am not saying that the issue around Subject Alternative Names is a new one, but the sheer scale of this now is a cause for concern.

So this got me thinking, what actually is the scale of this? The best way to find out is to write a tool to go over the internet and scrape out the SAN's (Subject Alternative Names) from certificates it finds and dump it into an easily searchable database.

We decided that scraping the entire internet was a little over the top for the purpose of examples for this blog post, so we cut it down to just around 1 million websites (insert dr evil gif here).

Here are the results:
More than 8 Million subdomains were revealed from 1 million initial sites.

Granted, a fair few of those are not worth our time. However, let's look at some other fairly well known urls that might be worth investigating:

sqlite> select count (*) from hosts where subdomain like "%cpanel%";
36063

Yikes! 36,000 cpanels, all directly connected to the internet and given away from the certificate of the main site.

What else could possibly be found? Well the list is almost endless. We have seen pre-production servers, administrative sites, UAT, beta and many other very interesting things so far.