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 landscape. 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. The benefits of this strategy, however, do not outweigh the risks. In fact, the aspects of this strategy that appear advantageous can be exploited by bad actors and turned into a gaping vulnerability.
What Is a Self-Signed Certificate?
A self-signed certificate is a digital certificate signed by the web owner itself, rather than a publicly trusted Certificate Authority. It’s a common workaround used by many companies to cut out third parties and save money, but the financial consequences of neglecting sufficient security can be devastating.
Are There Benefits to Using Self-Signed Certificates?
As stated above, the most tangible benefits of this strategy are saving money and reducing administrative efforts. Additionally, self-signed certificates be a valid alternative for securing internal communications or testing environments.
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.
The Major Risks of Self-Signed Certificates
When compared with certificates signed by CAs, self-signed certificates are often viewed as less trustworthy because they contain both the public and private keys in the same entity.
One of the key limitations of self-signed certificates is often mistaken for a benefit: self-signed certificates cannot be revoked, and they never expire. This makes a compromised certificate difficult to identify, which several security challenges. CAs can revoke a certificate if they discover it has been compromised, but organizations must go through the process of replacing or rotating the certificate. This “set it and forget it” mentality around certificates, along with the inability to rapidly revoke a compromised private key associated with a self-signed certificate, can open the door to malicious attackers. As we have discovered, shorter certificate validity periods are a good thing.
It’s also important to be aware of how in-house developers are using self-signed certificates. Rather than purchasing CA certificates, individuals tend to rely on OpenSSL, an open-source implementation of SSL, to create the certificates they need. This requires developers to request and configure each certificate independently, which is an enormous effort that essentially offsets the administrative responsibilities of a CA.
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 it really 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 is common when organizations use self-signed certificates.
Couple these self-signed certificate vulnerabilities with the operational challenges most organizations face with expiring and misconfigured certificates, and you can see how attackers can easily exploit this vulnerability. A machine identity management stategy is vital to detect and monitor certificates, identify rogue certificates in use, and quickly remediate. For added protection, establish a baseline, and automatically acquire new certificates to replace those that do not comply with the policies they have established.
Machine identity management solutions, such as TLS Protect by Venafi, eliminates the headache and human error from using CA-signed certificates with automation and full certificate visibility. Discover exactly how many keys and certificates you have across environments and automate replacement.
Cyber Attacks That Have Exploited Self-Signed Certificates
Several attacks have successfully exploited self-signed certificates. For example, thousands of malware samples
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.
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.
Conclusion
All certificates, especially self-signed certificates, need to be secured and protected. Most 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.
Related blogs
