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.

Perimeter

4/4/2011
08:24 AM
Tom Parker
Tom Parker
Commentary
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.

 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Oldest First  |  Newest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/13/2020
Omdia Research Launches Page on Dark Reading
Tim Wilson, Editor in Chief, Dark Reading 7/9/2020
Russian Cyber Gang 'Cosmic Lynx' Focuses on Email Fraud
Kelly Sheridan, Staff Editor, Dark Reading,  7/7/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
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 Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-20907
PUBLISHED: 2020-07-13
In Lib/tarfile.py in Python through 3.8.3, an attacker is able to craft a TAR archive leading to an infinite loop when opened by tarfile.open, because _proc_pax lacks header validation.
CVE-2020-14174
PUBLISHED: 2020-07-13
Affected versions of Atlassian Jira Server and Data Center allow remote attackers to view titles of a private project via an Insecure Direct Object References (IDOR) vulnerability in the Administration Permission Helper. The affected versions are before version 7.13.6, from version 8.0.0 before 8.5....
CVE-2019-20901
PUBLISHED: 2020-07-13
The login.jsp resource in Jira before version 8.5.2, and from version 8.6.0 before version 8.6.1 allows remote attackers to redirect users to a different website which they may use as part of performing a phishing attack via an open redirect in the os_destination parameter.
CVE-2019-20898
PUBLISHED: 2020-07-13
Affected versions of Atlassian Jira Server and Data Center allow remote attackers to access sensitive information without being authenticated in the Global permissions screen. The affected versions are before version 8.8.0.
CVE-2019-20899
PUBLISHED: 2020-07-13
The Gadget API in Atlassian Jira Server and Data Center in affected versions allows remote attackers to make Jira unresponsive via repeated requests to a certain endpoint in the Gadget API. The affected versions are before version 8.5.4, and from version 8.6.0 before 8.6.1.