Given their widespread use and role in securing data, digital certificates have become an increasingly important topic of interest within the security community, and an area of opportunity for innovative attackers.

By submitting your personal information, you agree to receive emails regarding relevant products and special offers from TechTarget and its partners. You also agree that your personal information may be transferred and processed in the United States, and that you have read and agree to the Terms of Use and the Privacy Policy.

Insecure digital certificates undermine the security of an entire infrastructure that relies on PKI and can be used to attack an otherwise secure system.

The risks associated with using weak certificates for SSL/TLS have been widely discussed, and several tools have been released to exploit certificate vulnerabilities. The recent Flame malware exploited a weak certificate and implementation in its attack, which allowed the malware's authors to secretly install the malware while using Microsoft's built-in trust mechanism to make the attack look like standard Windows Update activity.

As with all advanced attacks, malware authors are learning from the certificate exploitation techniques Flame used to construct future attacks, and the recent Adobe certificate attack is proof. Enterprises must learn about the dangers associated with using insecure digital certificates. In this tip, we'll explain the risk that insecure certificates pose to enterprise security, plus how enterprises can avoid digital security certificate problems.

The danger of insecure certificates

Most digital certificate exploits do not result in the execution of malicious code; however, that means these real vulnerabilities are receiving less attention than other threats. That doesn't mean problems with digital certificate exploits should be ignored.

In a blog post, Microsoft explained the PKI vulnerabilities the Flame malware exploited, how Flame took advantage of certificates using the MD5 algorithm, and vulnerabilities in the Terminal Services Licensing Infrastructure certificates. MD5 certificates are vulnerable to collision attacks by determined attackers and are now viewed unfavorably when compared to SHA-1 or SHA-2 certificates. The Terminal Services Licensing certificate vulnerability allowed the Flame malware's author to issue what appeared to be a legitimate Microsoft-issued certificate, but a couple of key details were set incorrectly.

This flaw enabled Flame to perform a man-in-the-middle attack on Windows Update. Certificates normally are the linchpin in validating the security of Windows Update and Microsoft's patches, so it is disconcerting that attackers were able to successfully target what has become a fundamental element of software security.

Protecting enterprises from insecure certificates

Microsoft recently released an update for the vulnerabilities Flame exploited and discussed some other improvements on its PKI blog. Certificate authorities (CAs) should not allow certificates that are less than 1,024 bits and that use the MD5 algorithm, and enterprises should not use them.

Listen to this tip as an MP3!

However, to truly secure digital certificates, enterprises need to take a more active stance in managing the CAs in use, along with their systems configurations. Some enterprises may want to more securely configure their systems for certificate usage by only using trusted CAs, but others may want to take an additional step forward and implement their own PKI (a task that could also be outsourced). To accomplish this lofty goal, enterprises would need to remove all certificate authorities built into their systems and only add in their own CAs from their PKI. Though this would allow for the most control of certificates in use, a significant effort would be required to reconfigure enterprise systems to only trust the internal CA. With such a configuration, an enterprise could avoid using high-risk certificates that rely on the MD5 algorithm and encryption keys using the RSA algorithm that are less than 1,024 bit. Again, additional effort would be required to push software updates or use other signed software, because the Microsoft CA would no longer be trusted.

These steps are not reasonable for most enterprises. Only organizations that adhere to the strictest security requirements would need to take such extensive steps. Implementing these basic steps on a dedicated workstation or system along with other security tools could be useful for analyzing potentially malicious software. A scaled-down approach would be to just remove the CAs included in the root certificate store that don't have a remote chance of being used. This could help minimize the risk from a compromised PKI or CA, because many root certificate stores include a significant number of root certificates that will never be used. By default, the public key of the root CAs are included in the root certificate stores to bootstrap validation of certificates used on the Internet.

From the editors: More on digital certificates

Discern the differences between a digital certificate and a digital signature.

Enterprises that forgo that path should ensure that their CAs and software vendors identify and replace the weak digital certificates described above. Software vendors that include built-in CAs as the default option in their software need to evaluate the CA/Browser Forum Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates to ensure they only include secure CAs that meet those requirements. To check for weak certificates, enterprises can scan their networks with a vulnerability scanner, a configuration management tool or a dedicated tool that has checks for insecure certificates or insecure settings.

Depending on the number of insecure certificates and settings found, an enterprise can manually replace certificates or update its configuration settings. Changing a certificate, or potentially a setting, that is used to encrypt data requires the enterprise to understand all of the changes or have good backups of all the data. If a certificate is securely deleted, it may be difficult, if not impossible, to decrypt the data. Given the effort to make such changes, enterprises may want to evaluate if using 1,024-bit RSA certificates will meet their long-term needs, if more changes are going to be made in the future. Enterprises that provide services that depend on digital certificates for encryption or signing should evaluate their usage of certificates to determine whether an insecure certificate could compromise their service, software or customers.

Conclusion

Digital certificates have been used to secure many different types of data, from signed software and documents to encrypted data. Digital security certificate problems undermine the security of an entire infrastructure that relies on PKI and can be used to attack an otherwise secure system.

Attackers have not widely exploited weak certificates for malicious software signing, but enterprises need to ensure they understand how certificates are used so they can implement an effective program to reduce digital security certificate problems. Quickly addressing these vulnerabilities will help prevent enterprises and consumers from losing trust in updates and certificates.

About the author: Nick Lewis, CISSP, is an information security architect at Saint Louis University. Nick received his master of science in information assurance from Norwich University in 2005 and in telecommunications from Michigan State University in 2002. Prior to joining Saint Louis University in 2011, Nick worked at the University of Michigan and previously at Children's Hospital Boston, the primary pediatric teaching hospital of Harvard Medical School, as well as for Internet2 and Michigan State University.

E-Handbook

0 comments

E-Mail

Username / Password

Password

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy