SSL v3 vulnerability: this POODLE eats secure cookies

What this is:

A method to compromise communication encrypted by SSL v3 (meaning: access secure cookies, thereby gaining access to session information)

What this is not:

A direct method of compromising endpoints

What is required:

A node capable of intercepting traffic between two nodes; a “bump on the wire”
The nodes at each end (client and server) are willing to fall-back to SSL v3

There is an ongoing balancing act between Internet browser software, the servers they communicate with, and the attackers attempting to profit by compromising the end-user, server, or communication between the two. In stark security terms, it’s permissive (bad) versus restrictive (good) behavior, while from an operations perspective, the opposite is true (permissive is good, restrictive is bad), at least until there’s a problem.

poodle

The most successful browsers are those that are willing to parse information from the widest variety of servers. The most popular servers are willing to serve information to the widest variety of browsers. This means that developers and administrators aim to achieve the widest available audience by accepting the widest possible variety of permutations of browser-server interactions.

This vulnerability provides a compelling example of permissive behavior leading to trouble. Though the version of SSL in question is nearly fifteen years old, it is highly likely that most browsers and servers, after failed attempts to use newer versions, will allow encryption to fall-back to SSL v3.

Though a server may prefer TLS (Transport Layer Security; a contemporary version of Secure Sockets-Layer [SSL]), from the perspective of usability, if a browser insists on using an older version of SSL, the server will permit it (if so configured) as part of the negotiation between the browser and server. Likewise, if a server is incapable of using TLS, a browser may permit the use of older SSL technology.

That permissive negotiation can run into problems if someone is in the middle of the conversation. There are two steps:

Modify the messages that form the negotiation such that the browser and server believe that they must fall-back to an older version of SSL

Once communication is established using the older version of SSL, engage the attack mechanism

When successful, the attacker will have plaintext access to the content of secure cookies. Let’s say you access your online banking application, while someone has access to the traffic between your browser and the bank server. As your browser accesses the banking site, the man-in-the-middle modifies the conversation so that your browser and the server agree to use SSL v3. After authenticating, the server maintains your session on the server, but to access that session, it expects communication from the browser to contain encrypted cookies. Without those secure cookies, the server doesn’t trust your browser. If the attacker has access to those cookies, they can convince the server that they are your browser. There may also be valuable information in the content of the secure cookies.

To remediate this attack, the recommendation is to restrict the permissive behavior of clients and/or servers (depending on which you have control of). Simply put, if one or the other refuses to fall-back to older versions of SSL, it is impossible to create the conditions in which the malicious man-in-the-middle requires to exploit the vulnerability.

What you can do is pretty straightforward. Install the latest patches for browsers and other clients that rely on SSL. If you are a server administrator, you can likewise check your patch version, and update your server settings to not allow fall-back to SSL v3. Finally, as an end-user, always push the “Logout” button. If the application is properly coded, that will end your session on the server side, meaning that the secure session cookies are no longer useful (unless your authentication information has been compromised).