IBM Blocks ‘Bar Mitzvah’ Attack In SSL/TLS
April 27, 2015 Alex Woodie
IBM recently issued a security bulletin for a newly discovered security vulnerability–a weak cryptography algorithm in the SSL/TLS protocol stack–that could allow hackers to steal data. That vulnerability was dubbed the “Bar Mitzvah Attack” by the security researcher who discovered it because it uses a 13-year-old weakness in the RC4 algorithm. The Bar Mitzvah flaw was first described by Itsik Mantin, director of security research with Imperva, at the Black Hat Asia security event held in Singapore last month. The attack stems from a weakness in the way that the RC4 stream cipher creates encryption keys, which could allow an attacker to recover plain text from the encrypted information. According to Mantin’s description, the Bar Mitzvah attack rides atop Invariance Weakness, “a 13-year-old vulnerability of RC4 that is based on huge classes of RC4 weak keys.” Mantin demonstrates how the vulnerability “can be used to mount several partial plaintext recovery attacks on SSL-protected data when RC4 is the cipher of choice, recovering part of secrets such as session cookies, passwords, and credit card numbers.” Despite the well-known problems with the RC4 cipher, it is still used to protect 30 percent of SSL traffic, Mantin says, “likely amounting to billions of TLS connections every day.” (TLS refers to a more advanced version of Secure Sockets Layer encryption, and is essentially a new name for SSL.) It’s not known if any hackers are actively exploiting the Bar Mitzvah attack that Mantin described, but it’s clear that it’s time to stop using RC4. That’s exactly what IBM recommends doing in its security bulletin on the matter. Instead of issuing a patch or a PTF that removes RC4 from the various SSL/TLS implementations on IBM i, IBM’s workaround recommends disabling RC4. IBM i administrators will want to follow IBM’s instructions carefully to ensure that all traces of the RC4 algorithm are removed from their system. There are no fewer than four SSL/TLS implementations in common IBM system libraries alone, including IBM i System SSL, OpenSSL in PASE, the default Java implementation called IBMJSSE, and another for Domino. Third-party products, such as terminal emulators or file transfer tools, may use System SSL or one of the other implementations, or they may use others, IBM says. Ripping out the RC4 ciphers and replacing them with more modern AES cipher suites won’t necessarily be easy, and some applications may stop working without them. In those cases, customers must make a determination whether it is worth using that application with the known security issue until they can replace the weak ciphers with strong ones, or replace the product altogether. There is no easy way to determine which applications use RC4–a trace active at the time the security connation is made is required, IBM says. The Bar Mitzvah attack doesn’t appear to be as devastating as last year’s Heartbleed vulnerability in OpenSSL or the POODLE attack that appeared a few months later (in fact there were dozens of new vulnerabilities in TLS/SSL stack discovered last year, Mantin says). But administrators should take immediate action to fix the problem anyway. IBM says that all supported versions of IBM i, from version 6.1 to 7.2, are potentially impacted by the gangly pubescent pupil. But in reality, any Power System, System i, iSeries, or AS/400 server put into service since 2001, and which uses SSL/TLS to secure communications over the Internet, is vulnerable to the Bar Mitzvah attack. RELATED STORIES IBM Patches BIND and OpenSSL Flaws in IBM i IBM And ISVs Fight POODLE Vulnerability In SSL 3.0 Heartbleed Exposes The Vulnerability Of An IBM i Mentality IBM Patches Heartbleed Vulnerability in Power Systems Firmware Heartbleed Postmortem: Time to Rethink Open Source Security?
|