Not just CSRF: SSL Authentication Gap used for credentials theft

Most people associate the recent SSL Authentication Gap vulnerability with mild CSRF, but a couple of days ago Anil Kurmus published an improved attack technique that enabled him to access victims' encrypted data streams. He wrote a proof of concept that could have been used to retrieve someone's Twitter credentials. Twitter's SSL servers no longer support renegotiation so the attack no longer works, but the same principle will still work with other sites. Anil's attack technique was posted to Full Disclosure last Wednesday, but it was ignored. It was subsequently picked up by Dan Goodin from The Register.

In researching the possible attack vectors made possible with the SSL authentication gap problem, most focused on trying to use the credentials included with hijacked requests (i.e., session cookies or Basic Authentication credentials). Anil realised that, although he was not able to decrypt the hijacked requests he was still able to include them as payload in arbitrary requests of his own. So all he needed was a site that has some sort of publishing functionality that can be used to reveal data. With the Twitter attack, he simply published the hijacked data as his Twitter status message.

The attack works because the hijacked information is used in a parameter of the attacker's request. Below is a partial attack example to describe the concept:

POST /statuses/update.xml HTTP/1.0
Authorization: Basic [attacker's credentials]

status=POST /statuses/update.xml HTTP/1.1
Authorization: Basic [victim's credentials]

This attack technique is best suited to exploit APIs protected using Basic Authentication. It will work equally well for session hijacking, but hijacking the credentials in the case of sites that use form-based authentication may be more difficult due to the presence of the ampersand characters in victims' data streams.

Marsh Ray (who discovered the SSL authentication gap issue), hinted that information theft might be possible in a comment to Eric Rescorla's blog post, but he said he was more interested in fixing the problem rather than seeking interesting ways to abuse it.

Comments

[Michael Owens]

So how does one disable Apache SSL renegotiation? I've looked at the mod_ssl doc, and it appears that renegotiation is forced only in location or directory blocks.

[Ivan Ristic]

You have two choices: 1) install this patch for Apache 2.2.14 http://bit.ly/3ttc7A or 2) upgrade (or patch) OpenSSL. If you are using a vendor-supplied Apache, wait for them to deal with the problem :)

[Michael Owens]

Thanks for the pointers.

[Kyle H]

Not everything that uses SSL/TLS is vulnerable. Most notably, anything that drops everything that it received under another security 'veil' when a renegotiation that changes the user's credentials occurs has already taken steps at the application/TLS interface to mitigate it.