What is POODLE?
With Google disclosing the POODLE vulnerability in SSL v3, we are now witnessing version 3’s last days. Unlike other SSL vulnerabilities, such as BEAST and LUCKY 13, POODLE has no patch or workaround-the v3 protocol itself is broken. Connections using CBC ciphers are insecure, enabling attackers to extract sensitive data from them.
In Google’s paper, their vulnerability researchers reveal how an attacker can extract data, ostensibly encrypted from SSL v3 connections using CBC ciphers. They also provide an example of how a real-world attack might take place, resulting in session cookies being stolen.
The bottom line is that attackers with access to client or server environments can manipulate clients to use insecure SSL v3 connections. They then use v3 weaknesses to extract sensitive data from the stream.
Which systems could be affected?
Basically any client and server supporting SSL v3.
What are the security consequences?
In a nutshell, access to any data sent over an encrypted connection. The Google paper suggests client cookies as an example, but POODLE can potentially lead to exposure of other personal data such as email addresses, passwords, and credit card numbers-the very things SSL was designed to protect.
How does POODLE compare to Heartbleed and Shellshock?
Heartbleed and Shellshock attackers only need public internet access to a vulnerable environment in order to exploit a system. Simply sending an HTTP request is sufficient.
Shellshock has the highest impact, for it allows complete compromise of a server environment. Heartbleed and POODLE, by contrast, can expose sensitive data. With Heartbleed, this data relates both to client and server (e.g., private keys). POODLE mostly exposes client data, such as a credit card number entered in an online shopping cart form.
In exploitability terms, POODLE is much less severe than Heartbleed and Shellshock. This is because an attacker needs some level of network access to the client or server environment to carry out a man-in-the-middle attack. A man-in-the-middle attack is a form of active eavesdropping in which the attacker makes independent connections with the victims and relays messages between them. This makes the victims believe they are communicating directly with one another over a private connection. In fact, the attacker controls the entire conversation.
POODLE poses the biggest mitigation challenge of the three. While Heartbleed and Shellshock require a simple system fix, there is no POODLE patch. Mitigating it requires completely removing SSL v3. The impact of doing so is relatively minor for people using browsers. However, it is huge for API implementations, scripted clients, and all sorts of .Net and Java libraries relying on SSL v3.
Incapsula network data reveals that roughly 2% of all SSL traffic uses v3. Removing it, therefore, means that all referenced clients will not be able to connect to servers.
What is Incapsula doing to mitigate POODLE?
Incapsula is taking a two-step approach-similar to Google research guidelines.
The immediate first step is to eliminate our customers’ POODLE exposure. In order to achieve this, Incapsula has removed support for POODLE-vulnerable CBC ciphers. From our analysis, this should not affect most customers; we will work with those who might otherwise be impacted. This change is effective immediately-Incapsula network customers are not susceptible to the POODLE vulnerability.
Second, Incapsula will work to make two additional changes:
- Deploying code to prevent attackers from forcing SSL v3 use when clients support newer versions. Work is already in progress to make this happen. It will take some time, however, as it also involves changes in client behavior.
- Eventually phasing out SSL v3 entirely, in a responsible way such that customer businesses are not negatively affected. We will analyze network traffic for all clients and provide them custom analysis of what percent of their traffic is using SSL v3.
How can non-Incapsula users mitigate against POODLE?
If mitigation is for a browser-only service, it’s probably best to disable SSL v3. Otherwise, do as we do — immediately disable weak ciphers and work to migrate SSL v3 clients to TLS.