Perimeter
4/4/2011
08:24 AM
Tom Parker
Tom Parker
Commentary
Connect Directly
RSS
E-Mail
50%
50%

The Public Key Infrastructure Under Siege

The abuse of certificates in the Stuxnet and Comodo attacks should come as no surprise given the flawed trust model

The idea of a public trust-based cryptographic signing infrastructure has always struck me as something of a paradox.

Through the use of websites utilizing public certificate authority (CA) signed SSL certificates, many of us have become accustomed to entrusting tens, if not hundreds of thousands, of dollars and some of our most confidential data to a group of mostly privately held organizations that, in reality, we know very little about. If posed the question of providing these same organizations with your online banking credentials, access to your email, or even access to your home, most without hesitation would politely decline.

And so in early July 2010 when I saw that Stuxnet came equipped with two device drivers signed by compromised semiconductor company certificates, my surprise wasn't associated with this particular occurrence -- but that there is no real evidence it had happened before.

Prior to the public discovery of Stuxnet in June 2010, there are no clear public occurrences of a malicious Windows device driver being signed by a valid, compromised signing key. Rather than going to the lengths of acquiring a real key, it has been fairly commonplace for malware components to be signed with a fraudulent signing-key, which has been created to reflect all of the certificate fields of the real signee -- of course, with the exception of being signed by a commonly trusted certificate authority.

Although this might seem like a trivial trick, it worked. An unfortunate result of many years of misuse of the public trust system is that the status quo has become numb to those "pesky" certificate validation warnings. This is largely due to the huge amount of SSL websites out there, configured with certificates that are self-signed, expired, with host name mismatches, and a plethora of other issues that might cause an error to be presented to the user.

Everyone is guilty of it, from large governmental and commercial entities, to small businesses that are reluctant to shell out the around-$200 for a signed cert. So it should really come as no surprise that when the bad guys took it upon themselves to exploit the status quo's lack of respect for that pesky little certificate error, now we're all getting owned.

When news of Stuxnet leveraging real, stolen certificates broke in July 2010, a mistake I believe many made was to be overly impressed by this feat. While there are no clear records of this happening before, just because it might be the first time it has been done doesn't make it difficult.

Many types of organizations are issued with signing keys that are trusted by default by common operating systems, and these are issued for numerous purposes, from the creation of installers, device drivers, at email gateways, and websites -- you name it. This creates a fairly significant attack surface and when tasked with trying to compromise such a key, today's adversary has a lot of soft targets to pick from.

While details are lacking regarding the compromise of keys used by Stuxnet, it is highly likely that the systems they were pilfered from lacked controls that many might consider best practice and may have been selected as soft targets by those behind Stuxnet for this reason.

Then there is Comodo. Comodo's hack marks yet another nail being firmly driven into the proverbial PKI coffin. Much like JMicron and Realtek in Stuxnet, details of how the attacker broke into one of Comodo's registration authorities (InstantSSL.it) are yet to be fully confirmed -- however, it does demonstrate an inherent problem with the PKI today: delegation of authority.

While scrutiny over security issues may be more easily placed on each of the root CAs, once authority starts being delegated to who knows how many secondary organizations, the situation suddenly becomes a lot more tricky to manage. As consumers, we are now having to trust a friend of a friend, rather than someone that we might have more direct trust for.

But if fooling people that a website is real, why bother going to the effort of stealing real signing keys?

Not everyone is so easily misled, and while users will always be users, software vendors are starting to understand these problems and accordingly are taking a more proactive approach in making decisions about whether to trust a signature, often without needing to ask the end user, who in all likelihood doesn’t know any better anyway.

The recent move by several Web browser vendors to force Online Certificate Status Protocol (OCSP) checking by default is a good example of this. There are few of us who manually added blacklists and were proactively looking out for the illicitly acquired Comodo certificates within days of the news breaking.

Over the next 12 months, we will see a rapid increase in the amount of malware utilizing certificates stolen through one means or another. In order to counter this, we will for now find ourselves having to keep a closer eye on the CAs our infrastructure trusts out of the box and have to manage our own CAs, for life's more sensitive purposes. It is without doubt that PKI served its purpose in its infancy and continues to offer a degree of protection.

I am certain that unless we find a revolutionary way to salvage it, PKI's days as we know it are truly numbered.

Tom Parker is director of security consulting services at Securicon.

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-4262
Published: 2014-07-28
svnwcsub.py in Subversion 1.8.0 before 1.8.3, when using the --pidfile option and running in foreground mode, allows local users to gain privileges via a symlink attack on the pid file. NOTE: this issue was SPLIT due to different affected versions (ADT3). The irkerbridge.py issue is covered by CVE-...

CVE-2013-4840
Published: 2014-07-28
Unspecified vulnerability in HP and H3C VPN Firewall Module products SECPATH1000FE before 5.20.R3177 and SECBLADEFW before 5.20.R3177 allows remote attackers to cause a denial of service via unknown vectors.

CVE-2013-7393
Published: 2014-07-28
The daemonize.py module in Subversion 1.8.0 before 1.8.2 allows local users to gain privileges via a symlink attack on the pid file created for (1) svnwcsub.py or (2) irkerbridge.py when the --pidfile option is used. NOTE: this issue was SPLIT from CVE-2013-4262 based on different affected versions...

CVE-2014-2974
Published: 2014-07-28
Cross-site request forgery (CSRF) vulnerability in php/user_account.php in Silver Peak VX through 6.2.4 allows remote attackers to hijack the authentication of administrators for requests that create administrative accounts.

CVE-2014-2975
Published: 2014-07-28
Cross-site scripting (XSS) vulnerability in php/user_account.php in Silver Peak VX before 6.2.4 allows remote attackers to inject arbitrary web script or HTML via the user_id parameter.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Sara Peters hosts a conversation on Botnets and those who fight them.