Major security flaw undermines Apple and Google users, researchers discover

Major security flaw undermines Apple and Google users, researchers discover(washingtonpost.com)

91 points by derekjobst 11 years ago | 23 comments

Kronopath 11 years ago |

This news story is way too light on details for this audience. A better description of the vulnerability is here: https://www.freakattack.com/

A summary:

The vulnerability allows attackers to intercept HTTPS connections between vulnerable clients and servers and force them to use ‘export-grade’ cryptogrpahy, which can then be decrypted.

A connection is vulnerable if the server accepts RSA_EXPORT cipher suites and the client either offers an RSA_EXPORT suite or is using a version of OpenSSL that is vulnerable to CVE-2015-0204. Vulnerable clients include many Google and Apple devices (which use unpatched OpenSSL), a large number of embedded systems, and many other software products that use TLS behind the scenes without disabling the vulnerable cryptographic suites.

It also includes a list of vulnerable websites, including sites like mit.edu, groupon.com, marriott.com, and americanexpress.com (!).

adsr 11 years ago | |

Something is odd with that site. If I enter https://www.freakattack.com it reports Safari 5.1.10 as safe from the attack. If I simply enter https://freakattack.com it reports it as vulnerable.

AnimalMuppet 11 years ago |

The story has a familiar ring.

Back in the day, Microsoft stored passwords in a fairly insecure format. Then they got security religion, and improved the strength of their password storage dramatically. It was very hard to crack the new format. (I don't remember exactly, but this would have been somewhere around when NT came out.)

But Microsoft was always big on backward compatibility. They wanted users of old machines to still be able to log in to the new servers. So they stored the passwords in the new, strong format, and in the old, weak format, so that they could still authenticate old clients. And that meant that attackers could still get the passwords in the weak format if they could get on the server.

This is from memory, and it's been over a decade, so I may not have all the details exactly correct...

rogerbinns 11 years ago | |

I worked on reverse engineering Microsoft's remote desktop protocol (RDP) back in the day. It was wrapped in encryption much like how SSL operates. France outlawed encryption except for authentication, so you just had to put the client and the server in the French country setting and then man in the middle the tcp connection. Reverse engineer away. Thanks France!

geofft 11 years ago | | |

Ah, is that what the "Disable encryption. This option is only needed (and will only work) if you have a French version of NT TSE." option to rdesktop(1) means. I always wondered about that!

yuhong 11 years ago | | |

Of course, the private key turned out to be hardcoded anyway.

jakejake 11 years ago | |

Yep I remember there were password cracker programs that would recover the "LM" version of the password in seconds. I was a network admin at the time and remember having to turn this "feature" off once we discovered it.

yuhong 11 years ago | |

Ah, LM vs NT hash.

dsp1234 11 years ago | | |

http://en.wikipedia.org/wiki/LM_hash

http://en.wikipedia.org/wiki/NT_LAN_Manager#NTLMv1

and

http://en.wikipedia.org/wiki/NT_LAN_Manager#NTLMv2

AnimalMuppet 11 years ago | | |

Yeah, that was it.

rbanffy 11 years ago |

If http://dualec.org/DualECTLS.pdf is the actual paper, I am not sure why Apple and Google users are more exposed than others. The paper requires a more thoughtful reading, of couse, but it does not appear to single out these two vendors.

Buge 11 years ago | |

Safari and Android browsers are vulnerable.

http://blog.cryptographyengineering.com/2015/03/attack-of-we...

cozzyd 11 years ago | | |

Firefox for Android seems to be fine? (According to the client test)

nmc 11 years ago |

I feel puzzled. How can a WP journalist link to three blog posts about the attack, while not linking to the actual researchers' website?

Here it is: https://www.smacktls.com

yuhong 11 years ago |

What is sad is that OpenSSL disabled the EXPORT1024 ciphersuites in 2006. If you don't know what these are, in year 1999 the US government raised the limit to 56-bit encryption and 1024-bit RSA. They were described in https://tools.ietf.org/html/draft-ietf-tls-56-bit-ciphersuit... . And for the record it was in year 2000 that the restrictions was removed for "retail" software.

MBlume 11 years ago |

I love the focus on how the Whitehouse/NSA/FBI sites are vulnerable. Someone could use this to attack the White House!

https://xkcd.com/932/

deathanatos 11 years ago |

> Google’s Chrome browser is not vulnerable to the FREAK bug, but the browser that comes built into most Android devices is vulnerable.

Is this true? Both Chrome on my mobile device and on my laptop show as vulnerable on freakattack.com. Both have outstanding updates[1]; however, if only mean the latest version is not vulnerable, I feel like the message that we need to send the layman is "update, now (and really, always)" not "is not vulnerable"

[1] which Chrome wasn't able to actually download earlier, but all seems good now.

zaroth 11 years ago |

If such a suite was enabled, how would the plethora of SSL testing sites out there have graded it? I assume a passing grade would not have allowed insecure suites such as these to be allowed. Insecure cipher is insecure; that would not typically be worthy of a CVE? It sounds more like even if the suite was not on your accepted list, a MITM could cause the server to downgrade?

This is all OpenSSL has to say about it;

  RSA silently downgrades to EXPORT_RSA [Client] (CVE-2015-0204)
  ==============================================================

  Severity: Low

  An OpenSSL client will accept the use of an RSA temporary key in a non-
  export RSA key exchange ciphersuite. A server could present a weak
  temporary key and downgrade the security of the session.

  This issue affects all current OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8.

  OpenSSL 1.0.1 users should upgrade to 1.0.1k.
  OpenSSL 1.0.0 users should upgrade to 1.0.0p.
  OpenSSL 0.9.8 users should upgrade to 0.9.8zd.

  This issue was reported to OpenSSL on 22nd October 2014 by Karthikeyan
  Bhargavan of the PROSECCO team at INRIA. The fix was developed by Stephen
  Henson of the OpenSSL core team.

I find these notes are usually too curt to really understand what's going on...

Also, that CVE is from Jan 8, 2015, while this is claiming to be a new issue disclosed today. I've seen no mention on the oss-security list of "FREAK", so something is borked with this disclosure if it is a new vulnerability...

netheril96 11 years ago |

> In recent days, FBI.gov and Whitehouse.gov have been fixed, though NSA.gov remains vulnerable, said Green.

Haha, the irony. I guess it now proves to NSA why they are also vulnerable when they mandate backdoors in common software.

RSA silently downgrades to EXPORT_RSA [Client] (CVE-2015-0204) ============================================================== Severity: Low An OpenSSL client will accept the use of an RSA temporary key in a non- export RSA key exchange ciphersuite. A server could present a weak temporary key and downgrade the security of the session. This issue affects all current OpenSSL versions: 1.0.1, 1.0.0 and 0.9.8. OpenSSL 1.0.1 users should upgrade to 1.0.1k. OpenSSL 1.0.0 users should upgrade to 1.0.0p. OpenSSL 0.9.8 users should upgrade to 0.9.8zd. This issue was reported to OpenSSL on 22nd October 2014 by Karthikeyan Bhargavan of the PROSECCO team at INRIA. The fix was developed by Stephen Henson of the OpenSSL core team.