LogJam Exposed: 575 Cloud Services Potentially Vulnerable to Man-in-the-Middle Attacks

By Sekhar Sarukkai, VP of Engineering, Skyhigh Networks

LogJam, the latest in a spate of web vulnerabilities, was exposed on Tuesday evening by a team including Mathew Green, assistant research professor at Johns Hopkins University, experts from University of Michigan and the University of Pennsylvania, and researchers from Microsoft Research and INRA, who were part of the team that initially discovered the FREAK vulnerability. The vulnerability, which is derived from an encryption flaw, is closely related to the FREAK vulnerability which was exposed on March 4, 2015.

How does LogJam work?

Specifically, any servers that support export grade DHE cipher suits are vulnerable to LogJam. This is a subset of FREAK, though in FREAK all export grade ciphers were counted against vulnerabilities. Additionally, if the server supports export grade DHE ciphers and uses a key less than 1024-bit, then it is computationally easy to break private keys as DH uses a known set of prime numbers to derive its private key. Web browsers also support 512 bit keys for encryption. If both the browser and server support 512-bit key encryption, a man-in-the-middle can force the browser to use a weak key. Most VPN (IKEv1 support) devices use 1024-bit keys, which can be easily broken by state sponsored resources. According to tests 61% of VPN devices are vulnerable, as opposed to only 8.4% of HTTPS servers.

Further, the researchers that exposed LogJam show that, “the computation against the most common 512-bit prime used for TLS demonstrates that the Logjam attack can be used to downgrade connections to 80% of TLS DHE EXPORT servers. We further estimate that an academic team can break a 768-bit prime and that a nation-state can break a 1024-bit prime. Breaking the single, most common 1024-bit prime used by web servers would allow passive eavesdropping on connections to 18% of the Top 1 Million HTTPS domains. A second prime would allow passive decryption of connections to 66% of VPN servers and 26% of SSH servers.” (https://weakdh.org/)

How widespread is LogJam?

Security researchers have focused on tracking vulnerable websites. The number of vulnerable sites is less than those vulnerable to FREAK upon its publication. This is due to the fact that websites and services that applied the FREAK patch also removed the yet-to-be surfaced LogJam vulnerability. As of Tuesday at 10pm PDT, 3.4% of browser trusted sites were vulnerable to LogJam, as opposed to 36.7% for FREAK on the day of its exposure, and 8.4% of the Alexa’s top 1M were vulnerable to Logjam, as opposed to 9.7% for FREAK on the day of its exposure. (Note – this website is not vulnerable). For the latest website vulnerability metrics, check https://weakdh.org/.

As a cloud security and enablement company, we’re focused on detailing how this vulnerability affects cloud services and helping enterprises manage their IT security response so they can protect their data and users. We’ll share stats on potentially vulnerable cloud services below and offer steps security teams should take to protect themselves.

How does a LogJam-enabled man-in-the-middle attack work?

The LogJam vulnerability enables man-in-the middle attacks. The attack would occur as follows:

• In the client’s Hello message, it asks for a standard ‘DH’ ciphersuite.
• The MITM attacker changes this message to ask for ‘export DH’.
• The server responds with a 512-bit export DH key, signed with its long-term key.
• The client accepts this weak key due to the OpenSSL/Secure Transport bug.
• The attacker factors the DH modulus to recover the corresponding DH 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.

575 cloud services potentially vulnerable to LogJam

Skyhigh’s Service Intelligence Team monitors security breaches and vulnerabilities,including the LogJam vulnerability, across thousands of cloud providers. Six hours after the vulnerability was officially publicized, 575 cloud providers remain potentially vulnerable.

With the average company using 923 cloud services, the chances that an organization uses one or more vulnerable services is high. Across the 400+ enterprises using Skyhigh, 99% are using at least one cloud service that is potentially vulnerable, and the average enterprise uses 71 vulnerable services. We will continue to track these vulnerable services and work with customers to diagnose and remediate their vulnerabilities.

Eliminating the LogJam vulnerability for cloud services

To patch the vulnerability, cloud providers should disable support for export suites, deploy elliptic-curve Diffie Hellman, and generate a strong, unique Diffie Hellman Group. For specific details, visit: https://weakdh.org/sysadmin.html.

Protecting your company from LogJam

Organization must determine and contain both their client-side and service-side exposure. Skyhigh is contacting each of the cloud providers affected to ensure they are aware of their vulnerability and perform the required steps towards remediation. We‘re also informing our customers who use potentially vulnerable services. Here are 5 steps to protect your company from LogJam:

1. Contain your client-side exposure: Require that employees use only browser versions that are not vulnerable (i.e. patched versions of Chrome, Firefox, IE).
2. Determine your service-side exposure: Skyhigh informs customers of the potentially vulnerable cloud services in use at their organization. If you’d like to look up an individual service to see if it’s vulnerable, visit: https://tools.keycdn.com/freak (If they have applied the FREAK patch, the service has eliminated the LogJam Vulnerability, as well).
3. Validate your proxy configurations: If 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 the enterprise is updated: If not careful, external facing sites may be fixed first while internal sites/development environments are never fixed. Ensure that you don’t neglect internal deployments as well.
5. Update your VPN Server: VPN servers that support IKEv1 protocol for encryption should be updated to disable any keysize less than 1024 bits – or better yet, use elliptical curve keys. Organizations should also consider using SSL VPN technology, which is better supported as its underlying OpenSSL is updated regularly against various encryption protocol vulnerabilities.