Risk
11/8/2012
06:05 PM
Connect Directly
RSS
E-Mail
50%
50%

Salvaging Digital Certificates

Following breaches at Diginotar, Comodo, and RSA, digital certificate technology has been deeply tarnished. Here are five ways to shine it up and make it work for your organization.

One year ago, Gmail users in Iran woke up to a chilling prospect: Their sensitive and supposedly secure communications on Google's email program may have been tapped by unknown parties. A phony digital certificate in Google's name was used to impersonate the site and let the culprits mount a "man in the middle" attack to intercept and decrypt email sent to Google's servers before passing the messages along to the intended recipients.

In the search for the source of the phony certificate, all eyes turned to DigiNotar, a certificate authority in Beverwijk, Netherlands. DigiNotar admitted that it had been the victim of a cyberattack a month earlier whereby the attackers generated hundreds of bogus certificates in the names of some of the Internet's most trusted brands, including Google, Yahoo, Skype and the anonymity network Tor. Use of the fraudulent certificates was concentrated among Iranian users, leading to speculation that the attack was linked to that country's intelligence services, which have been cracking down on political dissidents.

The DigiNotar attack was the worst security compromise at a certificate authority to date. But it was hardly the only such attack. It came just months after an attack on a business affiliate of Comodo, a New Jersey CA. In that incident, the attackers generated phony certificates also in the names of prominent online brands.

These successful attacks were earth shaking because digital certificates and the encryption keys they represent are the bedrock of Internet communications. They secure everything from VPN connections to protocols such as TLS (Transport Layer Security) and SSL (Secure Sockets Layer) that protect billions of Web sessions and online transactions daily. At the heart of this system is a global public key infrastructure network of some 300 CAs entrusted with issuing certificates to individuals and organizations.

Certificate authorities are gatekeepers. They verify the identities of individuals and organizations before issuing digital certificates that contain the public and private encryption keys used to secure online exchange of information.

At least that's how it's supposed to work. As the DigiNotar attack revealed, CAs aren't Fort Knox-style identity vaults but rather are businesses subject to their own security mishaps. In the last year, CAs have come under attack from sophisticated and possibly nation-backed hacking crews, exposing security lapses and poor internal controls.

The current system leaves security-conscious businesses in a pinch. More than ever, they need secure and reliable identity services to back up their growing online presences, but the system in place is more vulnerable than ever.

What's to be done? Many experts say certificate technology still has a future and that security-conscious organizations can protect themselves by understanding the gaps in the system and taking common-sense steps to avoid them.

chart: CA compromises come in many flavors

Previous
1 of 4
Next
Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading Must Reads - September 25, 2014
Dark Reading's new Must Reads is a compendium of our best recent coverage of identity and access management. Learn about access control in the age of HTML5, how to improve authentication, why Active Directory is dead, and more.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-5485
Published: 2014-09-30
registerConfiglet.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via unspecified vectors, related to the admin interface.

CVE-2012-5486
Published: 2014-09-30
ZPublisher.HTTPRequest._scrubHeader in Zope 2 before 2.13.19, as used in Plone before 4.3 beta 1, allows remote attackers to inject arbitrary HTTP headers via a linefeed (LF) character.

CVE-2012-5487
Published: 2014-09-30
The sandbox whitelisting function (allowmodule.py) in Plone before 4.2.3 and 4.3 before beta 1 allows remote authenticated users with certain privileges to bypass the Python sandbox restriction and execute arbitrary Python code via vectors related to importing.

CVE-2012-5488
Published: 2014-09-30
python_scripts.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via a crafted URL, related to createObject.

CVE-2012-5489
Published: 2014-09-30
The App.Undo.UndoSupport.get_request_var_or_attr function in Zope before 2.12.21 and 3.13.x before 2.13.11, as used in Plone before 4.2.3 and 4.3 before beta 1, allows remote authenticated users to gain access to restricted attributes via unspecified vectors.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
In our next Dark Reading Radio broadcast, we’ll take a close look at some of the latest research and practices in application security.