DigiNotar Roundups
Early this week, I did a quick and dirty write-up trying to do a high level explanation of what is going on with DigiNotar and why it’s important. Since then there have been a lot of pieces that had dropped that are directly or indirectly related to the incident.
In Context
The ComodoGate hacker has ‘come forward’ claiming responsibility for the DigiNotar crack as well as claimed successful attacks on other Certificate Authorities (CA’s) including major world player GlobalSign. ComodoGate is the widely reported name given to a similar event earlier this year where a CA and anti-malware developer Comodo had a user account compromised, resulting in the issue of nine rogue signing certificates. In response to the allegations, GlobalSign suspended issuance of new certificates until at least Monday while hiring the same security technicians as DigiNotar to investigate the alleged breach.
The investigation has found evidence suggesting that a web server hosting the corporation’s website had been compromised. It must be stressed, however, that the server was always isolated from the rest of the company’s infrastructure; thereby making it no more of a jump point for attacking the server involved with their Certificate business than any other computer on the internet. Additionally, they have found no evidence of any compromises in the remainder of their systems. The fallout from this is yet to be seen. This was the same language used with relation to the Sony PlayStation Network credit card database attack, which to this day shows no suggestive evidence (much less conclusive) that the database was compromised or touched. Aside from a handful of anecdotal accounts from users, neither Sony nor any credit card company has seen fraudulent activity on cards; yet the fallout from the intrusion is at least evident even if the breaches were clouded in media hyperbole. This is not to say the breach at Playstation, or GlobalSign is not severe, but it has to be taken into context. Security is not about eliminating threats, but reducing the amount of threats and learning to live with the ones you can’t eliminate While data might have been accessed it was protected from being used in any meaningful way, and I think it’s both unfair and rather dangerous to suggests that either GlobalSign, DigiNotar, or Sony are any worse off than a majority of the companies running large computer infrastructures.
The Zilla Speaks Up
Mozilla, the makers of the Firefox Web browser, took other measures this week in response to the DigiNotar incident. As reported last week Mozilla, Microsoft, and Google all issued revocations of the programmed trusts of DigiNotar’s certificates last Friday (Sep 2nd). In addition to this action, Mozilla has requested that all CA’s currently participating in the trusted CA program (that have a “root” trust in Firefox) perform security audits of their Private Key Infrastructures (PKI’s : The servers that run this whole show). Mozilla issued a set of requirements that are intended as guidelines for any CA’s wishing to continue their presence in Mozilla’s trusted CA Program, and extend to any third party CA’s that the root CA’s are essentially vouching for by signing the third party’s root certificate. All technical jargon aside, Mozilla is starting a discussion and potentially naming requirements to try to close up holes in the entire SSL system as it is today. Part of this discussion is already touching on the idea that most of the oversight and guidelines in place have a much stronger focus on governance, ITIL, and ETSI audits than actual security practices; a situation that is probably not appropriate when dealing with a company or department that is in the business of security. The big question is does Mozilla have enough clout to turn this discussion into action.
Of Apples and Indians
When beginning to work on this write-up, Apple was being singled out. As of Friday (Sep 9th) morning (7 days following the revocation of DigiNotar Certificates by the major players in the web-browsing arena) Apple still had not revoked trusts to DigiNotar. Worse yet, security technicians from leading security groups were confirming that manual revocation within Safari wasn’t working as intended, and sites certified by DigiNotar were still showing up as valid. It seems being called out on the event had gotten a reaction as Friday afternoon a number of out of band security updates were implemented in an attempt to fix this oversight. The situation, however, underscores many of the security concerns with Apple, more than anything else.
Another security hole was upgraded to a critical issue a few weeks ago, as a denial of service attack tool was found in the wild for a major flaw that has been present in the Apache web-server and known for nearly a decade now. Apache is an open-source program that serves websites and makes up a majority of the internet today. Apache developers were quick to release a mitigation that could be made to the configuration until a patch was released; the patch was promised and released within 48 hours of the announcement. Even at the time of the announcement, there were concerns as Apple ships their own flavour of Apache with their operating systems and all patches end up going through Apple governance. In many cases patches for security issues have seen delays upon delays, and many fixes have never seen the light of day. At the writing of this article, conservatively nine days since the patch was released, a number of simple Google searches show that there are only two options available to users of Apache on OSX. Manually apply the patch and hope nothing breaks, or use the mitigation configuration. (As of yet I’ve not heard of anyone manually applying the patch).
SSL: Is it broken?
I wanted to touch a bit deeper on SSL and what it is. In the article previously I pointed out that SSL is a two part strategy for dealing with websites and services across the internet. One part of SSL is the ability to encrypt data so a third party cannot look at it, the other part is essentially giving the user the confidence that the website or services are who they claim to be. A critical discussion has been on-going for several years questioning if the SSL Regime is broken. The main argument has centered on the trust issue and asking who are these companies that we are trusting to tell us this website is legitimate? In the end that’s the flaw in the system and that’s what we, as users, need to manage. How much do we trust the site, or the person telling us to trust the site? Hopefully the Mozilla CA discussion will yield some movement in this arena that points the industry in the right direction.
As for why this is such a big deal, I propose the following situation. On April 8th of 2010, for approximately 18 minutes, a “configuration error” at a Chinese telecom resulted in a reported 10% to 15% of the world’s traffic being routed through the Chinese internet and included US government and military traffic, among others. Allegations have flown that even larger and longer route poisoning incidents have taken place since. Consider if you will, a rogue nation poisoning routes and similarly hijacking all data destined for servers of MI6, one of Britain’s intelligence departments. Now imagine they have set up servers to replicate the behavior of MI6’s infrastructure and loaded SSL certificates from a compromised CA. People and automated services could then connect to these fake MI6’s and offload data to them in what appears to be a secured and safe manner. There are even methods available to simply use this technique to sit and watch the data without the information failing to make it to MI6’s servers. By the time MI6 or the party trying to connect to them has figured out they were being tricked, the data is already in the hands of this fictional rogue state. At this point, the only protection is hoping that the data’s useful lifespan is much less than the time it takes for the attacker to break whatever encryption might have been wrapped around the data in addition to the PKI encryption provided by SSL.
