24 Hours After FREAK, 766 Cloud Providers Still Vulnerable
Blog Article Published: 03/06/2015
The Average Company Uses 122 FREAK-vulnerable services By Sekhar Sarukkai, Co-founder and VP of Engineering, Skyhigh Networks This week a group of researchers at INRA, Microsoft Reseach, and IMDEA discovered a widespread vulnerability in OpenSSL that has rendered millions of Apple and Android devices vulnerable to man-in-the-middle attacks when they visited supposedly secure websites and cloud services. You can read the detailed description of the vulnerability from the discovering researchers here. The researchers have dubbed this the “FREAK” vulnerability (CVE-2015-0204) or Factoring Attack on RSA-EXPORT Keys, and it enables attackers to force clients to use older, weaker encryption , known as the “export-grade” key or 512-bit RSA keys. Currently, the media have focused on tracking vulnerable websites and highlighting specific sites, such as the White House, FBI, and NSA that suffered from the vulnerability. As of Wednesday at 12PM PST, 36.7% of browser-trusted sites, 26.3% of Full IPv4, and 9.7% of Alexa’s top 1M domains were vulnerable (Note – this website is not vulnerable). For the latest website vulnerability metrics, check https://freakattack.com/ Naturally, here at Skyhigh we’re most concerned with identifying and tracking vulnerable cloud services and helping enterprises manage their IT Security response and protect their users and data. Below we’ll share the latest data on cloud service vulnerabilities and share the security steps organizations must take to protect themselves. You can read our detailed advice on how to protect corporate cloud data from FREAK here. First, a little background (why is their “export grade” security anyway?) In the 1990’s Netscape developed an SSL technology that was widely used to protect credit card transactions using public key cryptography. However, US policy required the creation of an intentionally weakened version of the technology and dictated that a maximum key length of 512 bits would be permitted for “export-grade” encryption. The idea was that, with 512-bit encryption, the NSA would have the ability to access communications, while theoretically providing crypto that was still good enough for commercial use. And now, despite the fact that these export restrictions have been modified or lifted, “export-grade” cryptography support was never removed, so many devices can be tricked into accepting the lowest “export-grade” encryption, opening them up to man-in-the-middle attacks. How does the man-in-the-middle attack work? Mathew Green, a research professor at Johns Hopkins Information Security Institute, has a simply stated (and widely cited) description of how the FREAK-enabled man-in-the-middle attack works:
- 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/Secure Transport 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 plain text and can inject anything it wants.
- Determine your service-side exposure: Skyhigh automatically alerted customers to services they use that are affected by FREAK. If you’d like to identify all the affected services in use at your company for free, email [email protected]. If you’d like to look up an individual service to see if it’s vulnerable, visit: https://tools.keycdn.com/freak
- Contain your client-side exposure: Ensure that only browser versions that are not susceptible (Chrome, or later versions of IE & Firefox for example). If employees use unmanaged BYOD devices, educate them on the current safe browser list at http://www.computerworld.com/article/2892926/time-to-freak-out-how-to-tell-if-youre-vulnerable.html
- Validate proxy configurations: If you manage your enterprise network and your enterprise uses a MITM proxy (like a web proxy) ensure that the configurations are properly set so it does not degrade.
- Ensure any OpenSSL use within enterprise is updated: If not careful, external facing sites may be fixed first and internal sites/development environments never. Ensure that you don’t take your eye off internal deployments, as well.