POODLE and The Curse of Backwards Compatibility
This post was written by Martin Lee
Old protocol versions are a fact of life. When a new improved protocol is released, products still need to support the old version for backwards compatibility. If previous versions contain weaknesses in security, yet their continued support is mandated, then security can become a major issue when a potential weakness is discovered to be a genuine vulnerability and an exploit is released.
The Transport Layer Security (TLS) protocol defines how systems can exchange data securely. The current version 1.2 dates from August 2008, however the protocol’s origins lie in the Secure Sockets Layer (SSL) standard first published in February 1995. As weaknesses in the cryptography and flaws in the protocol design were discovered, new versions of the protocol were released.
In order to maintain interoperability the most recent TLS standard requires that systems support previous versions down to SSL 3.0. The discovery of a cryptographic weakness in SSL 3.0 and the publication of an attack that can exploit this provide attackers with a means to attack TLS implementations by intercepting communications using the old SSL 3.0 protocol.
The vulnerability, assigned the Common Vulnerability and Exposure ID CVE-2014-3566, and referred to as POODLE, allows an attacker to modify the padding bytes that are inserted into SSL packets to ensure that they are of the correct length and replay modified packets to a system in order to identify the bytes within a message, one by one. This allows an attacker to discover the values of cookies used to authenticate https secured web sessions. Nevertheless, the vulnerability potentially affects any application that secures traffic using TLS, not only https traffic.
In practice, the attacker would need to be able to intercept communications between a client and a server, possibly as part of a man-in-the-middle attack in order to exploit the weakness. This restriction means that this bug is far less significant than Heartbleed or Shellshock which permit attackers to remotely exploit the vulnerability.
Web browser are likely to support backwards compatibility and should be considered to be vulnerable to the attack.This vulnerability is another reason to be wary of public wi-fi networks where malicious actors may be capturing or interfering with traffic. Where possible browsing should be conducted over a secure VPN connection that ensures the confidentiality and integrity of traffic.
The TLS standard has already been amended to prohibit communications using SSL 2.0. With the publication of this attack, it is certain that the TLS standard will be subsequently amended to prohibit communications using SSL 3.0. In the meantime, organisations can disable the use of SSL 3.0 on clients and servers in order to mitigate against the attack. NGFW and IPS implementations can detect and block malicious network packets.
Protecting Users Against These Threats
The malware detecting capabilities of Advanced Malware Protection (AMP) are not applicable to this threat.
The Network Security protection of IPS and NGFW have up-to-date signatures to detect such malicious network activity. Snort signature IDs 32204 and 32205 have been released to detect exploitation of the vulnerability. Cisco IPS signature 4743-0 detects SSL 3.0 activity.
The email protection of ESA is not applicable to this threat.
Cisco have created an Event Response Page for this threat, available here.