(No Ratings Yet)

Loading...

• Facebook
• Twitter
• LinkedIn
• Mail

August 21, 2017 Comments closed

Wildcard SSL Certificates and Phishing: A Match Made in Heaven

in Everything Encryption

How Wildcard Certificates “Hide The Phish”

Ever since free and automated SSL certificates have been popularized – primarily by Let’s Encrypt, but also by Cloudflare – there has been a massive surge in the use of certificates on phishing sites. It has remained one of the most popular topics of debate within the industry – a hot button issue with firmly opposed sides.

Next year, Let’s Encrypt will start supporting Wildcard certificates. This will create a new angle in the phishing debate because of Wildcard certificates’ unique ability to mask their intended use.

It is likely that criminals and phishers will use Wildcard certificates to their advantage to hide hostnames and make them more versatile. Wildcard certificates may even replace single-domain certificates as the tool of choice.

How Wildcards Can Help Phishers

With traditional SSL certificates, the entire hostname is listed within the certificate. The client checks those hostnames to make sure it only uses the certificate when visiting those sites – and treats it as invalid if it was used with any other hostname.

With single-domain certificates, only one hostname is covered: “www.example.com.” Multi-domain certificates can allow up to hundreds of hostnames. Each is discretely listed – www.example.com, mail.example.com, cpanel.example.com, etc.

Wildcards work differently. With a Wildcard certificate, the left-most label of the domain name is replaced with an asterisk. This is the literal “wildcard” character and it tells clients that the certificate is valid for every possible name at that label. With a Wildcard certificate the hostname contained in the certificate would be “*.example.com,” and it would be valid for all the names we listed in our previous example.

If you wanted to phish Paypal, Apple, or Barclays Bank with a single-domain or multi-domain certificate you would receive a certificate that contained names like this:

paypal.secure-account.com
Apple-id.support-com.online
bankofamerica.verify-account.com

If you wanted to create a phishing site for those same companies with a Wildcard certificate, it would look like this:

*.support-com.com

When a client receives that certificate it would treat it as valid for “paypal.support-com.com,” or “apple-id.support-com.com,” or any other combination of letters and numbers. Depending on how generic your root domain is, you could use that one certificate for all of those phishing scams.

This property allows Wildcard certificates to hide what we call the “phishy bit,” the part of the domain name which most evidently identifies the phishing target.

There are restrictions on Wildcards that limit the scenarios they can be used in. There can only be one “*” and it must be in the left-most position. So, “www.*.secure.com” is not allowed. It also cannot be used directly after the TLD. So “*.com” is not allowed.

This means the “phishy bit” must be in the left-most position as well. The following hostnames, which resemble real-world phishing sites, would not be able to benefit from a Wildcard certificate:

paypal-com-update.net
www.paypal-limited.us.helpsecured.cf

Using Wildcard certificates to hide a phishing site has been possible since their invention. You can buy a wildcard certificate from any CA, and they have little to no way to stop you from using it for any purpose you like. The methods they would normally use to block issuance of a certificate for a phishing site requires knowing the hostname.

Phishers have been using Wildcard certificates for years. However, because phishing certificates typically cost more than five times what a single-domain certificate does, they are not economically feasible for most phishing. The vast majority of phishing sites with SSL certificates use single-domain certificates because they are cheap or free.

Why It Matters

Another recent development in the SSL world is Certificate Transparency, or CT.

CT is a system that publicly records (“logs”) SSL certificates in centralized lists. This allows oversight of CAs and detection of certificates that are issued improperly or without authorization. We can get almost real-time updates on the certificates that CAs are issuing by monitoring these logs, which can be used to spot a variety of problems including CA compromises – like what happened to DigiNotar in 2011.

Another benefit of these logs is that they can be used as a detection system for finding new phishing sites. By regularly querying the logs for terms likely to be used for phishing, such as “paypal,” you can quickly find the hostnames for new phishing sites and block or flag them.

Logs can be updated less than 30 minutes after a certificate is issued, making it one of the fastest ways of discovering the hostnames of potentially malicious sites. We know there are at least a few organizations using logs for this purpose.

By leveraging logs as phishing detection systems, phishers who want to use an SSL certificate to enhance the legitimate appearance are actually making it easier to get caught.

However, this method only works if the entire hostname is included in the certificate, which is not the case with Wildcard certificates. Instead of searching the log and seeing “paypal.online-account.us,” we would only see “*.online-account.us.”

If a large proportion of phishing sites begin using Wildcard certificates instead of single-domain or multi-domain certificate it will make CT logs an ineffective detection systems.

Outside of proactively using the logs as a phishing detection system, the ability to search for these certificates is also useful for research. Earlier this year we quantified the volume of “paypal” phishing sites using SSL certificates – something that would have been much more difficult if Wildcard certificates were widely used by phishers.

Why It’s Okay.

Even though Wildcard certificates can make life easier for phishers and harder for researchers, they serve an important purpose.

There are use cases that single-domain or multi-domain certificates cannot easily accommodate. For example, if you wanted to assign a unique sub-domain to each user who signs up for your service: cpanel-01.example.com, cpanel-02.example, etc.

Having to constantly issue new certificates for these hostnames is an engineering challenge many sites cannot implement. Sometimes software has limits on how many certificates it can serve, which could create a limitation if users were stuck with multi-domain certificate where they had to discretely list all hostnames.

When Certificate Transparency becomes mandatory for all CAs (in mid-2018) some users will want to ‘hide’ their sub-domains with a Wildcard, out of concern that having their hostnames publicly listed will be a vulnerability or identify services they would rather remain unknown.

Researcher Hanno Bock demonstrated this property by searching CT logs to find and compromise unauthenticated web apps. While relying on a ‘black-box’ model of security to hide your domains is not the proper way to solve this problem, it does demonstrate another example of Wildcards being useful.

So “killing” Wildcard certificates is simply not a realistic solution. Instead, we simply need to be aware of and adapt to this new behavior, which I believe will become widespread early next year after Let’s Encrypt begins offering them for free. This will be a major benefit for many sites and users who need free certificates – which will greatly outweigh their abusing for phishing.

• #phishing
• #SSL Certificates
• #SSL/TLS
• #Wildcard SSL