"Let’s Get Ready to Logjam!" -- The Need to Know About This New Exploit

Bill Malchisky  May 22 2015 12:35:00 AM

Logjam (CVE-2015-4000) is the latest server exploit hitting the nation (world). In scope are 8.4x10**3 of the top 1x10**6 websites and 14.8% of mail servers in the IPv4 address space as per weakdh.org. The cause is a weakness identified in the Diffie-Hellman key exchange (explained here and here), with the exploit reported early by Ars Technica.

The root cause goes back to the 1990's. Recall when products like Lotus Notes had a North American encryption flavor and an International encryption flavor. That ended when encryption standards were lowered and the two offerings merged, for example. It helped the Feds crack encryption overseas, but now average users have incredible computing power available to them cheaply. Thus, algorithms can be broken with significant ease today, that were nearly impossible to do so 20 years ago. I expect more exploits of this nature in the months ahead.

"Logjam shows us once again why it's a terrible idea to deliberately weaken cryptography" -- J. Alex Halderman, a key scientist behind the exploit's research, posted at https://weakdh.org

---

Work-around and a Solution
Initially, server administrators should disable support for DHE_EXPORT ciphersuites, as they downgrade connections of the Diffie-Hellman variety.

The solution for Logjam is akin to POODLE in that TLS is the way to go. Companies like Red Hat and IBM offered TLS solutions for POODLE and the Logjam research team provided a document on how to deploy correctly Diffie-Hellman for TLS.

For your browsers, jscher2000 in Silicon Valley, CA, via a mozillaZine Logjam post offers a four step process to Disable insecure ciphers.
"(1) In a new tab, type or paste about:config in the address bar and press Enter. Click the button promising to be careful.
(2) In the search box above the list, type or paste ssl3 and pause while the list is filtered
(3) Double-click the security.ssl3.dhe_rsa_aes_128_sha preference to switch it from true to false (this usually would be the first item on the list)
(4) Double-click the security.ssl3.dhe_rsa_aes_256_sha preference to switch it from true to false (this usually would be the second item on the list)"
Then, test the success with the Qualys SSL Labs test in the next section.

Paul Farris, earlier this week, wrote a blog post on Domino SSL Ciphers, which is located here.


Establishing your Risk
Clients
Web browsers should be updated shortly (as of this writing). Internet Explorer on Windows 10 was the first to have a patch. Firefox and Chrome are in the works. Check here for clarity. As of this morning (21 May 2015), my browsers were still at risk.


For checking browsers beyond Logjam, Qualys SSL Labs has a browser check here which checks three key vulnerabilities, the protocol support and features plus cipher suites utilized

Servers
The TLS deployment document has a Server Test, which is easy and free to use. Here is the link. Just scroll down to the Server Test section. I tested many known sites and found that many were safe from Logjam style attacks, (which is on-par with the sub-ten percent of sites in scope), they could be further secured with Elliptic-Curve Diffie-Hellman (ECDHE).



They also offer two suggestions for many common application server programs (e.g. Apache, OpenSSH). The researchers also suggest that all your TLS libraries are patched and set to reject D-H Groups < 1024-bit in size.

Checking Servers
More detailed results are available from these two free resources
1. An open source site entitled SSL Decoder is available to decode well as you surmised a site's SSL connection. The output is robust and the licensing allows for use internally, so start testing;
2. Qualys SSL Labs' SSL Server Test - which provides links to additional information on each exploit tested, with several linked resources on each information page.

A side point to know is that DSA-1024 bit signing keys are quite insecure and should be at 2048 or higher, with 4096 recommended where possible. If your keyrings are light on the encryption bits, make a plan to get them upgraded this year.

Notation: Know that the client fix may block some websites lacking current updates. Thus, it is a good idea to ensure that your company site is current on web security patches.


Red Hat to the Rescue
Upon learning of the threat, Red Hat did their own research with threat assessment and published their security bulletin on this exploit. The good news is that RHEL 6.6+ and 7 are NOT vulnerable to Logjam, but if you are running early RHEL6 versions (get them patched -- see advisory RHBA-2014:1525) or RHEL 5, then you are vulnerable. Specifically, RHEL 7 omitted by design export-grade cipher suites in their initial release--offering piece of mind to those that upgraded early.

To their credit, Red Hat made it clear early that they will not update the default cipher list in RHEL 5, so you need to upgrade to at least RHEL 6.6 to be safe. I do like a vendor that gets to the point quickly in an unambiguous manner. Everybody wins with this type of communication, from my perspective.

SUSE has a security bulletin with some information on resolutions, located here.


Additional Reading
Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice -- outlining specific attacks and how the researchers broke the 512-bit DH group
Logjam Attack Proof of Concept Demonstrations -- which lists the susceptibility to each of the three attack styles
Guide to Deploying Diffie-Hellman for TLS
Logjam: TLS vulnerabilities (CVE-2015-4000) by Red Hat
MITRE CVE's Logjam dictionary definition
NIST NVD's entry (National Vulnerability Database)
"Logjam TLS Attack (Weak Diffie-Hellman) and Novell Products"

• Comments [0]