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."
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.
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"
"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?"
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 o
Ooops - I spoke to soon. Gotta have OpenSSL (0.9.8l) - that's a letter l at the end, not a number 1. We ain't safe - but I'll be compiling the blasted thing real soon. Debian has no l available in any repository I looked at.
by Anonymous Coward
on Monday November 16, @09:06PM (#30124918)
You are forgiven for the error. Anyone using a letter that could be mistaken for a number in any software version string should be cockpunched with brass knuckles coated in broken glass and lemon juice
The NSA has Alien Technology from Area 51, and you think they're bothering with silly little SSL man-in-the-middle exploits? Pft. Please leave your tinfoil hat at the door, on your way out.
The NSA is like the DIA, they actually have a real mission, funding and never have "Church report" or ""Oliver North" moment.
The staff rise up via wealthy parents or selection via standardised testing and scholarships/part time work.
Entering the final years of advanced maths and cryptography they are tapped/groomed via security clearances for small projects.
If they show the skills and mindset they are invited in deeper.
Nothing like working in the future, with languages, huge budgets and never having to answer to anyone.
Some burn out, some get the contacts and security clearances to contract back, some exit and go private.
Over history, after ww2, the US has been seen to be very good with hardware and software.
Enigma shows the gold standard, Crypto ag and Soviet penetration shows the ongoing skill set.
The idea that "all the big encryption methods" are safe is rather large risk to take.
The US gifted (as in export laws) the world Apple. IBM, Sun, MS , Unix ect.
Was that just for MS and Apple to sell boxes and get students enjoying the American way of digital life?
"the rest of the world" has sold out and is part of the NSA telco loop, a disputed zone or under constant surveillance.
If your under under constant surveillance, it becomes a known known to have fun with:)
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.
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.
Internet banking is 100% SSL/TLS based. On top of that, most banks, and services like Paypal offer B2B interfaces and APIs. This is not just a problem, this is adding a serious risk to all Internet based transactions. Obviously, Internet merchants and banks are going to downplay this publicly but security consultants just paid their next vacation in the Bahamas.
2) Let's assume you have an answer to 1). The exploit involves dumping text to a public message. If your bank has any sort of messaging feature, it's private. Hell, if your tweets are private on twitter, you were never in danger in the first place.
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.
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.
What's to prevent inserting text that essentially says make this request, and use the same password string to change the user's password? Not all malicious uses of the injection need to be about *getting* data. It doesn't even have to be kids having "fun". Locking a particular [set of] user[s] out of a financial system at a critical time in a financial transaction might benefit someone in organized crime.
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.
Well I'm not doing my banking on Twitter anymore that's for sure !
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 [ietf.org].
Time to switch our systems to using challenge-response auth even when the entire site is carried over SSL...
Umm.. most sites don't use SSL for authentication (client certificates), so I don't know what you're implying. Authentication aside, you still have the equally serious loss of integrity that comes with broken crypto.
It would be nice if FireFox updated with detection for sites that would allow this (and other) kinds of attacks. With shit like this in the wild it's hard to know what sites to trust./Paranoid
People ought to stop blaming "The Web" as being inherently insecure. As much as you drill down into it, when party1 communicates with party2 and party1 isn't intimately familiar with party2's identity then transactions of information will always be prone to being exploited. This goes for human interaction (face to face) as well as human-to-computer interaction.
Frankly, I'd rather have an insecure internet than have an internet where everyone's identity was fully exposed and documented.
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/ [ssllabs.com]
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...
Well, that's nice, but there are many other web servers and proxy servers in Debian which are still vulnerable. And from what I can tell, there are no plans to fix the root vulnerability in stable. What are we supposed to do?
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.
Apparently just a specific subset, though it would probably be easy to find other websites with vulnerabilities similar to Twitter's. Basically, although he couldn't directly read the encrypted user name and password passed between Twitter servers and clients, he was able to exploit functionality in Twitter's public API to log the data from the request to a location he could access, including the stuff that had been encrypted in transit.
And the person who publicised the security flaw did a great job by trying it out on Twitter (and mentioning it). Hopefully this will make people tweet a tad bit lesser.
In the interim, its quite necessary to patch the SSL protocol to avoid these kind of attacks.
Hopefully this will make people tweet a tad bit lesser.
I fear it's like hoping a large sponge will be able to lower ocean levels a foot. For some people, I'm sure they would only slack off on their Twitter use if the exploit made your computer grow a foot and kick you in the groin every time you tweeted.
You could actually read the rest of the article, in which it indicates that this is not merely a CSRF-equivalent attack (as it was originally taken to be), as opposed to just reposting an out-of-context snippet chosen to make the editors look bad.
Well, I suppose thats another Benefit of Twitter.. (Score:5, Funny)
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.
Reply to This
Re: (Score:2, Informative)
no its not, in the code base its 666
Don't worry. It'll be fixed soon. (Score:2)
As will the next one. And the one after that, and the one after that...
Re: (Score:2, Funny)
Re:Don't worry. It'll be fixed soon. (Score:4, Funny)
That one burned down, fell over, and THEN sank into the swamp...
Reply to This
Parent
Re: (Score:2)
I don't think the fourth one is going to stay up this time...
Re: (Score:2)
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"
Not worried, fixed already (Score:2, Informative)
"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 [iss.net]
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 o
Re: (Score:2)
Ooops - I spoke to soon. Gotta have OpenSSL (0.9.8l) - that's a letter l at the end, not a number 1. We ain't safe - but I'll be compiling the blasted thing real soon. Debian has no l available in any repository I looked at.
Re:Not worried, fixed already (Score:5, Insightful)
You are forgiven for the error. Anyone using a letter that could be mistaken for a number in any software version string should be cockpunched with brass knuckles coated in broken glass and lemon juice
Reply to This
Parent
Re: (Score:3, Informative)
Looks like Debian has backported the security fix. The version with disabled renegotiation is 0.9.8k-6 .
http://packages.debian.org/changelogs/pool/main/o/openssl/openssl_0.9.8k-6/changelog [debian.org]
It's in "unstable" at the moment, but you should be able to download and install it without harm.
Re: (Score:3, Insightful)
Their are also new packages for Apache2 for Debian for some other parts that needed to be disabled/changed, but it too is just a workaround.
Their isn't yet a real fix, because it's problem with the protocol it self.
Testing times (Score:2)
Re: (Score:2, Interesting)
Do you seriously believe the NSA hadn't exploited this, and other bugs, already ?
Re: (Score:2)
The NSA has Alien Technology from Area 51, and you think they're bothering with silly little SSL man-in-the-middle exploits? Pft. Please leave your tinfoil hat at the door, on your way out.
Re:Really... (Score:4, Interesting)
The staff rise up via wealthy parents or selection via standardised testing and scholarships/part time work.
Entering the final years of advanced maths and cryptography they are tapped/groomed via security clearances for small projects.
If they show the skills and mindset they are invited in deeper.
Nothing like working in the future, with languages, huge budgets and never having to answer to anyone.
Some burn out, some get the contacts and security clearances to contract back, some exit and go private.
Over history, after ww2, the US has been seen to be very good with hardware and software.
Enigma shows the gold standard, Crypto ag and Soviet penetration shows the ongoing skill set.
The idea that "all the big encryption methods" are safe is rather large risk to take.
The US gifted (as in export laws) the world Apple. IBM, Sun, MS , Unix ect.
Was that just for MS and Apple to sell boxes and get students enjoying the American way of digital life?
"the rest of the world" has sold out and is part of the NSA telco loop, a disputed zone or under constant surveillance.
If your under under constant surveillance, it becomes a known known to have fun with
Reply to This
Parent
That, or . . . (Score:2)
they'll just keep posting reading those state secrets right off the spy's twitter . . . yeaaaaaaah.
Kinda bad summary (Score:5, Insightful)
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.
Reply to This
Re:Kinda bad summary (Score:5, Insightful)
Reply to This
Parent
Re:Kinda bad summary (Score:4, Interesting)
Internet banking is 100% SSL/TLS based. On top of that, most banks, and services like Paypal offer B2B interfaces and APIs. This is not just a problem, this is adding a serious risk to all Internet based transactions. Obviously, Internet merchants and banks are going to downplay this publicly but security consultants just paid their next vacation in the Bahamas.
Reply to This
Parent
Re:Kinda bad summary (Score:4, Interesting)
2) Let's assume you have an answer to 1). The exploit involves dumping text to a public message. If your bank has any sort of messaging feature, it's private. Hell, if your tweets are private on twitter, you were never in danger in the first place.
Reply to This
Parent
Re:Kinda bad summary (Score:4, Interesting)
Wrong. Your HTTP headers don't end up on your Twitter "blog" (or whatever it's called), they end up on the attacker's.
And as for banks not having a public messaging feature, is Citibank big enough for you?
https://banking.citibank.com/JoinOurOnlineForum/UserGuide.aspx [citibank.com]
But once again, do note that the page where the user's credentials end up doesn't need to be public; it just has to be accessible by the attacker.
Reply to This
Parent
Kinda bad article (Score:5, Informative)
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.
Reply to This
Parent
Re: (Score:3, Interesting)
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.
What's to prevent inserting text that essentially says make this request, and use the same password string to change the user's password? Not all malicious uses of the injection need to be about *getting* data. It doesn't even have to be kids having "fun". Locking a particular [set of] user[s] out of a financial system at a critical time in a financial transaction might benefit someone in organized crime.
Re:Kinda bad summary (Score:4, Funny)
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.
Well I'm not doing my banking on Twitter anymore that's for sure !
Reply to This
Parent
What to do? (Score:4, Informative)
Reply to This
Good explanation of the bug by TLS spec author (Score:5, Informative)
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 [educatedguesswork.org]
Reply to This
Change in password/auth policy (Score:2)
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?
Re: (Score:2)
Anyone have good ideas for authentication mechanisms
Genome scans and very large automatic rifles!
Re: (Score:2)
Time to switch our systems to using challenge-response auth even when the entire site is carried over SSL...
Umm.. most sites don't use SSL for authentication (client certificates), so I don't know what you're implying. Authentication aside, you still have the equally serious loss of integrity that comes with broken crypto.
The sky is falling (Score:4, Insightful)
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.
Reply to This
Re: (Score:3, Insightful)
It would be nice if FireFox updated with detection for sites that would allow this (and other) kinds of attacks.
FF already nags enough.
Re: (Score:2)
> ...it's hard to know what sites to trust.
None. The Web is inherently insecure.
Re:The sky is falling (Score:5, Insightful)
Frankly, I'd rather have an insecure internet than have an internet where everyone's identity was fully exposed and documented.
Reply to This
Parent
SSL Renegotiation Attacks... (Score:2)
Twitter? (Score:2)
Nothing of value was lost.
Securing Servers (Score:4, Informative)
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/ [ssllabs.com]
BTW, clients (e.g. browsers) are pretty save - there is NO need to panic!!
Reply to This
Debian Linux (Score:3, Interesting)
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...
Reply to This
Re: (Score:2)
Well, that's nice, but there are many other web servers and proxy servers in Debian which are still vulnerable. And from what I can tell, there are no plans to fix the root vulnerability in stable. What are we supposed to do?
hmmmmm (Score:4, Funny)
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.
Reply to This
Re:Just one phrase that fits. (Score:4, Funny)
Reply to This
Parent
Re: (Score:2)
Or in Internet English:
OMGWTF!
Just so I'm clear here, does this mean that SSL, (and thus all https traffic) is compromised, or is it just a specific subset?
I mean, are we talking about just twitter and facebook getting fux0r3d or is this everyone from Amazon to banking to webmail?
Re:Just one phrase that fits. (Score:5, Informative)
Reply to This
Parent
Re: (Score:2, Insightful)
No it just means they will arrest him and throw him in jail next time he visits the USA on holiday.
Re: (Score:2)
Re: (Score:2)
Crikey! We're rooted!
Two phrases for us as well, mate. That's fair dinkum.
Re: (Score:2)
And the person who publicised the security flaw did a great job by trying it out on Twitter (and mentioning it). Hopefully this will make people tweet a tad bit lesser.
In the interim, its quite necessary to patch the SSL protocol to avoid these kind of attacks.
Re:Just one phrase that fits. (Score:4, Funny)
Hopefully this will make people tweet a tad bit lesser.
I fear it's like hoping a large sponge will be able to lower ocean levels a foot. For some people, I'm sure they would only slack off on their Twitter use if the exploit made your computer grow a foot and kick you in the groin every time you tweeted.
Reply to This
Parent
Re: (Score:2)
Re:theregoestheinternet? Not so fast! (Score:5, Informative)
You could actually read the rest of the article, in which it indicates that this is not merely a CSRF-equivalent attack (as it was originally taken to be), as opposed to just reposting an out-of-context snippet chosen to make the editors look bad.
Reply to This
Parent