Watch It And Weep

This YouTube video, from the newly-released Fox-IT report into the DigiNotar compromise, demonstrates the extent of the failure. Every red dot is an OCSP hit for the *.google.com certificate, indicating that someone in Iran was successfully MITMed, giving the attacker access to their private Google data. There were over 300,000 unique IPs over the course of a month (August 4th to 29th). See page 8 of the report.

18 thoughts on “Watch It And Weep

  1. It’s awful. These are not regular google searches, but connections that should have been protected. Even worse, those connections coming from outside Iran were from Tor exit nodes and proxies. People taking the effort to go through Tor were intercepted anyway.

    The video covers _weeks_ of MITM activity. Meanwhile, Vasco in its press releases shows zero concern for its responsibility, Diginotar has gone quiet, and all the Dutch government cares about is whether its citizens will be able to file their tax reports.

  2. “The serial number of the certificate was, however, not found in the CA system‟s records” – it just occurred to me that a possible explanation for this would be: the attackers found the private key for the DigiNotar root certificate, copied it and continued generating new certificates on their own machines, without accessing DigiNotar’s systems. Is there anything suggesting that this didn’t happen?

  3. Wladimir: if they had managed to do that, it is unlikely that they would have used the DigiNotar systems, thereby setting off the alarm. Also, private keys are stored in Hardware Security Modules, which makes them very, very hard to copy. Of course, as we have seen, if you have access to the HSM, you don’t need a copy of the key. But when you lose access to it, you can no longer sign stuff.

  4. Are you sure Diginotar used a HSM? They where so totally clueless that I won’t bet on it.

  5. A core part of the problem here is that no major browser checks whether the certificate for the site has unexpectedly changed, and indeed HTTPS is not set up in such a way as to allow the browser to know when to expect normal, predictable changes. Heck, the browser doesn’t EVEN look to see if the new cert is signed by the same CA as the old cert, nor is there any provision for the server to communicate to the browser things like, “Here’s the old cert to show that I’m still the same site as last time, but that’s expired, so here’s a new cert signed by a different CA, which is not expired.” The whole issue of unexpected new certs by different CAs is just completely ignored, as if it somehow weren’t a MUCH more likely indication of something fishy going on than garden-variety expiration, which routinely happens all the time.

    No amount of gratuitous super-enhanced extended ultra-verified mega-expensive prove-you-really-can-afford-this ubercertification will fix this, or even mitigate it slightly. The protocol must be rethought completely, using a model influenced by the way SSH uses SSL (but with provisions for allowing the software to handle new certificates without asking the user about them).

    If the user goes to the same site they went to last week and suddenly out of the blue gets presented with a completely new certificate unrelated to the old one, the browser must pitch a hairy conniption fit — of a much higher order than the relatively mild warning used when a cert is expired or signed by a CA that’s not on The List.

    Ideally this should be implemented in such a way that users who have never visited the site before are in no more danger than under the current system.

  6. I wouldn’t call it “clueless”, rather “neglectful”. It looks like they did their best to fulfill the formal criteria in letter but not in spirit. They did have proper separation of networks but they built a hole into it. They did have regular audits but they failed to act on the results. That’s what I find so ridiculous about the whole thing – they managed to detect the attack before any damage was done and they still messed up! So if they were required to use HSMs then I am pretty sure that they did. But it wouldn’t surprise me if they used one that allowed exporting private keys for backup purposes and stored that backup on one of the machines in the network.

  7. Gerv, your blog supports threaded comments now – you can reply to the comment rather than adding a new comment at the bottom ;)

    Anyway, the video still works for me. Maybe it was only a temporary thing.

  8. If you want to read the personal story of the hacker, start here:
    http://pastebin.com/u/ComodoHacker

    It seems to be profen that he is the one who hacked DigiNotar. What he says fits imo to the report from Fox-IT. He even released a copy of calc.exe signed with the *.google.com cert. (Read the latest paste named “Two more little points”.)

  9. I am still trying to figure out why you are seeing people in USA/Europe making OCSP requests. The report says its mostly TOR exit nodes, but if you are using TOR, where is the opportunity to MITM and present a fake cert?

  10. Note that DNS requests don’t go through TOR (by default, at least).

    So the MITM could respond to your (not TOR-ified) DNS rquest, giving you the IP address of a hacker-controlled web server. Then, you’ll open an SSL connection to that server (which presents you with its fake cert).

    Your SSL connection could be routed through TOR — it doesn’t matter — you’re still talking to the evil server, since you got the wrong answer from DNS.

  11. If what you say is true it would be a major flaw of TOR. It would mean that a MITM (or an ISP) would still know which sites I visit simply by looking at my DNS requests – even though all the browsing traffic goes through the TOR network and is out of reach.

Leave a Reply

Your email address will not be published. Required fields are marked *