Evidence Suggests DigiNotar, Who Issued Fraudulent Google Certificate, Was Hacked Years Ago

from the diginot dept

Tue, Aug 30th 2011 2:08pm — Mike Masnick

The big news in the security world, obviously, is the fact that a fraudulent Google certificate made its way out into the wild, apparently targeting internet users in Iran. The Dutch company DigiNotar has put out a statement saying that it discovered a breach back on July 19th during a security audit, and that fraudulent certificates were generated for "several dozen" websites. The only one known to have gotten out into the wild is the Google one. Either way, as everyone scrambles to clean this up, you should remove DigiNotar from your browser trust root (usually under "advanced" or somewhere in the options). Whether or not you do this, DigiNotar is probably effectively dead as an ongoing issuer of security certificates. No one will trust them again.

So how was this done? The folks at F-Secure have found some evidence suggesting the company was hacked by Iranian hackers (probably working for the government). But what's really scary, is that the evidence F-Secure found suggests that DigiNotar was hacked at least two years ago. F-Secure also takes issue with DigiNotar's explanation concerning how this one fraudulent Google certificate got out:

While Diginotar revoked the other rogue certificates, they missed the one issued to Google. Didn't Diginotar think it's a tad weird that Google would suddenly renew their SSL certificate, and decide to do it with a mid-sized Dutch CA, of all places? And when Diginotar was auditing their systems after the breach, how on earth did they miss the Iranian defacement discussed above?

Realistically, this raises a much larger issue about our reliance on these Certificate Authorities, and what happens when their security is weak, as appears to be the case with DigiNotar. As the EFF notes, it's time to move beyond this method of security:

As the problems with the certificate authority system become clear, lots of people are working on ways to detect and mitigate these attacks. Chrome's pinning feature is available not only to Google web sites but to any webmaster; if you run an HTTPS site, you can contact the Chrome developers and get your site's keys hard-coded. Other browser vendors may implement a similar feature soon. The same result could also be achieved by giving web sites themselves a way to tell browsers what certificates to anticipate�and efforts to do this are now underway, building on top of DNSSEC or HSTS. Then browsers could simply not believe conflicting information, or at least provide a meaningful way to report it or warn the user about the situation.

Of course, there will be no DNSSEC if PROTECT IP passes... Another reason to worry about that law, as it closes off one path to protect against these kinds of attacks.

Thank you for reading this Techdirt post. With so many things competing for everyone’s attention these days, we really appreciate you giving us your time. We work hard every day to put quality content out there for our community.

Techdirt is one of the few remaining truly independent media outlets. We do not have a giant corporation behind us, and we rely heavily on our community to support us, in an age when advertisers are increasingly uninterested in sponsoring small, independent sites — especially a site like ours that is unwilling to pull punches in its reporting and analysis.

While other websites have resorted to paywalls, registration requirements, and increasingly annoying/intrusive advertising, we have always kept Techdirt open and available to anyone. But in order to continue doing so, we need your support. We offer a variety of ways for our readers to support us, from direct donations to special subscriptions and cool merchandise — and every little bit helps. Thank you.

–The Techdirt Team

Filed Under: certificates, certification authority, hackers, iran, security
Companies: diginotar, google

13 Comments

If you liked this post, you may also be interested in...

Reader Comments

Subscribe: RSS

View by: Time | Thread

SD (profile), 30 Aug 2011 @ 2:27pm

Seems like most of these problems involve one trusted root changing to another completely different one in the spoofed cert. Browsers should easily be able to throw up a red flag if the old CA doesn't match the new one. A user might click through it, but a graphical web of trust model should be implemented too. If a user in Iran is shown on a world map that the change is concentrated in Iran they would know some funny business is going on.
[ link to this | view in chronology ]
Anonymous Coward, 30 Aug 2011 @ 2:32pm

Yes because DNSSEC is so much better... as Bernstein explains you could just DDoS the entire world.
[ link to this | view in chronology ]
- Anonymous Coward, 30 Aug 2011 @ 3:02pm
  
  Response to: Anonymous Coward on Aug 30th, 2011 @ 2:32pm
  A cure worse than the disease
  [ link to this | view in chronology ]
- Anonymous Coward, 30 Aug 2011 @ 3:25pm
  
  Re:
  Bernstein is the idiot responsible for worthless crap like qmail -- which neatly "solved" various SMTP problems by ignoring the standards. He is not, repeat NOT, any kind of expert on real-world network/server/service management issues.
  [ link to this | view in chronology ]
  - Anonymous Coward, 30 Aug 2011 @ 3:29pm
    
    Re: Re:
    Really? What worthless crap did YOU write? Are you an expert in cryptography? I thought so. So shut up instead of writing useless crap in blogs.
    
    http://en.wikipedia.org/wiki/Daniel_J._Bernstein
    [ link to this | view in chronology ]
    - Anonymous Coward, 30 Aug 2011 @ 4:18pm
      
      Re: Re: Re:
      I'm sure that many novices are unaware that there is a huge gap between theoretical cryptography and actual real-world functional, usable, scalable cryptography.
      [ link to this | view in chronology ]
      - Anonymous Coward, 30 Aug 2011 @ 4:52pm
        
        Re: Re: Re: Re:
        Even if you dislike him extremely, it doesn't take away the false sense of security that DNSSEC creates, and the end problem of being able to flood using it. He still proves the concept.
        [ link to this | view in chronology ]
Anonymous Coward, 30 Aug 2011 @ 2:41pm

Tough problem to solve
"if you run an HTTPS site, you can contact the Chrome developers and get your site's keys hard-coded."

a) I don't think this could scale very far (a couple dozen are supported so far).
b) google in essence becomes the cert authority - who's to prevent them from getting false info.
c) These are hard-coded into the binary. If google wants to revoke a trusted cert, they have to wait for users to update chrome.

Tackling this issue is a valuable endeavor, and I'd love to see other ideas. Its not a simple problem.
[ link to this | view in chronology ]
- SD (profile), 30 Aug 2011 @ 3:16pm
  
  Re: Tough problem to solve
  Except Google isn't offering to hard-code site certificates at all.
  
  They are offering to hard-code the new "HTTP Strict Transport Security" setting, which solves a different problem. HSTS just forces a browser to load a site via HTTPS all the time rather than HTTP. It doesn't need to be hard-coded. A site owner can set up a HSTS response header on their site themselves, and upon every subsequent reload of their site it will never attempt an unencrypted connection until the header expires. Most likely Google will end up only hard-coding a list of payment processors and banking institutions or remove hard-coding completely.
  [ link to this | view in chronology ]
  - Anonymous Coward, 30 Aug 2011 @ 3:48pm
    
    Re: Re: Tough problem to solve
    That makes more sense. So that whole paragraph from the EFF about "Chrome's pinning feature is available not only to Google web sites but to any webmaster" is a bit of bunk then?
    [ link to this | view in chronology ]
eric, 30 Aug 2011 @ 2:50pm

I don't consider myself an expert, but I have looked into their service for the Dutch organisation I work for and thought it was a big step forward in getting communication between companies digital. No longer paper and stamps, but fast and trusted emails. That "trusted" part was the most important. Diginotar is a TTP (TRUSTED third party, oops) and the safety aspect is considered crucial by our lawyers. A small experiment with the service will now be a little bit further in the future I guess. Also shows that my line of business (post and archives) has changed from putting date stamps with red ink on paper to reading Iranian dissident blogs. Any suggestions about which websites/blogs it is smart to follow if you have my job (in Holland I follow "Breed")?
[ link to this | view in chronology ]
DinDaddy (profile), 30 Aug 2011 @ 3:01pm

Of course, there will be no DNSSEC if PROTECT IP passes...
The internet routes around damage.
[ link to this | view in chronology ]
- Anonymous Coward, 30 Aug 2011 @ 6:11pm
  
  Re: Of course, there will be no DNSSEC if PROTECT IP passes...
  What happens when America is considered 'damaged'?
  [ link to this | view in chronology ]