Certificate Breach: 3 LessonsDigiNotar Collapse Exposes Fundamental Security Flaws
Although not the first certificate authority host to be hacked - Comodo was hit in March - DigiNotar's breach reveals security gaps and gaffes that could have been avoided.
A 13-page audit of DigiNotar conducted by IT security firm Fox-IT notes lax monitoring controls and breach-reporting delays that magnified the compromise. Fox-IT is quick to point out, however, that the audit report does not aim to offer suggestions for improving or changing certificate-issuing practices. Because the investigation into the DigiNotar breach is ongoing, Fox-IT was only willing to comment about facts and findings contained within the report, which is public.
DigiNotar: What HappenedHackers targeted DigiNotar, like Comodo, to issue counterfeit certificates for common sites such Google and Skype. With these fraudulent certificates, hackers allegedly directed Web users to ghost sites that mimicked those sites users trust.
Under common Internet browsing behavior and standards, it's difficult for the average Web user to spot a counterfeit site. And browsers, based on the faith they have for the companies that issue certificates, often trust a certificate if it appears to come from a respected issuer.
In all, 531 counterfeit certificates were issued, and more than 50 common names found in certificates are believed to have been copied by hackers in the DigiNotar case. Among the list of those 50 or so names are Google, Skype, Microsoft, blog-provider Wordpress, Equifax, Mozilla, CA Thawte and WindowsUpdate.
Given the use of common names like Google and Skype, it seems logical that the hackers tried to infiltrate Gmail e-mail accounts and perhaps listen to calls made via Skype. The audit also notes the use of Microsoft.com and WindowsUpdate, which could be used to issue malicious software.
Fox-IT also tracked the certificates and found that most of the online users who were being rerouted to counterfeit sites resided in Iran. [A map of the online usage tracked by Fox-It may be viewed here.]
"It is very likely that people in Iran were going to websites where the fake certificates were installed," says Joost Bij, CISSP and marketing manager at Fox-IT. "A logical explanation is that the government rerouted the traffic from Google and other sites so that they could eavesdrop ... but there is no proof."
3 Lessons LearnedThe DigiNotar breach should serve as the proverbial wake-up call, industry experts say.
"For a CA company, your whole business is based on issuing certificates that browsers trust," says Mike Smith, an online security expert at Akamai. "When the browsers took DigiNotar's CAs out of their CA lists, that put them out of business. If all the browsers take the CA certificate out of their lists, then any certificate that DigiNotar signs will not be recognized by the browser. So why would I get a certificate from you if it doesn't work anywhere?"
Among the lessons from the DigiNotar case:
- Immediate breach notification is a necessity. "Comodo was also hacked, but they announced it right away and people took actions to mitigate the risks of the certificates that were issued fraudulently," says Fox-IT's Bijl. "In the case of DigiNotar, they put their trust in the balance by not telling that they were hacked."
Several weeks passed between the time hackers infiltrated the DigiNotar system in June and when Dutch authorities and browsers were alerted to the problem, after an Iranian user mentioned a fraudulent G-mail certificate on the Google mailing listing, in August. "That was the big issue," Bijl says. "The government publicly revoked trust in DigiNotar and then, quickly thereafter, Google, Firefox, Microsoft and the others revoked their trust, too."
- Because hacks are unavoidable, heightened security and monitoring are a must. "The problem is not so much that they were hacked, because that can happen," Bijl says. "But the problem is that they did not deal with it on time."
More immediate notification of the breach would have made a difference, obviously. But monitoring and security also posed concerns during the audit. "Disconnecting the core PKI-systems from the Internet is an industry best practice," Bijl says. "Those systems should not have been connected to the Internet."
In the audit, IT-Fox notes the rogue certificate found by Google was issued by the DigiNotar Public CA 2025. But that serial number did not exist in DigiNotar's CA systems records. "This leads to the conclusion that it is unknown how many certificates were issued without any record present," Fox-IT says. To identify unknown certificates, Fox-IT recommended DigiNotar set up monitoring requests.
Those monitoring requests were set up Sept. 1, two months after hackers first hit DigiNotar. It's likely many counterfeits got through.
Fox-IT notes the only way a certificate would be flagged by browser is if the CA sends a response to the browser saying the certificate has been revoked. Even if the serial number of the certificate presented is unknown, unless revoked, the CA response to the browser typically says the certificate is good.
- The current system is flawed. The good news is: lingering or unknown losses associated with a breach like DigiNotar's are unlikely, since tracking post-breach activity is relatively easy. Unknown serial number requests can be reviewed and analyzed during a post-breach investigation. And when a large number of requests to are linked to a single serial number, that raises a red flag.
The bad news is: The fundamental way certificate approval works is flawed. Most of that trust hinges on the relationship browsers have with certificate issuers. No single enforcement or regulatory body has been charged with setting a standard. "You could reasonably say ICANN [the organization that assigns Internet addresses] could be a body that might take that on, but so far, it's been the CAs policing themselves," says Akamai's Smith. "This is why the DigiNotar thing is so big, because the browser manufacturers are agreeing amongst themselves to block DigiNotar."