In earlier blog, I spoke with George Parsons, the inventor of wildcard certificates, about why he created them and how they may be overused. During that conversation, George mentioned that he is concerned that organizations may not be taking wildcard certificates seriously enough. He noted that many organizations may be unaware of the risks connected with hasty certificate deployment strategies as well as a couple of attack scenarios that you may not have thought about.
Here’s the final portion of my interview with George:
What will change now that Let’s Encrypt is offering free wildcard certificates?
With free wildcard certificates, the natural filtering or controlled use of wild cards based on cost just isn’t going to be there. I’m not a huge fan of DV certificates in general because it’s too easy to validate ownership of the domain. It doesn’t give us the assurances that we mere mortals need. It’s important to understand that it’s relatively easy to register a domain and order a certificate that’s DV only. I recently heard an analyst say that 80% of all malware shops use DV certificates. People go to these sites that are putting out this malware, and they think, “Well, it’s encrypted, it must be a safe vendor or website.” And certainly, the average user doesn’t know the difference between DV, EV, and OV.
Unfortunately, I think what’s going to happen with free Let’s Encrypt wildcard certificates is that more and more people will use wildcard certificates for their entire domain (*.website.com) without thinking about how easily these can be abused.
Are organizations thinking enough about the security of wildcard certificates?
No, not really. For example, if they are using an internal PKI vs. an external CA, they may not always worry about using best practices for certificates. They often think that, because they have control over the access to these systems, no malicious actors are ever going to get to them. This is just naive thinking, but often these same companies leave the key pairs for wildcard certificates laying around in .p12 containers living on file shares. And they rely upon the permissions to those file shares to restrict access to them. You know how easy it is to get access to file shares in certain companies? As long as you’re a member of a group, you have access to the file share and you can download anything.
What happens when attackers have access to a wildcard certificate?
If you’re a bad actor and you get access to a file share through escalated privileges of some sort, you are then free to download an .p12 file (these contain a private key and its corresponding wildcard certificate) and exfiltrate it. Then you can do a brute-force attack on that .p12 using a password cracker, extract the key pairs, and you then have the ability to do man-in-the-middle attacks within that organization. At that point, you can impersonate any server inside the organization because you now control the key and the wildcard certificate.
What kind of sloppy practices have you seen with wildcard certificates?
I worked with one company that left their keys and certificates in .p12 files on a server with no passwords. Their reasoning was that their orchestration software couldn’t do lights-out functions with the password injection so they had to do it without passwords. It gets worse; they weren’t all that worried about doing so, because they felt that they had strong permissions on the file server where they were storing the .p12 file for the wildcard, so they thought they’d be okay.
You name it, I’ve seen it. I’ve seen administrators leaving .p12 files lying around, emailing them to colleagues or partners, or leaving them on FTP servers. I’ve also seen them dropped inside of orchestration software.
What are the potential risks of treating wildcard certificates too lightly?
Emailing a .p12 file containing wildcard assets immediately exposes it to attackers who may be sniffing email traffic that’s not encrypted. Another risk is that organizations may leave a .p12 file lying around on file shares, as I mentioned before. If the network has been infiltrated, those .p12s can be exfiltrated. Using brute force to factor the password, attackers can open up the .p12 and export the key pairs. Once they have the private key and are inside the website they can potentially impersonate an internal trusted server and capture sensitive data. Or, if it’s an external server, they can capture customer or user information in a phishing attack.
Why do you have to be careful about where you store wildcard certificates?
Let’s say administrators get sloppy and leave .p12 files for wildcards lying around. If one of those is exfiltrated then there’s all sorts of exposure to targeted phishing attacks. Here’s another scenario: 10 admins have left the company over the past 5 years. Every one of those 10 admins have left SSH keys on a variety of different servers. This means the SSH privileged access into those servers is still enabled. Attackers that gain access to these SSH keys can pivot over to the file server where the .p12 files are , and then exfiltrate them. So much for the folks who say they are not exposed because they store .p12 files on servers that have strict permissions. The reality is that—even if they never (officially) allow escalation privileges or anything like that—they can still be at risk.
As an executive at Venafi, George feels obligated to mention that we offer a different kind of easy button. And by pushing it, you’ll actually become more secure. Venafi automates the entire key and certificate lifecycle. So, whether you choose to use wildcard or SAN certificates, we make it easy for you to automate the deployment of keys and certificates that follow your approved policies and workflows. This means you won’t have the additional overhead of manually provisioning certificates to their respective endpoints.