Self-Signed Certificates: Cybercriminals Are Turning This Strength into a Vulnerability

The risk of self-signed certificates 

When compared with certificates signed by CAs, self-signed certificates are often viewed as less trustworthy because they have not been vetted through official channels. With signed certificates, a trusted Certificate Authority must verify the certificate applicant’s domain ownership and identity information, whereas anyone can generate a self-signed certificate without having to submit through this means of authentication.
 

While concerns over trustworthiness may ring true for self-signed certificates used on a publicly accessible service, it may not be the case for internal usage. Self-signed certificates can be a valid alternative for securing internal communications.
 

If properly secured, self-signed certificates can actually reduce the risk profile of using CA-issued certificates for internal communications. However, if you do not have the ability to continuously monitor and protect self-signed certificates, cyber-criminals can conduct man-in-the-middle (MitM) attacks to impersonate banking, e-commerce, and social media websites. 
 

A number of attacks have successfully exploited self-signed certificates. For example, one variant of the Dyre banking Trojan uses a self-signed certificate to communicate with its command-and-control (C&C) server over ports 443 and 4443. This certificate makes the Dyre variant’s exfiltration traffic look like regular browser traffic, thereby rendering the malware more difficult to detect and analyze.
 

Sponsorships Available

Sponsorships Available

Sponsorships Available

Dyre isn’t the only malware to use self-signed certificates. Another highly sophisticated banking Trojan known as Shifu replicates Dyre’s secure communications model with its own C&C infrastructure. By contrast, a Mac-based threat called Flashback uses self-signed certificates to trick users into installing the Trojan onto their machines.
 

Once compromised, self-signed certificates can pose a number of challenges. If an attacker has already gained access to a system, the attacker can spoof the identity of the victim. Sure, CAs can revoke a certificate when they discover it has been compromised, but organizations cannot revoke a self-signed certificate. Instead they must replace or rotate the certificate. This inability to rapidly revoke a compromised private key associated with a self-signed certificate may open the door to malicious attackers.

Organizations massively underestimate active certificates

In addition, most organizations underestimate the number of active certificates in use on their systems. For example, one major retail organization estimated it had 5,000 active certificates, but in actuality, it had 20,000! Even more alarming, more than 5,000 certificates had no owners, and no one knew what they did, what they allowed, and who was responsible for them. This lack of insight can easily occur when organizations use self-signed certificates.
 

You should also be aware of how in-house developers are using self-signed certificates. Rather than purchasing CA certificates, these individuals tend to download an open source implementation of SSL and TLS called OpenSSL. They then create the certificates they need in order to develop and test software. If used in production versions of applications, these self-signed certificates can make you vulnerable to unforeseen attacks.
 

Remember the Heartbleed vulnerability from back in 2014? That flaw showed exactly how organizations blindly trust keys and certificates and how quickly and easily cyber-criminals can exploit a trust-related vulnerability. Astoundingly, hundreds of thousands of services were still vulnerable to Heartbleed three years after the bug’s disclosure.
 

Couple these self-signed certificate vulnerabilities with the operational challenges most organizations face with expiring and misconfigured certificates, and you can see why attackers are quickly turning this strength into a vulnerability. To quickly counter these attacks, you must be able to swiftly replace compromised self-signed certificates on internal systems and replace the self-signed certificates used on production systems with certificates issued by an established intermediate CA.
 

You also need a mechanism to detect and monitor self-signed certificates, identify rogue certificates in use, and quickly remediate. For added protection, you should establish a baseline and, when appropriate, automatically acquire new certificates to replace those that do not comply with the policies they have established.
 

All certificates, especially self-signed certificates, need to be secured and protected. According to the Ponemon Institute, 54% of organizations do not know exactly how many certificates are in use within their infrastructures, where they are located, or how they are used—let alone how many of these unknown assets are self-signed or CA-signed. They must not only know which systems use self-signed certificates but also replace these certificates on a regular basis.
 

Do you have clear visibility into your self-signed certificate inventory, so you can respond much more quickly when certificates are compromised and reduce your risk of attack?

(This post has been updated. It was originally published on January 9, 2019.) 

Related posts

• Self-signed Certificates Open a Can of Worms for DevOps Security Teams
• Code Signing Certificates: A Dark Web Best Seller
• Crypto Mining, Code Signing Compromise: Are Your Certificates Safe?

Traditionally, organizations have used certificates signed by Certificate Authorities (CAs) to secure both external and internal communications. But internal certificates can be more difficult to find and replace, making it more challenging for organizations to manage internal certificates in the event of a CA error, security breach, or attack on a CA. As a result, organizations are looking for ways to reduce their threat surface. One strategy is to use self-signed certificates to secure communications between internal systems as well as to authenticate devices and users to the internal network.
 

“>