March 6th, 2015
Back in early 90’s in the US was illegal to export strong crypto code. Sending crypto code overseas was considered something similar to export weapons. At that time the
NSA and the US government banned people from selling software to other countries unless the code used involved encryption keys no longer than 512 bits.
The idea was to export weak encryption to the rest of the world to keep the stronger stuff at home.
Although this restrictions were removed long time ago, some
TLS/SSL implementations still support these 90’s ciphers.
Last Tuesday security researchers found a vulnerability on some
TLS/SSL implementations that allows an attacker to force clients and servers connecting over HTTPS to use these weakened encryption mechanisms, which the attacker can break to steal or manipulate sensitive data like session cookies or credentials.
Is this critical? Well, let me put it in this way: Microsoft just said that All windows versions are vulnerable. This means if you’re using Windows, an attacker on your network can potentially force Internet Explorer and other software using the Windows Secure Channel component to use weak encryption over the web and capture your credentials, cookie sessions or any other sensitive information.
How does it work?
If you want to know more about the attack, here is a very detailed analysis of it http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-or-factoring-nsa.html, but roughly, this is how it works:
1. In the client’s Hello message, it asks for a standard ‘RSA’ ciphersuite.
2. The MITM attacker changes this message to ask for ‘export RSA’.
3. The server responds with a 512-bit export RSA key, signed with its long-term key.
4. The client accepts this weak key due to the OpenSSL/SecureTransport bug.
5. The attacker factors the RSA modulus to recover the corresponding RSA decryption key.
6. When the client encrypts the ‘pre-master secret’ to the server, the attacker can now decrypt it to recover the TLS ‘master secret’.
7. From here on out, the attacker sees plaintext and can inject anything it wants.
Who is vulnerable?
FREAK (Factoring RSA Export Keys) attack is possible when both, client and server, are vulnerable.
From clients perspective seems that many major browsers in all major platforms are vulnerable. As I said before couple of hours ago Microsoft published this article saying that All versions of Windows are vulnerable with no patch yet. Also SecureTransport library used by the Safari web browser on iPhones, iPads and OS X Macs, and OpenSSL by Android browsers are also vulnerable implementations. Have in mind that this doesn’t only affects to browsers, but also native apps using vulnerable TLS libraries.
This is the list of known vulnerable browsers:
Internet Explorer (All versions)
Chrome on Mac OS (Patch available now)
Chrome on Android
Safari on Mac OS (Patch expected next week)
Safari on iOS (Patch expected next week)
Stock Android Browser
You can check if your client is vulnerable here: https://freakattack.com/clienttest.html
From servers, any server supporting
RSA_EXPORT cipher suites is potentially vulnerable. Almost any popular webserver Nginx, Apache, IIS, etc may be vulnerable depending of its configuration, so if you are running a webserver you must disable export ciphers asap.
Node.js v0.10.36, v0.12 and io.js are not vulnerable since they use a version of OpenSSL that is more recent and in which the vulnerability was fixed, unfortunately in older versions (0.10.35 and older, including all versions of v0.8.x) the TLS client uses default OpenSSL cipher suites, which makes them vulnerable (of course you can always limit the ciphers when creating the TLS createServer)
You can test your server using this online tool: https://tools.keycdn.com/freak