
Major security flaw undermines Apple and Google users, researchers discover - derekjobst
http://www.washingtonpost.com/blogs/the-switch/wp/2015/03/03/freak-flaw-undermines-security-for-apple-and-google-users-researchers-discover/
======
Kronopath
This news story is way too light on details for this audience. A better
description of the vulnerability is here:
[https://www.freakattack.com/](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
Something is odd with that site. If I enter
[https://www.freakattack.com](https://www.freakattack.com) it reports Safari
5.1.10 as safe from the attack. If I simply enter
[https://freakattack.com](https://freakattack.com) it reports it as
vulnerable.

------
AnimalMuppet
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
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!

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

~~~
rogerbinns
It was more akin to a self signed certificate, but also more complicated
depending on domain setup. But also things changed a lot between RDP protocol
versions.

It did take me quite a while to reverse engineer the encryption. It was mostly
done using IDA Pro and SoftIce. The hardest bit was because I had several
crypto books, and whichever Microsoft employee implemented their security kept
doing what the books said not to do, so I'd never expect to keep encountering
the "wrong" way of doing things.

[https://www.hex-rays.com/products/ida/index.shtml](https://www.hex-
rays.com/products/ida/index.shtml)

[https://en.wikipedia.org/wiki/SoftICE](https://en.wikipedia.org/wiki/SoftICE)

~~~
yuhong
[http://www.rapid7.com/db/vulnerabilities/windows-rdp-
constan...](http://www.rapid7.com/db/vulnerabilities/windows-rdp-constant-key-
mitm)

I think the newer RDP versions uses TLS BTW.

~~~
rogerbinns
I did the reverse engineering on RDP 4, almost 10 years before that
vulnerability report. With each RDP release they did very big changes to the
security layer as well as other pieces. Somewhat surprisingly Microsoft did
base RDP on open standards, especially a whole bunch around video messaging.

But those standards were developed by committee, so the number of ways you
could do things was usually the same as the number of committee members. Then
their implementation had bugs (eg drawing some parts from bottom to top when
the standards said top to bottom), but they didn't know this since they didn't
try interoperating with other implementations. The initial "security" was some
half assed hack, and yes in later versions they did switch to TLS.

Note that the security is complicated because of domain membership, WAN vs
LAN, and a bunch of other related issues.

------
rbanffy
If [http://dualec.org/DualECTLS.pdf](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
Safari and Android browsers are vulnerable.

[http://blog.cryptographyengineering.com/2015/03/attack-of-
we...](http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-
or-factoring-nsa.html)

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

------
nmc
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](https://www.smacktls.com)

------
yuhong
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...](https://tools.ietf.org/html/draft-ietf-tls-56-bit-
ciphersuites-01) . And for the record it was in year 2000 that the
restrictions was removed for "retail" software.

------
MBlume
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/](https://xkcd.com/932/)

------
deathanatos
> 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
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
> 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.

