SSL and TLS Authentication Gap vulnerability discovered

A serious vulnerability has been discovered in the way web servers utilise SSL (and TLS, up to the most recent version, 1.2), effectively allowing an active man-in-the-middle attacker to inject arbitrary content into an encrypted data stream. Both the Apache web server and the IIS have been found to be vulnerable.

The problem is with the renegotiation feature, which allows one part of an encrypted connection (the one taking place before renegotiation) to be controlled by one party with the other part (the one taking place after renegotiation) to be controlled by another. A MITM attacker can open a connection to an SSL server, send some data, request renegotiation and, from that point on, continue to forward to the SSL server the data coming from a genuine user. One could argue that this is not a fault in the protocols, but it is certainly a severe usability issue. The protocols do not ensure continuity before and after negotiation.

To make things worse, web servers will combine the data they receive prior to renegotiation (which is coming from an attacker) with the data they receive after renegotiation (which is coming from a victim). This issue is the one affecting the majority of SSL users.

The following example demonstrates how the flaw can be exploited by an attacker to send an arbitrary request using the authentication credentials of a victim. The red parts are sent by the attacker and the blue parts are sent by the victim.

GET /path/to/resource.jsp HTTP/1.0
Dummy-Header: GET /index.jsp HTTP/1.0
Cookie: sessionCookie=Token

The good news is that, although the attacker can execute an arbitrary request, he will not be able to retrieve the corresponding response. On the negative side, the client will see something different from that what she requested.

You can see that GET attacks are essentially trivial to execute. To date, no one has claimed a successful execution of a POST request using this flaw. Until someone does, that means that an application that only makes changes in response to POST requests will probably not be vulnerable. Further, an application not vulnerable to CSRF attacks will probably be safe too, because the attacker won't be able to generate or predict the token required for the request to go through.

Mitigation options:

1. If you can, disable renegotiation. There isn't normally a configuration option to do this, but patches are being developed and will be available soon. The majority of web sites do not use renegotiation so disabling it won't be a problem. Those that do will need to make changes to their sites to make them work without it.
2. Use a web application firewall to monitor the contents of all request headers to spot what seems like an embedded HTTP request line. The good news is that the embedded request line will not be obfuscated, making it easier to detect. I do not believe that this advice can help the bypass of the client certificate authentication, though.
3. If you can, monitor all connections that make use of the renegotiation feature. That won't help you if renegotiation is an integral feature of your web site, but it may do if it is rarely used.

Further information:

• Marsh Ray's blog post (Marsh discovered the problem a couple of months ago) contains a detailed description of the problems in the attachment.
• The post by Martin Rex to the TLS mailing list that prompted public disclosure.

Comments

[Steven]

"Use a web application firewall to monitor the contents of all request headers to spot what seems like an embedded HTTP request line. The good news is that the embedded request line will not be obfuscated, making it easier to detect. I do not believe that this advice can help the bypass of the client certificate authentication, though."

What mod_security directive would you recommend?

[Ivan Ristic]

Steven, I haven't tried but I don't think ModSecurity can be used to mitigate this particular issue, though not through a fault of its own. The problem is that Apache terminates request headers when it encounters a NUL byte. Thus all the attacker needs to do is spice up the attack with a NUL byte as the last byte in the unfinished request header.

Still, not all attackers will have a deep knowledge of the Apache ways, so it may be worth writing a ModSecurity rule after all. You could try this simple rule (not tested):

SecRule REQUEST_HEADERS "@rx HTTP/1\.[01]" phase:1,t:none,log,deny

The assumption is the the protocol information will be part of the genuine client request and that no evasion will be attempted.

[Jeremy]

If one wanted to quickly and easily add CSRF protection to there app - there is always the OWASP CSRFGuard:

http://www.owasp.org/index.php/Category:OWASP_CSRFGuard_Project

[arkanoid.livejournal.com]

Is there a way to detect renegotiation from client-side application (and to, say, drop the connection if there was any)? I was trying to figure out by myself and could not find a solution.

[Ivan Ristic]

I don't believe that it is possible to detect renegotiation if you are a victim, because what seems like the first negotiation to you might actually be a renegotiation in a MITM situation.