24 Hours After FREAK, 766 Cloud Providers Still Vulnerable

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.

How many cloud services are vulnerable?

Skyhigh’s Service Intelligence Team tracks vulnerabilities and security breaches across thousands of cloud providers, including the FREAK vulnerability. Almost 24 hours after the vulnerability was widely publicized, 766 cloud providers are still not patched, making them vulnerable to attack. These services include some of the leading backup, HR, security, collaboration, CRM, ERP, cloud storage, and backup services.

The average company uses 897 cloud services, making the likelihood they use at least one affected service extremely high. Across over 350 companies using Skyhigh, 99% are using at least one cloud provider that is still not patched and the average company uses 122 vulnerable services. We’ll continue tracking these services, working with customers to diagnose and remediate vulnerabilities and provide updates as cloud services are patched.

Here’s how to eliminate the FREAK vulnerability from your cloud service

In order to close the vulnerability, cloud providers should disable support for export suites. Rather than excluding RSA export cipher suites, administrators should disable support for all known ciphers and enable forward secrecy. Mozilla published a guide here, and a SSL Configuration Generator, which will provide good certifications for common servers.

Here’s how to protect your company from FREAK

Enterprises need to determine and contain both their service-side and client-side exposure. Skyhigh has contacted each of the cloud providers affected and is working with them to ensure they are aware of their vulnerability and perform remediation. We've also alerted our customers who use affected services.

There are 4 steps that every company needs to take in response to FREAK:

1. 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
2. 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
3. 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.
4. 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.