Skip to main content
banner image
venafi logo

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

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

self-signed certificates breaking rope
August 24, 2017 | David Bisson

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.
 

What are the five worst things attackers can do in your encrypted tunnels? Read the white paper.

 

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. (This attack potential explains everyone's concern around Superfish, an advertising company whose adware came preinstalled on Lenovo computers not too long ago.)
 

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.
 

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.
 

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?
 

Learn more about machine identity protection. Explore now.
 

Related blogs

Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

See Popular Tags

You might also like

Why Encryption Should Be the Next Step in Operationalizing GDPR Compliance

Why Encryption Should Be the Next Step in Operationalizing GDPR Compliance

Russia-Yandex Encryption Spat Highlights Trust as a Competitive Business Advantage

Russia-Yandex Encryption Spat Highlights Trust as a Competitive Business Advantage

https phishing, tls certificate, phishing scam

FBI Warns Users about Phishing Campaigns that Leverage HTTPS Websites

About the author

David Bisson
David Bisson

David Bisson writes for Venafi's blog and is an expert in machine identity protection.

Read Posts by Author
get-started-overlay close-overlay cross icon
get-started-overlay close-overlay cross icon
Venafi Risk assessment Form Image

Sign up for Venafi Cloud


Venafi Cloud manages and protects certificates



* Please fill in this field Please enter valid email address
* Please fill in this field Password must be
At least 8 characters long
At least one digit
At last one lowercase letter
At least one uppercase letter
At least one special character
(@%+^!#$?:,(){}[]~`-_)
* Please fill in this field
* Please fill in this field
* Please fill in this field
*

End User License Agreement needs to be viewed and accepted



Already have an account? Login Here

×
get-started-overlay close-overlay cross icon

How can we help you?

Thank you!

Venafi will reach out to you within 24 hours. If you need an immediate answer please use our chat to get a live person.

In the meantime, please explore more of our solutions

Explore Solutions

learn more

Email Us a Question

learn more

Chat With Us

learn more
Chat