Heartbleed bug reloaded: New web encryption vulnerability found
Posted by: Jon Ben-Mayor on 06/05/2014 12:37 PM
[
Comments
]
Japanese researcher Masashi Kikuchi, discovered an CCS injection vulnerability (CVE-2014-0224) on the heels of the massive Heartbleed bug; the new vulnerability, which has apparently been lying undiscovered for 16 years, (or as far as Kikuchi is concerned, since the very first release of OpenSSL) works by OpenSSL inappropriately accepting ChangeCipherSpec (CCS) during a handshake.
The cryptographic parameters of the session state are produced by the TLS Handshake Protocol, which operates on top of the TLS record layer. When a TLS client and server first start communicating, they agree on a protocol version, select cryptographic algorithms, optionally authenticate each other, and use public-key encryption techniques to generate shared secrets.
The OpenSSL Foundation posted OpenSSL security advisory which explains further; an attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers. This can be exploited by a Man-in-the-middle (MITM) attack where the attacker can decrypt and modify traffic from the attacked client and server.
The attack can only be performed between a vulnerable client *and* server. OpenSSL clients are vulnerable in all versions of OpenSSL. Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution.
OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za.
OpenSSL 1.0.0 SSL/TLS users (client and/or server) should upgrade to 1.0.0m.
OpenSSL 1.0.1 SSL/TLS users (client and/or server) should upgrade to 1.0.1h.
Kikuchi stresses that, ChangeCipherSpec MUST be sent at these positions in the handshake. OpenSSL sends CCS in exact timing itself. However, it accepts CCS at other timings when receiving. Attackers can exploit this behavior so that they can decrypt and/or modify data in the communication channel.
Ashkan Soltani, a privacy researcher who has been involved in analyzing the Snowden NSA leaks for the NSA and closely tracked SSL’s woes, offered this translation to Wired: “Basically, as you and I are establishing a secure connection, an attacker injects a command that fools us to thinking we’re using a ‘private’ password whereas we’re actually using a public one.”
Unlike the Heartbleed flaw, which allowed anyone to directly attack any server using OpenSSL, the attacker exploiting this newly discovered bug would have to be located somewhere between the two computers communicating. But that still leaves open the possibility that anyone from an eavesdropper on your local Starbucks’ network to the NSA to strip away your Web connection’s encryption before it’s even initialized.
The cryptographic parameters of the session state are produced by the TLS Handshake Protocol, which operates on top of the TLS record layer. When a TLS client and server first start communicating, they agree on a protocol version, select cryptographic algorithms, optionally authenticate each other, and use public-key encryption techniques to generate shared secrets.The OpenSSL Foundation posted OpenSSL security advisory which explains further; an attacker using a carefully crafted handshake can force the use of weak keying material in OpenSSL SSL/TLS clients and servers. This can be exploited by a Man-in-the-middle (MITM) attack where the attacker can decrypt and modify traffic from the attacked client and server.
The attack can only be performed between a vulnerable client *and* server. OpenSSL clients are vulnerable in all versions of OpenSSL. Servers are only known to be vulnerable in OpenSSL 1.0.1 and 1.0.2-beta1. Users of OpenSSL servers earlier than 1.0.1 are advised to upgrade as a precaution.
OpenSSL 0.9.8 SSL/TLS users (client and/or server) should upgrade to 0.9.8za.
OpenSSL 1.0.0 SSL/TLS users (client and/or server) should upgrade to 1.0.0m.
OpenSSL 1.0.1 SSL/TLS users (client and/or server) should upgrade to 1.0.1h.
Kikuchi stresses that, ChangeCipherSpec MUST be sent at these positions in the handshake. OpenSSL sends CCS in exact timing itself. However, it accepts CCS at other timings when receiving. Attackers can exploit this behavior so that they can decrypt and/or modify data in the communication channel.
Ashkan Soltani, a privacy researcher who has been involved in analyzing the Snowden NSA leaks for the NSA and closely tracked SSL’s woes, offered this translation to Wired: “Basically, as you and I are establishing a secure connection, an attacker injects a command that fools us to thinking we’re using a ‘private’ password whereas we’re actually using a public one.”
Unlike the Heartbleed flaw, which allowed anyone to directly attack any server using OpenSSL, the attacker exploiting this newly discovered bug would have to be located somewhere between the two computers communicating. But that still leaves open the possibility that anyone from an eavesdropper on your local Starbucks’ network to the NSA to strip away your Web connection’s encryption before it’s even initialized.
Comments
