Tuesday, November 18, 2014

IT: SSL 3.0 "Poodle" Vulnerability

My new gig is keeping me pretty busy. Here's a bit I wrote on the Poodle SSL vulnerability today.

What is the vulnerability?

SSL 3.0’s block cipher encryption is vulnerable to a padding
attack. With this technique an attacker with access to the network path
between client and server can decode the contents of an encrypted message by
forcing it to be retransmitted many times.

To make this work, at a minimum, the attacker must be able
to intercept and modify the network traffic sent by the client to the remote
server. (Examples of this include unencrypted wi-fi or access to the
physical network between server and client.) Additionally, this attack
requires very large numbers of requests (hundreds to tens of thousands) to be
sent to the remote server. As such, the attack is really only feasible if
the attacker also has the ability to run malicious code (i.e. JavaScript) on
the client.

How does it work?

First, the attacker has to get the user to run their
malicious code. This can be accomplished by a man-in-the-middle
attack against an unencrypted site.

Next, the code makes a connection to a secure site
whose request they wish to decode.

Then the attacker must trick the client into using SSL 3.0
to talk to the remote server. This is accomplished by interrupting or
corrupting requests for a TLS connection.

Once the SSL connection is opened, the attacker changes the
SSL request by changing a single byte of the stream, their “guess”, and adding
additional padding to the SSL stream they want to decode.

-If the attacker has guessed the SSL-encrypted
byte improperly, the SSL connection will fail and disconnect.

-If the attacker has guessed that byte properly,
the SSL connection succeeds.

This pattern repeats until the SSL
request has been decoded. Each “Guessed” byte is a random value between 0
and 255, so decoding a 64 character request can take up to 16,000 attempts to
complete, depending on the luck of the attacker.

Finally the malicious code will
report back the decoded request to the attacker. [1]

What Protocols are vulnerable?

SSL 3.0

Is TLS 1.0 vulnerable?
With SSL 3.0 disabled, no. TLS 1.0 has a built-in fail-back to SSL 3.0 if
TLS negotiation fails. An attacker can only leverage this failback if
both TLS 1.0 AND SSL 3.0 are enabled. This risk is eliminated when SSL
3.0 is disabled.

How acute is this Vulnerability?

Microsoft’s position is that there are no secure ciphers
remaining in SSL 3.0, and it should be disabled.[3]

SANS’ position, from the CVE summary, is slightly more
nuanced.[2]

“What should you do: Disable SSLv3.
There is no patch for this. SSLv3 has reached the end of its useful life and
should be retired.

This isn't a "patch now".
Give it some time, test it carefully, but get going with it. The other problem
is that this is a client and a server issue. You need to disable SSLv3 on
either. Start with the servers for highest impact, but then see what you can do
about clients.”

What is the impact of disabling SSL 3.0?

Clients that do not support TLS 1.0 or above will fail to
connect. This specifically includes Internet Explorer 6.0. I call attention to this browser specifically as it still has a non-trivial installed base, comprising 1.6% of all internet traffic in October 2014.[5]

How do I disable SSL 3.0 on Clients?

-SSL 3.0 can be disabled in Internet Explorer
using a check box on the advanced tab of the Internet Options Panel.

-Other OS Components

oWeb
Browsers are the most likely target for attack, but are not the only components
that use SSL.

oThe
Windows operating system provides a library called Schannel to handle client
encryption.

oThe
SSL 3.0 Schannel client can be disabled using the registry key [3]