Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


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 (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.


Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 8/10/2020
Researcher Finds New Office Macro Attacks for MacOS
Curtis Franklin Jr., Senior Editor at Dark Reading,  8/7/2020
Exploiting Google Cloud Platform With Ease
Dark Reading Staff 8/6/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: They said you could use Zoom anywhere.......
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Changing Face of Threat Intelligence
The Changing Face of Threat Intelligence
This special report takes a look at how enterprises are using threat intelligence, as well as emerging best practices for integrating threat intel into security operations and incident response. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-08-13
For GitLab before 13.0.12, 13.1.6, 13.2.3 a cross-site scripting vulnerability exists in the issue reference number tooltip.
PUBLISHED: 2020-08-13
An issue was discovered in Zalo.exe in VNG Zalo Desktop An attacker can run arbitrary commands on a remote Windows machine running the Zalo client by sending the user of the device a crafted file.
PUBLISHED: 2020-08-13
FUEL CMS 1.4.7 allows SQL Injection via the col parameter to /pages/items, /permissions/items, or /navigation/items.
PUBLISHED: 2020-08-13
Pega Platform 8.2.1 allows LDAP injection because a username can contain a * character and can be of unlimited length. An attacker can specify four characters of a username, followed by the * character, to bypass access control.
PUBLISHED: 2020-08-13
For GitLab before 13.0.12, 13.1.6, 13.2.3 a memory exhaustion flaw exists due to excessive logging of an invite email error message.