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.
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.
The reason he went after Twitter was:
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.
Finally, many Twitter users send and receive messages using third-party applications. Many of those programs ignore error pages like those that would have resulted from Kurmus's attack, preventing victims from knowing anything was amiss.
So, here's my thinking on this: even though Twitter have fixed the bug on their side, you can rest assured that there are others. Twitter's implementation and "oauth" external authorisation model mean that it's always going to be a popular target.
The first thing you have to do is make sure you don't have a similar login/password combination on any other site. Always make sure Twitter has a different password to any other site that has the same login.
The second thing you have to do is to change your Twitter password fairly regularly. This means that even if your account is compromised, it won't be for too long.
Thirdly, always keep your eyes open for weird messages or behaviour. If something odd happens, it's probably worth changing your password immediately.
Security is a pain in the arse, but it's a price you have to pay.
3 comments:
Twitters "security" model seems a little flawed.
Sending the Username and password on every request (in the cookies?) seems a little open to abuse.
Me, I put s GUID in the URL and throw it away after each page is shown.
Much as I admire and read El Reg, this bit :
"First, every request sent over the microblogging site includes the account holder's username and password" is wrong.
This is only the case if using the basic auth model. The oAuth model specifically avoids transferring ID/passwords, that's the point of the horrid thing.
I know this because I spent several hours writing an oAuth module because all the ones available on the web appeared to have been written by cunts.
Which brings me neatly to :
Many of those programs ignore error pages like those that would have resulted from Kurmus's attack
Essentially meaning that the programmers of those apps chose, chose mark you, to ignore the error code in the HTTP response header. Cunts, I tell you.
"Essentially meaning that the programmers of those apps chose, chose mark you, to ignore the error code in the HTTP response header. Cunts, I tell you."
People who write business applications are no better. ;o(
Post a Comment