Traditionally, organizations have used certificates signed by Certificate Authorities (CAs) to secure both external and internal communications. Because security breaches and attacks on CAs are on the rise, however, organizations are looking for ways to reduce their threat surface. One strategy is to use self-signed certificates to secure communications between internal systems and to authenticate devices and users to the internal network.
When compared to certificates signed by CAs, self-signed certificates are typically considered untrustworthy because they contain both the public and private key in the same entity. This assessment may hold true when a self-signed certificate is used on a publicly accessible service, but self-signed certificates can be a valid alternative for securing internal communications. If properly secured, self-signed certificates greatly reduce the risk profile of using CA certificates for internal communications.
There’s no doubt the industry understands the benefits of using self-signed certificates to reduce the threat and exposure to attacks on CAs. However, if organizations do not have the ability to continuously monitor and protect self-signed certificates, cyber-criminals will exploit this strategy and turn it into a weakness, such as those identified in Mandiant’s APT1. (This report summarizes the activities of one of the most active Advanced Persistent Threat [APT] groups and provides guidelines for eliminating vulnerabilities this group exploits.)
A number of attacks have successfully exploited self-signed certificates. For example, the Shylock Trojan, which targeted 24 major banks (including Chase Manhattan, Bank of America, Citi, Wells Fargo, Barclays, and Bank of Scotland) last year, is designed to steal money while customers use online banking services. The Shylock Trojan uses self-signed certificates to disguise the phone home traffic to command and control. Another Trojan attack used a fake, anomalous self-signed certificate, which was supposedly from Adobe, to bypass detection. And earlier this year, Tor network exit relays were manipulated using self-signed certificates to create Man-in-the-Middle (MiTM) attacks.
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 subject. Although CAs can revoke a certificate when they discover it has been compromised, organizations cannot revoke a self-signed certificate. Instead, they must replace or rotate the certificate. If a self-signed certificate’s private key is compromised, the inability to rapidly revoke the key 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 it actually 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.
Organizations should also be aware of how in-house developers are using self-signed certificates. Rather than purchasing CA certificates, many in-house developers download an open source implementation of SSL and TLS, called OpenSSL and create the certificates they need to develop and test software. If used in production versions of applications, these self-signed certificates can make organizations vulnerable to unforeseen attacks. Case in point: the recent Heartbleed vulnerability shows exactly how organizations blindly trust keys and certificates and how quickly and easily cyber-criminals can exploit a trust-related vulnerability.
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. Organizations 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. Organizations also need a mechanism to detect and monitor self-signed certificates, identify rogue certificates in use, and quickly remediate. Furthermore, organizations 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, 51% of organizations do not know exactly how many certificates are in use within their infrastructures—let alone how many of them are self-signed or CA-signed. This represents an unquantifiable risk! Organizations need to gain control over trust. They must not only know which systems use self-signed certificates but also replace these certificates on a regular basis. With clear visibility into their self-signed certificate inventory, organizations can respond much more quickly when certificates are compromised and reduce their risk to trust-based attacks.