26

I admit that while I'm a programmer, my crypto/security knowledge is fairly basic. I understand that the potential of leaking private SSL keys is cited as one of the most serious effects of the Heartbleed bug. My question is, how can an attacker actually use the private key?

Heartbleed.com states that:

These are the crown jewels, the encryption keys themselves. Leaked secret keys allows the attacker to decrypt any past and future traffic to the protected services and to impersonate the service at will.

"Decrypt any past and future traffic" is clear to me, assuming the attacker has (or has had) means of sniffing the encrypted traffic. But I can't quite grasp how they can "impersonate the service at will."

The way I understand it, to impersonate the service, the attacker would need a way to divert traffic to their site, or pose as a man in the middle. And I believe both of these are quite difficult to accomplish (at least when no unsecure network like public Wi-Fi is involved). Is this correct, or am I missing something?

So, perhaps a different way to phrase it: if I, as an end user, type in https://someorotherdomain.tld into a browser's address bar (and there's no certificate problem), how likely am I to be talking to someone else due to someorotherdomain's private key having been heartbled?

Angew is no longer proud of SO
  • 374
  • 1
  • 4
  • 10

3 Answers3

21

Here is an example: My dad started getting browser certificate warnings when he went to Gmail. I looked in his hosts (C:\Windows\System32\drivers\etc\hosts ) file and some malware had edited it to redirect requests to gmail and a bunch of other sites to bad IP addresses that I assume the attacker controlled. His browser warned him because those bad IP addresses did not have the correct private key of the certificate. Now, if they had used a heartbleed type attack to grab those private keys, they could better impersonate the sites and my dad would have never seen a warning.

mcgyver5
  • 6,807
  • 2
  • 24
  • 45
  • 1
    What's the linux equivalent? – Pacerier Apr 11 '14 at 15:47
  • 8
    On Linux: /etc/hosts – mcgyver5 Apr 11 '14 at 16:04
  • Couldn't the potential attacker add his own self-signed certificates, so the browser wouldn't complain about this? – Konrad Borowski Apr 12 '14 at 17:13
  • @xfix That's why browsers complain about self-signed certificates. [HTTP Strict Transport Security](http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security) will allow the browser to completely block access to the website with a self-signed certificate. – Yogu Apr 12 '14 at 18:47
  • 1
    @Yogu: The browsers complain, all-right, but only if the certificate is not recognized. If the certificate is in system's database of certificates, it's fine. – Konrad Borowski Apr 12 '14 at 20:43
  • @Pacerier A simple Google search of `hosts file on linux` would yield the result you wanted. Also, the `\etc\hosts` in the file path is a big hint. – Cole Tobin Apr 12 '14 at 21:00
  • 1
    @xfix Ah, you're right - the attacker must have root access to modify `/etc/hosts`, so it can basically do anything. – Yogu Apr 12 '14 at 22:26
  • @Yogu, If he needs root access to modify `/etc/hosts`, then basically he can already get what he needs *without* modifying it. – Pacerier Apr 14 '14 at 05:09
10

So, perhaps a different way to phrase it: if I, as an end user, type in https://someorotherdomain.tld into a browser's address bar (and there's no certificate problem), how likely am I to be talking to someone else due to someorotherdomain's private key having been heartbled?

You rightfully ask how likely, which does not demand a clear answer but rather a probability. What factors do affect the likelihood?

  • How many gateways are between you and the destination;
  • How many of these can control your DNS queries too;
  • What's the bounty? Or, given the cost of mounting a MITM attack, what are the possible rewards? Which is linked to:
  • How juicy is the target? (e.g. spoofing gmail.com in a public wi-fi in an airport)
  • Which country are you in? Maybe the government wants to know if you're planning to overthrow them. Or they just spy on everyone, all the time, by default.

These should give you a quick back-of-the-envelope calculations on the likelihood of this happening to you personally.

lorenzog
  • 1,911
  • 11
  • 18
  • 5
    Somewhat extending the "control your DNS queries" point: There are also attacks like DNS cache poisoning. Or just send a good old fax to a low-end registrar and have them change authorative DNS servers for that domain. Many other attacks can be chained with that one. – PlasmaHH Apr 11 '14 at 14:15
2

Within a cooperate environment the attacker could have been sniffing from a network switch however that network may employ anti-arp spoofing prevent the attacker from using tools such as SSL strip.. However now the attacker holds the encryption keys he would be able to decrypt all the traffic he had gathered previously.

Sam Aldis
  • 73
  • 7