In the early days of the Internet, the US government did not allow the export of strong encryption algorithms outside of the United States. Only weak encryption techniques were allowed for export, so-called “export-grade” encryption, which allowed a maximum RSA key size of 512 bits, making them easy to crack.
The SSL protocol was designed so that US-based servers could handle both strong and weak encryption. The protocol uses a clever negotiation mechanism that allows the client and server to agree on the strongest cipher supported by both. This mechanism allowed US-based browsers to support strong encryption, while non-US browsers used a more weakly encrypted communications link.
These restrictions were removed in the late 1990’s, but the weaker encryption has remained in some cryptographic libraries (older versions of OpenSSL, Microsoft’s Schannel TLS library, and Apple’s SecureTransport).
Recently, a team of researchers found that they could do a protocol degradation attack and force a browser to use the weaker encryption. Using cloud computing, they were able to crack the encryption in about 8 hours and for a cost of about $100.
Once the research team had the encryption keys, they could do “Man-in-the-Middle” (MITM) attacks to capture, read, and even modify “encrypted” communications between the victim and the website.
This vulnerability is called “FREAK” for Factoring Attack on RSA-Export Keys
Threat assessment
Man-in-the-Middle attacks are rather common. Just a couple of weeks ago, it was discovered that some Lenovo laptops had pre-installed software which installed a self-signed root certificate that intercepted encrypted traffic (MITM) from every HTTPS site visited by the user.
Researchers at the University of Michigan recently surveyed encrypted websites and found about one third of the 14 million sites surveyed are vulnerable to FREAK.
The following browsers are also vulnerable to the attack:
- Android browser (a patch has been developed, but it could take a while to get deployed to millions of phones)
- Internet Explorer and Windows software that uses the Schannel library
- Safari
Firefox and Google Chrome are not vulnerable.
Root Cause
The affected SSL libraries have a bug that allows the client to accept the weak RSA keys even when the client didn’t ask for export- grade RSA. As a result, an attacker doing a MITM attack can force the connection to use the weaker protocol if the server supports the weaker RSA and the client is vulnerable. The attacker is then able to recover the corresponding RSA decryption key by performing some heavy mathematics. The recovered key is ultimately used to give the attacker the ability to decrypt the encrypted traffic to and from the site.
Even in implementations where the export-grade ciphers are disabled, security defects in some implementations allow the weaker cipher suite to be used, despite having negotiated a non-export cipher suite.
Impact
A number of high profile sites are impacted, including government and banking sites. Many content distribution networks (CDN) are also impacted.
It gets worse…
…Because RSA key generation is expensive, web servers do not generate a new key with each connection.
For example, Apache mod_ssl generates a key when the server starts and re-uses it until the server shuts down. The security implication is frightening – once the RSA key for a site is discovered by an attacker, he can break every session on that server as long as he can MITM the session.
Many websites use third-party JavaScript. For example, the Facebook “Like” button found on many sites uses JavaScript from the vulnerable site, connect.facebook.net. After factoring the RSA modulus, an attacker could impersonate servers that host JavaScript, and then inject malicious JavaScript into the sites that use the Facebook “Like” JavaScript code. The malicious JavaScript could even be used to conduct Cross Site Scripting attacks to steal credentials.
Prevention
- Test to see if your webserver is vulnerable with the SSL FREAK Check CVE-2015-0204. While you are checking for FREAK, consider doing a full SSL check.
- Disable support for any export suites and all known insecure ciphers.
- See the Mozilla recommended server TLS configuration settings guidance and the Mozilla SSL Configuration Generator which can help with securing the server side.
- Use TEAM Mentor coding standards to ensure the proper use of cryptography:
Lessons Learned
- Cryptography is hard to do right. And even when it is done right (mathematically), many software implementations still are done incorrectly. Heartbleed is another recent example of this.
- Reduce attack surface to improve your security stance. Minimize privileges, minimize the amount and kinds of private data collected, and minimize cryptographic protocols that might be out of date, no longer used, or even vulnerable.
- Periodically assess your systems. Not only conducting security code reviews, penetration tests, and vulnerability assessments, but also consider the bigger picture: Is the system adequately configured? From a cryptographic perspective: are the protocols and algorithms current? Is it necessary to support really old browsers that could be vulnerable?
- Trust is also hard to do. Consider the third-party software (modules, libraries, frameworks, etc.) that are part of your application. Are these components current? Have they been evaluated from a security perspective? Are you trusting that they are “secure”? What is the impact to your application if these components are vulnerable?
