All You Need To Know About POODLE Vulnerability

Today, Google announced a vulnerability in the implementation of the SSL 3.0 protocol potentially compromising secure connections online. POODLE (Padding Oracle on Downgraded Legacy Encryption) is a new security hole in Secure Socket Layer (SSL) 3.0 that makes the 15-year-old protocol nearly impossible to use safely. The “Poodle” is a protocol flaw, not an implementation issue; every implementation of SSL 3.0 suffers from it. The TLS versions are not affected (neither is DTLS).

The Poodle attack works in a chosen plaintext context. The attacker is interested in data that gets protected with SSL, and he can:

1)      Inject data of his own before and after the secret value that he wants to obtain;

2)      Inspect, intercept and modify the resulting bytes on the wire.

The main and about only plausible scenario where such conditions are met is a Web context: the attacker runs a fake WiFi access point and injects some Javascript of his own as part of a Web page (HTTP, not HTTPS) that the victim browses. The evil Javascript makes the browser send requests to an HTTPS site (say, a bank Web site) for which the victim’s browser has a cookie. The attacker wants that cookie. The attack proceeds byte-by-byte. The attacker’s Javascript arranges for the request to be such that the last cookie byte occurs at the end of an encryption block (one of the 8-byte blocks of 3DES) and such that the total request length implies full-block padding.

Can You Detect Poodle Attacks on Your Network?

You don’t! Since the most probable attack setup involves the attacker luring the victim on his network, not yours.

Although, on the server-side, you may want to react to an inordinate amount of requests that fail on a decryption error. Not all server software will log events for such cases, but this should be within the possibilities of any decent IDS system.

Recommendations by Google:

The attack described above requires an SSL 3.0 connection to be established, so disabling the SSL 3.0 protocol in the client or in the server (or both) will completely avoid it. If either side supports only SSL 3.0, then all hope is gone, and a serious update required to avoid insecure encryption. If SSL 3.0 is neither disabled nor the only possible protocol version, then the attack is possible if the client uses a downgrade dance for interoperability.

Disabling SSL 3.0 entirely right away may not be practical if it is needed occasionally to work with legacy systems. Also, similar protocol version downgrades are still a concern with newer protocol versions (although not nearly as severe as with SSL 3.0).

The TLS_FALLBACK_SCSV mechanism from [draft­ietf­tls­downgrade­scsv­00] addresses the broader issue across protocol versions, and we consider it crucial especially for systems that maintain SSL 3.0 compatibility.

The following recommendations summarize how TLS_FALLBACK_SCSV works:

TLS clients that use a downgrade dance to improve interoperability should include the value 0x56, 0x00 (TLS_FALLBACK_SCSV) in ClientHello.cipher_suites in any fallback handshakes. This value serves as a signal allowing updated servers to reject the connection in case of a downgrade attack. Clients should always fall back to the next lower version (if starting at TLS 1.2, try TLS 1.1 next, then TLS 1.0, then SSL 3.0) because skipping a protocol version forgoes its better security. (With TLS_FALLBACK_SCSV, skipping a version also could entirely prevent a successful handshake if it happens to be the version that should be used with the server in question.) In TLS servers, whenever an incoming connection includes 0x56, 0x00 (TLS_FALLBACK_SCSV) in ClientHello.cipher_suites, compare ClientHello.client_version to the highest protocol version supported by the server. If the server supports a version higher than the one indicated by the client, reject the connection with a fatal alert (preferably, inappropriate fallback (86) from [draft­ietf­tls­downgrade­scsv­00]).

This use of TLS_FALLBACK_SCSV will ensure that SSL 3.0 is used only when a legacy implementation is involved: attackers can no longer force a protocol downgrade. (Attacks remain possible if both parties allow SSL 3.0 but one of them is not updated to support TLS_FALLBACK_SCSV, provided that the client implements a downgrade dance down to SSL 3.0.)

Stay tuned for more relevant and interesting security articles. Follow Indusface on Facebook, Twitter, and LinkedIn.