[ad]
When this SSL Renegotiation bug hit the news, most people said it was a theoretical attack and was of no practical use in the real world.
But then people tend to say that about most things don’t they until they get pwned up the face.
It turns out the rather obscure SSL flaw can be used to take over user accounts from websites that use API’s and especially those utilizing 3rd party clients (Twitter being the biggest but a lot of people are accessing Facebook now using clients too).
A Turkish grad student has devised a serious, real-world attack on Twitter that targeted a recently discovered vulnerability in the secure sockets layer protocol.
The exploit by Anil Kurmus is significant because it successfully targeted the so-called SSL renegotiation bug to steal Twitter login credentials that passed through encrypted data streams. When the flaw surfaced last week, many researchers dismissed it as an esoteric curiosity with little practical effect.
For one thing, the critics said, the protocol bug was hard to exploit. And for another, they said, even when it could be targeted, it achieved extremely limited results. The skepticism was understandable: While attackers could inject a small amount of text at the beginning of an authenticated SSL session, they were unable to read encrypted data that flowed between the two parties
So even though the fella couldn’t decrypt or read the data in the session, he could manipulate it in such a way that it spat out the goodies using the Twitter API.
It’s a very neat attack if you ask me, especially if you executed it via DM (Direct Message) it’s pretty unlikely anyone would notice their account had been ‘hacked’.
Perhaps this is how the bad guys have been doing it for a while because I do see an awful lot of hijacked accounts on Twitter and the owners have no idea why (they hadn’t logged in to any dodgy sites with OAuth or their Twitter credentials).
Despite those limitations, Kurmus was able to exploit the bug to steal Twitter usernames and passwords as they passed between client applications and Twitter’s servers, even though they were encrypted. He did it by injecting text that instructed Twitter’s application protocol interface to dump the contents of the web request into a Twitter message after they had been decrypted.
“My point is I think that it’s not so hard to make it work,” said Kurmus, who lives in Zurich and recently completed his masters thesis at the Eurecom Institute. “Maybe some other people did the same thing and did not make it public, so this is why I think it’s important that people would take this bug more seriously.”
Twitter proved an ideal platform to carry out the attack for several reasons. First, every request sent over the microblogging site includes the account holder’s username and password. Second, the site’s API made it easy to post the contents of the intercepted data stream into a message that an attacker could then retrieve.
Twitter has apparently plugged the hole from their side, but as the flaw in SSL itself it seems only one vendor is near to issuing a patch (OpenSSL).
If you extrapolate a little though, this attack could work on anything with a POST/GET interface on the web running on SSL – like Gmail for example.
I hope companies get to patching and plug this hole as it can be carried out all too quietly and wreak a whole lot of havoc!
Source: The Register
d3m4s1@d0v1v0 says
I’d like to see the proof of concept. I was following this failure since last week and I find it very interesting.
I haven’t time to prove it, but I think it can be used easily on a private LAN placing a mitm attack.
This twitter attack reveal account information, but even without doing that, you can do interesting things, like sending a message with your boss e-mail!
emerging says
i’v seen the prove of concept attacks in a paper 2 weeks back :). surfed around the so called -security – sites they were all underestimating the vulnerability -miss design- . that paper describes 3 scenario for exploiting this vulnerability :) . and i guess there reaction was to only elude ppl. But the real disaster is going to be when when you read about the use of “hash clash” method to attack certificates. the method is well documented and has a prove of concept experiments but, again they say it is far from being used . because bla bla bla. so shall we sit and wait OR be of the first ?