08:24 AM
Tom Parker
Tom Parker

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 ( 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
Current Issue
Dark Reading Tech Digest, Dec. 19, 2014
Software-defined networking can be a net plus for security. The key: Work with the network team to implement gradually, test as you go, and take the opportunity to overhaul your security strategy.
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2015-01-23
The Pie Register plugin before 2.0.14 for WordPress does not properly restrict access to certain functions in pie-register.php, which allows remote attackers to (1) add a user by uploading a crafted CSV file or (2) activate a user account via a verifyit action.

Published: 2015-01-23
OpenStack Glance 2014.2.x through 2014.2.1, 2014.1.3, and earlier allows remote authenticated users to bypass the storage quote and cause a denial of service (disk consumption) by deleting an image in the saving state.

Published: 2015-01-23
oggenc in vorbis-tools 1.4.0 allows remote attackers to cause a denial of service (divide-by-zero error and crash) via a WAV file with the number of channels set to zero.

Published: 2015-01-23
Integer overflow in oggenc in vorbis-tools 1.4.0 allows remote attackers to cause a denial of service (crash) via a crafted number of channels in a WAV file, which triggers an out-of-bounds memory access.

Published: 2015-01-23
oggenc/oggenc.c in vorbis-tools 1.4.0 allows remote attackers to cause a denial of service (out-of-bounds read) via a crafted raw file.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
If you’re a security professional, you’ve probably been asked many questions about the December attack on Sony. On Jan. 21 at 1pm eastern, you can join a special, one-hour Dark Reading Radio discussion devoted to the Sony hack and the issues that may arise from it.