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.

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Inside the Ransomware Campaigns Targeting Exchange Servers
Kelly Sheridan, Staff Editor, Dark Reading,  4/2/2021
Beyond MITRE ATT&CK: The Case for a New Cyber Kill Chain
Rik Turner, Principal Analyst, Infrastructure Solutions, Omdia,  3/30/2021
Register for Dark Reading Newsletters
White Papers
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2021-04-15
Sydent is a reference Matrix identity server. Sydent does not limit the size of requests it receives from HTTP clients. A malicious user could send an HTTP request with a very large body, leading to memory exhaustion and denial of service. Sydent also does not limit response size for requests it mak...
PUBLISHED: 2021-04-15
Sydent is a reference Matrix identity server. Sydent can be induced to send HTTP GET requests to internal systems, due to lack of parameter validation or IP address blacklisting. It is not possible to exfiltrate data or control request headers, but it might be possible to use the attack to perform a...
PUBLISHED: 2021-04-15
Sydent is a reference matrix identity server. A malicious user could abuse Sydent to send out arbitrary emails from the Sydent email address. This could be used to construct plausible phishing emails, for example. This issue has been fixed in 4469d1d.
PUBLISHED: 2021-04-15
Wordpress is an open source CMS. A user with the ability to upload files (like an Author) can exploit an XML parsing issue in the Media Library leading to XXE attacks. This requires WordPress installation to be using PHP 8. Access to internal files is possible in a successful XXE attack. This has be...
PUBLISHED: 2021-04-15
The project received a report that all versions of Apache OpenOffice through 4.1.8 can open non-http(s) hyperlinks. The problem has existed since about 2006 and the issue is also in 4.1.9. If the link is specifically crafted this could lead to untrusted code execution. It is always best practice to ...