UPDATE 06/03/2015 – Microsoft have released a statement that their Secure Channel (Schannel) SSL implementation is vulnerable to the FREAK attack across all implementation of Microsoft Windows. You can find details on the Microsoft advisory here: https://technet.microsoft.com/en-us/library/security/3046015
It’s been less than two weeks since we were here last, telling tales of woe about SSL Man-in-the-Middle attacks that leaves all your data open for malicious users to view, and lookie, here we are again.
Let me set the scene for you; it’s the 1990s, and crypto for the masses is on the rise; not least of which is PGP for your emails and Netscape Corporation conjuring up SSL, as a means of encrypting data for secure communication.
The US government, now unable to read everyone’s shopping list, decrees that strong encryption is a munition, and any encryption systems exported from the US must utilise deliberately weakened encryption keys . In the case of RSA encryption, this specified that the key length must not exceed 512 bits.
Yup that’s right, these were specifically engineered to be breakable. (Cue legions of activists travelling from the US with the PGP source code tattooed on their body parts).
As of course as we are aware, SSL performs a negotiation to allow clients capable of stronger encryption methods to use those over the weaker ones. US clients connected to the servers with strong ciphers – everyone else used the weakened ‘Export’ grade ciphers, and had to put up with the NSA knowing their favourite breakfast cereal.
Roll on the end of the 90s and early 00s, the export restrictions are lifted and ‘secure’ SSL comes to us all (well, mostly all), so surely these weak ciphers are all disabled and removed by software updates into non-existence right?……Sure.
So these are old and broken ciphers, and we now have a negotiation process that prefers stronger and secure ciphers, so what’s the issue? Only those who can’t use proper crypto would be victims, right? The masses in the still taboo countries on the restricted list, and a few million corporate users browsing their Internet banking from work on IE6.
So, given that (in theory) no modern clients would ask for export ciphers, and no servers should support them, and cryptanalysis is haaaaard, there shouldn’t be a problem.
So let’s jump into these points, starting maybe a bit unusually with the second point, that the number of servers actually supporting Export grade cipher suites is very small. Details emerging today show that over the IPv4 address space, 26.3% (at time of writing) supported at least one RSA-Export grade Cipher Suite.
The excellent blog article by Matthew Green identifies a number of interesting (worrying) sites supporting EXP ciphers, including notable content providers (presumably to avoid support calls when people couldn’t access their customers’ sites using archaic browsers).
Other notable sites included nsa.gov, tips.fbi.gov and connect.facebook.net. The latter of these is the source of the well-known Facebook ‘like’ button which is on SSL Sites all over the world, MITM that connection and you have injection opportunities almost everywhere… just one example.
Ok so that’s point two sorted, lets backtrack and check out point one again, thanks to the wonderful research done at INRIA, Microsoft Research and IMDEA we know that there is a bug in several modern TLS clients, namely OpenSSL and SecureTransport (Apple). This bug allows the client to accept a response containing an RSA-Export key, regardless of the RSA grade initially requested. So presuming you can sit between a vulnerable client and a server that will serve an Export-grade cipher, this can be used to effectively downgrade an SSL communication to its lowest level.
Suppose you’re in the position to perform a MITM attack, you’ve got a vulnerable client and a server that will support RSA-Export, what is the workflow here, how does the attack work?
Well here’s how Matthew Green describes it, in excellent terms:
- In the client’s Hello message, it asks for a standard ‘RSA’ ciphersuite.
- The MITM attacker changes this message to ask for ‘export RSA’.
- The server responds with a 512-bit export RSA key, signed with its long-term key.
- The client accepts this weak key due to the OpenSSL/SecureTransport bug.
- The attacker factors the RSA modulus to recover the corresponding RSA decryption key.
- When the client encrypts the ‘pre-master secret’ to the server, the attacker can now decrypt it to recover the TLS ‘master secret’.
- From here on out, the attacker sees plaintext and can inject anything it wants.
Hey it’s not all bad, at least the attacker is going to have to factor the RSA key for every connection which is going to make this one heck of a tedious attack to perform…..
Generating an RSA key is a fairly complex process, uses a notable amount of system resources while it’s being done, so what do the majority of web servers do to counter this problem? Well they just generate one, and re-use it. See the problem?
Break it once and you’re golden until the server goes down and a new key is generated.
Ok… Now what?
OpenSSL has very quietly released a patch in the latest version that corrects this. Apple is ‘working on it’ and the big CDNs such as Akamai are rolling out patches to remove the Export grade ciphers. Facebooks are gone, who knows what the NSA and FBI are doing.
The conclusions for this are fairly straightforward, upgrade your clients where possible, patch your servers, and purge RSA-Export from the internet.
And you Mr G-Man lurking in the corner, learn from your mistakes, stop trying to build backdoors into encryption before it bites you (and us) in the ass……again.