Slashdot Mirror
SSL Renegotiation Attack Becomes Real
rastos1 and several other readers noted that the SSL vulnerability we discussed a couple of weeks back, which some researchers had claimed was too theoretical to worry about, has now been demonstrated by exploit. The attack description is available on securegoose.org. "A Turkish grad student has devised a serious, real-world attack on Twitter that targeted a recently discovered vulnerability in the SSL 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. 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."
Holy crap, that sucks.
512 MB RAM, 20 GB disk, 200 GB transfer, five datacenters. $19.95/month.
It's nice to have a Sandbox for testing the latest and greatest hacks and security protocols, where no one cares about the user and/or what information they've posted on the site.
FUD!!!!
As will the next one. And the one after that, and the one after that...
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
And has already been patched on twitters end last week.
Oh the deliciousness of it all
No doubt some government somewhere around the world will use this to grab as much information as possible before the exploit is patched.
Take Nobody's Word For It.
Important part of the article:
The only reason it was exploitable was because of Twitter's API. Understandably, I'm not too worried about the rest of the Internet going down in flames any time soon.
I wondered how this will be addressed and the numerous "it will be fixed, don't worry" posts were not really helpful. TFA was and linked to "a TLS extension to cryptographically tie renegotiations to the TLS connections they are being performed over, thus preventing this attack" draft.
I hope I didn't brain my damage.
A good source of info about what this attack is and how serious it is can be found at
http://www.educatedguesswork.org/2009/11/understanding_the_tls_renegoti.html
Well, I suppose it's my own fault for trusting The Register. After reading the first article, I got curious and went on to check out the technical details of the exploit. What The Register phrases as "it's Twitter's API's fault" is actually "holy fuck you can POST the whole HTTP message to arbitrary locations (hosted on the same server, anyway)", which is a tad bit worse. While the Internet still isn't going to go down in flames, this does open up potential for some sites to get some nasty burns, and in a way they almost surely won't already be protected against, even if the developers aren't idiots.
Time to switch our systems to using challenge-response auth even when the entire site is carried over SSL...
Of course that means having to store passwords in a for that the server-side code can decode them, which is itself generally a no-no...
Anyone have good ideas for authentication mechanisms that can't be circumvented by this and similar hacks?
FTFA:
I know this is /., but come on and at least check when it's a claim as big as "theregoestheinternet."
However the one after that will take a bit longer...
dnuof eruc rof aixelsid
they'll just keep posting reading those state secrets right off the spy's twitter . . . yeaaaaaaah.
NSA has a lot of resources. They have a lot of clever people working there. (Though I don't know how motivated they are to constantly do their best aftery they get hired.)
That said... It's just a government agency. One large organization. I have large difficulties to believe that they can know (let alone utilize) backdoors to all the big encryption methods/communications softwares/protocols/operating systems and whatnot. And this all without the rest of the world ever finding out details.
It's nice to have a Sandbox for testing the latest and greatest hacks and security protocols, where no one cares about the user and/or what information they've posted on the site.
How about slashdot? We could make it a game, person who can steal the credentials w/ the lowest UID wins.
...person who can steal the credentials w/ the lowest UID wins.
I win!!!!
Anonymous Coward is '0'
no its not, in the code base its 666
"Fortunately a version of OpenSSL (0.9.8l) is available which disables renegotiation, which is appropriate for most applications. According to Mr. Kurmu, Twitter seems to have already applied it. Have you?"
http://blogs.iss.net/archive/stealingcookieswiths.html
Unless I'm missing something, I need not worry about the wife, or myself. We both have OpenSSL 0.9.8 but I ain't sure WHAT my sons are using. Windows XP probably doesn't use SSL.
Oh well - I'll just warn them one more time NOT to do internet banking on their Windows machines, and warn as well that their SSL connections may be vulnerable.
"Windows is like the faint smell of piss in a subway: it's there, and there's nothing you can do about it." - Charlie Br
It would be nice if FireFox updated with detection for sites that would allow this (and other) kinds of attacks. /Paranoid
With shit like this in the wild it's hard to know what sites to trust.
Shut. Down. EVERYTHING.
Nothing of value was lost.
--
Stay tuned for some shock and awe coming right up after this messages!
Obviously such attacks are possible because of the application security, renegotiation just makes it easier. BTW, here is a tool to check if your server is vulnerable to renegotiation attacks: https://www.ssllabs.com/ssldb/
BTW, clients (e.g. browsers) are pretty save - there is NO need to panic!!
For what its worth Debian released an update to Apache and guidance on how to mitigate the vulnerability.
They did indicate that this was only a work around and a protocol redesign would be required in order to completely fix the vulnerability.
I wonder how many people just simply aren't paying attention and will get burnt by this problem. I want to believe not many but I honestly know better...
Hack the planet!!
Long live the BSD license
That one burned down, fell over, and THEN sank into the swamp...
666 is still fairly hard to beat.
I don't think the fourth one is going to stay up this time...
Warning: this article may contain humor, sarcasm, parody, and perhaps even irony. Read at your own risk.
I once asked my russian friend what the slang "pizdets" means, though it literally is vagina it is used like "fucked". He said it was something beyond hopeless, "thing burn to ground, someone drops atom bomb on embers, pigs come and zey shit in zee crater"
But the fourth one stayed up. And that's what you're going to get, Lad, the strongest castle in all of England
Funny mod's well deserved evilpengquin.
dnuof eruc rof aixelsid
it does not mean "vagina" literally, actually. you probably were thinking about 'pizda', which also would be more like 'cunt'
From TFA: "To be sure, Kurmus's attack only worked because Twitter's API allowed him to post the captured data steam to a tweet that he was then able to retrieve."
Researcher busts into Twitter via SSL reneg hole
Yes, it's a serious vuln
So now we assess the gravity of the situation based on Twitter? Awsm.
His explanation describes how the compromise might work using online pizza ordering as an example. This is a superb way to highlight the risks. No-one wants their pizzas going to someone else, after all.
Goodbye car analogies, Hello pizza analogies :-)
"If you think the problem is bad now, just wait until we've solved it." --- Arthur Kasspe
looks like we're all well and truly fucked.
Microsoft should have a patch in about 8 years, Apple will have lashed its developers until there are no further utterances of this problem, Adobe will ask what model phone does it affect, Oracle will ship another box of stupid mugs and tshirts to me as soon as I complain about the vulnerability, Dell will insist i continue to wait for the DRAC to load its SSL page, and i think most importantly my bank will have little, if ANY clue what im talking about.
I need about, say, a million open source eyes on this problem. Gentlemen, the internet appears broken and im offering beer to fix it.
Good people go to bed earlier.
"every request sent over the microblogging site includes the account holder's username and password"
Retarded design. However this attack could just as easily be used to dump a session id from a well designed site with the same end result. This is bad bad bad...
The attacker could, once in the user's session, change their password and email address and hijack the account.
Don't kid yourself. It's the size of the regexp AND how you use it that counts.
You're mixing Polish with Russian. Something like NI3.
Upward mobility is a slippery slope - the higher you climb the more you show your ass.
I think you missed the sound. It was something like: Whoosh!
Don't get me wrong, I think the initial "this isn't a practical problem" response to the SSL reneg vulnerability is a serious mistake. A major facet of security is knowing what the system is doing; if the system is doing something unexpected that none of the legitimate users can anticipate, then there is a potential for severe security problems. This is one of the big reasons why I wish people who think "it works so I don't have to know why" would leave the programming industry and do something more suited to that way of thinking.
HOWEVER, the people who should be really embarrased from a security standpoint are twitter. Why does their API have a function that causes the user's password to be written to anywhere in cleartext?!? That's just bat-shit crazy. And as I understand it their workaround is to disable reneg instead of addressing the application-level problem? (If they'd done both, I'd say the response were at least on the ball...)
To be clear - if there's a feature of twitter that depends on writing out user credentials in cleartext, feel free to enlighten me; but my response will assuredly be "then that feature is not worth the risk and should not exist".
The fundamental problem is that the password (or its material) is sent through the encrypted SSL channel instead of being integrated into it. The SSL negotiation should use the password to (re)generate the shared secret. If the server doesn't have the password (or password derived bits), it won't be able to communicate with the client. Similarly for the client. Why does this matter? A Man In The Middle attack is more difficult to stage because the client can detect that the middle man has no knowledge of the password during the secret key negotiation phase. It is still possible for the MITM to guess the key (at chance) and depending upon the protocol, the MITM might be able to extract information about the password that allows better than chance guessing; this all depends upon the design of the protocol. There are plenty of protocols out there both freely available and patented that solve this problem. The patent for Encrypted Diffie Hellman has just expired and ought to be used by everyone, now. The problem is that SSL hardware accelerators won't work as expected, since they take the server key and pass the client credentials (password or its derived material) back to the application server for login. With an updated (more secure system), the password verifiers will have to be pushed down into the hardware accelerators, which means the hardware accelerator will have to "know" about the users, keep a user database. IT nightmare. Plus, that accelerator is sitting at the network edge, so you've got all of the user/password verifier info residing in close proximity to the internet (and hackers). I still think it's better than sending your password (material, verifier) over a channel to a remote server. Anyone can be tricked into doing it.
nah, in Polish it's pochwy
Trying to teach a Polish guy Polish? Spierdalaj.
Upward mobility is a slippery slope - the higher you climb the more you show your ass.