In recent SEC filings, VeriSign revealed they were repeatedly hacked during 2010. Though the company did not divulge what type of data was breached, the report raised serious concerns – particularly since VeriSign’s claim to fame was their position as a leader in the certificate issuance field. So tightly is the VeriSign brand coupled with certificates that that when Symantec purchased this part of their business in August 2010, the security vendor chose to keep the name. We cannot jump to conclusions that the breach had to do with certificate issuance, but this type of incident serves as a reminder of the threats plaguing some of the Internet’s trust models and implementation. Namely, the Public Key Infrastructure (PKI) and Secure Socket Layer (SSL).
While most of the research community is focused on pointing out inherent SSL protocol vulnerabilities and common implementation mistakes that could potentially be subverted for an attack, the hackers are focusing on more practical types of attacks against PKI and SSL. In this column, we will take a look at some of these attacks and the threat landscape facing PKI and SSL.
Some Background: PKI and SSL
In the real world, when we want to make sure a service is honest and delivers us the promised goods we ask for some sort of “seal of trust”. That “seal of trust” usually comes in the form of a certificate signed by a trusted notary that vouches for the legitimacy and honesty of that provider. For that model to work, both the business and the consumer need to trust that notary.
The virtual world works in a similar fashion through an infrastructure called PKI. When we log onto a Web site, say a bank, the browser first requests the site provide it with a certificate guaranteeing that the site is what it appears to be. That certificate is “signed” by the digital equivalent of the notary, called the Certificate Authority (CA).
The certificate does not only guarantee the authenticity of the service, but also the confidentiality of communications between the user and the service. It does this by supplying the required components used to encrypt our transactions. Through the use of encryption, the protocol is able to guarantee the privacy and security of the transactions because it prevents some third party to eavesdrop or modify the transactions. The most popular method of encryption for these transactions is, generally speaking, SSL. When you see https:// (as opposed to just http://) in your browser, you know that SSL is in the works and your communication with the website is encrypted.
The increasing awareness to the confidentiality of our transactions (just recall how much media noise was made following the release of FireSheep) means that more companies are now deploying SSL. SSL is not restricted anymore only to our banking services. Take, Google for instance. At first, only the Gmail login page was encrypted. In time, the whole Gmail service supported encryption – by default. Google has now even added the search functionality to be accessed via https.
Threat #1: Attacks against PKI
It’s easy to see the powerful role that the CA has in the PKI model. Since, at the base of this model is the underlying assumption that the CA is truthful, honest and legitimate. Consequently, a hacker who gains control on a CA can then use it to issue fraudulent certificates and then masquerade as any website.
Over the past year, attackers have repeatedly compromised various CA organizations. These include, DigiNotar, GlobalSign, Comodo and Digicert Malaysia. These attacks were a direct consequence of the commoditization of certificates, where smaller, less competent organizations have started to obtain a bigger share in the certificate authority market. As it stands now, any CA can issue a digital certificate for any application – without any required consent from application owner.
Last weekend, Trustwave published a blog entry which in itself shows how fragile is this system. As a CA, they had once issued a certificate specific to an unnamed private company which allowed the interception of all SSL communications within the company. As part of this admission, Trustwave also announced that they will not repeat this type of offering again.
Threat #2: The Theft of Issued Website Certificates
The problem here is that Web application certificates are not simply confined to being stored by the application. While SSL prevents access to traffic by attackers, it has no built-in mechanisms that allow restrictive access to it by collaborative third parties. For example, proxies, load balancers, content delivery networks (CDNs) need to access the certificate’s private key in order to access application data. Also data loss prevention and Web application firewall solutions require similar key access. As a result, the digital certificate is now stored in many locations – some residing outside of the site’s physical environment and out of the application’s owner control. These open up additional attack points which imply a higher success rate for attackers.
Threat #3: The Theft of Issued Code Signing Certificates
The problem is not only with online services. Also applications present certificates that attest to their legitimacy before performing sensitive operations. Therefore, code signing certificates are too a prime target for malware distributers. We’ve already witnessed this in the wild – Stuxnet for instance used a stolen certificate. More recently, a malware strain used a stolen certificate belonging to the Malaysian government.
Threat #4: Denial of Service attacks
Because of the encryption component – there is a heavy computational burden incurred when initiating the SSL communication. Therefore, SSL-protected resources are prime candidates for effective Denial of Service (DoS) attacks. Together with an increased consumption of computer resources per session, a multitude of simple attacks can be devised very efficiently.
Addressing the Threats
As for the denial-of-service attacks, it is possible to strengthen the applications using anti-DoS and anti-DDoS protections.
What about the other threats? The issues posed by PKI and SSL have gotten security researchers to explore improvements and alternatives. Google for instance, has recently published their proposal. Their enhancement includes adding server side support for a new strand of the encryption protocol. Their assumption is that 10 years from now someone might break the current encryption protocol and would use that capability to go back and decipher recorded streams. But understanding the problem leads half-way to the solution and unfortunately, this research does not address the above practical problems.
Nevertheless, the industry is humming. In fact, Moxie Marlinspike discussed a lot of these problems in Black Hat USA 2011. His project to amend the PKI issues is ongoing although, long due from being widely accepted.
As it stands now, the ground is still ripe for the research of an alternative, stronger model. It won’t be a simple solution and will require the collaboration of both academia and industry experts. Any volunteers?
Update 4/06/2012: It was brought to my attention that the attack against StartSSL was not successful as I had previously implied. I apologize if anyone or any company may have taken offense. I had no intention to point fingers but to present the real-world implications of attacks against certificate-issuing companies.
