Attacks/Breaches
9/20/2011
04:42 PM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%
Repost This

DigiNotar Hacked Out Of Business

Doomed certificate authority files for bankruptcy, and industry looks for answers on preventing more CA hacks

Say goodbye to certificate authority DigiNotar: The beleaguered Dutch CA has filed for bankruptcy in the wake of the recent massive breach at the firm, its parent company VASCO Security said today, and has exited the CA business altogether. While the demise of DigiNotar comes as no real surprise given the chain of events that have transpired since it was first learned the CA had been hacked, its downfall has ignited debate over what can be done to prevent digital certificate disasters in the future.

There's no easy way to ensure CAs don't get hacked, or that one is more trustworthy than another if they pass their audits. But there is a way to discourage CA hacks altogether, says Roel Schouwenberg, senior antivirus researcher for Kaspersky Lab: Browser vendors could store a whitelist of proper certificates for the top 10 or 20 targets of cyberespionage, such as Facebook, Gmail, Yahoo, and Tor, as well as any high-profile sites.

DigiNotar's hack was first exposed last month when Google's Chrome team noticed a DigiNotar-issued certificate for google.com that didn't match its internal certificate list for google.com. Schouwenberg says browser vendors could add a similar feature to their software so they could automatically confirm the legitimacy of a certificate. "You need to disincentivize actors to hack CAs. In the current system, we need to live with the fact that CAs can be hacked," he says. Adding a list of known certificates for, say, the top 20 targeted websites would give browsers the ability to vet certs before users get duped.

"Simply doing this within the browser would really disincentivize attackers," he says. "So fixing this aspect of the broken trust model is quite easy."

Revoking certificates is problematic: Not only is it difficult to remove a certificate once a CA accepts it, but when a CA's trust is revoked, there is fallout: "When you try to revoke trust for a CA, you will see major repercussions," such as with the Dutch government agencies that had certs with DigiNotar, Schouwenberg says. "It truly crippled part of the Dutch infrastructure," including hospitals, financial services, and law firms, he says.

So far, most browser vendors have blackballed DigiNotar certs in response. Mozilla took it a step further and called for CAs to beef up their security by conducting a series of security audits and steps this month.

In the wake of the DigiNotar breach, more than 500 rogue DigiNotar digital certificates were created for such high-profile domains as cia.gov, microsoft.com, Microsoft's windowsupdate.com, and mozilla.org, as well as one posing as VeriSign Root CA. In addition, more than 300,000 IP addresses, mostly in Iran, were compromised, and the hacker who breached a Comodo reseller earlier this year claimed responsibility for the DigiNotar hack.

What ultimately doomed DigiNotar was it had known about the hack for weeks before publicly acknowledging the damage.

The DigiNotar disaster, coupled with the breach targeting Comodo, have shed light on worries security researchers have had for some time about the security and ultimate trustworthiness of the existing CA model.

"I think many end users are wondering just why exactly they are trusting these CAs. In many cases these CAs are companies the end users has never heard of. Why did your Web browser blindly trust a medium-size Dutch company [that] had issued a certificate for google.com? Why did your Windows system blindly trust a medium-size Dutch vompany [that] had issued code-signing certificates under the name 'VeriSign Root CA?' It just doesn't make any sense," says Mikko Hypponen, chief research officer of F-Secure Lab.

Take the Bermudan company Quo Vadis Global, Hypponen says. You might have never heard of this root CA, but your browser inherently trusts it: "Your browsers and operating systems blindly trust any certificate issued by this company because they are a root CA. You also blindly trust any certificate issued by the Chinese government via CNNIC root CA," he says.

Meanwhile, VASCO officials maintained that the parent company's authentication technology was not compromised in the DigiNotar incident. "The technological infrastructures of VASCO and DigiNotar remain completely separated, meaning that there is no risk for infection of VASCO’s strong authentication business … We also plan to cooperate with the Dutch government in its investigation of the person or persons responsible for the attack on DigiNotar," said T. Kendall Hunt, VASCO’s chairman and CEO, in a statement.

VASCO has no plans to return to the CA business any time soon, but hopes to "integrate the PKI/identity verification technology acquired from DigiNotar into our core authentication platform. As a result, we expect to be able to offer a stronger authentication product line in the coming year to our traditional customers," Jan Valcke, president and COO of VASCO, said in a statement.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message. Kelly Jackson Higgins is Senior Editor at DarkReading.com. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise Magazine, ... View Full Bio

Comment  | 
Print  | 
More Insights
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-0360
Published: 2014-04-23
Memory leak in Cisco IOS before 15.1(1)SY, when IKEv2 debugging is enabled, allows remote attackers to cause a denial of service (memory consumption) via crafted packets, aka Bug ID CSCtn22376.

CVE-2012-1317
Published: 2014-04-23
The multicast implementation in Cisco IOS before 15.1(1)SY allows remote attackers to cause a denial of service (Route Processor crash) by sending packets at a high rate, aka Bug ID CSCts37717.

CVE-2012-1366
Published: 2014-04-23
Cisco IOS before 15.1(1)SY on ASR 1000 devices, when Multicast Listener Discovery (MLD) tracking is enabled for IPv6, allows remote attackers to cause a denial of service (device reload) via crafted MLD packets, aka Bug ID CSCtz28544.

CVE-2012-3062
Published: 2014-04-23
Cisco IOS before 15.1(1)SY, when Multicast Listener Discovery (MLD) snooping is enabled, allows remote attackers to cause a denial of service (CPU consumption or device crash) via MLD packets on a network that contains many IPv6 hosts, aka Bug ID CSCtr88193.

CVE-2012-3918
Published: 2014-04-23
Cisco IOS before 15.3(1)T on Cisco 2900 devices, when a VWIC2-2MFT-T1/E1 card is configured for TDM/HDLC mode, allows remote attackers to cause a denial of service (serial-interface outage) via certain Frame Relay traffic, aka Bug ID CSCub13317.

Best of the Web