Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Security

SSL Renegotiation Attack Becomes Real 97

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."
This discussion has been archived. No new comments can be posted.

SSL Renegotiation Attack Becomes Real

Comments Filter:
  • Holy crap, that sucks.
    • by Bottles ( 1672000 ) on Monday November 16, 2009 @06:35PM (#30123672)
      Or 'Goodness, old boy, that's dashed inconvenient!' for us Brits. So two phrases. Gosh.
      • 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?

        • by crymeph0 ( 682581 ) on Monday November 16, 2009 @08:06PM (#30124538)
          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.
          • So you didn't bother to RTFA did you now? It was after all ONE click away and stuff.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.

            So, added slashdot formatting for you

        • Re: (Score:2, Insightful)

          by Anonymous Coward

          No it just means they will arrest him and throw him in jail next time he visits the USA on holiday.

          • by dch24 ( 904899 )
            GET it.slashdot.org/post?user=Anonymous%20Coward&pw=hi HTTP/1.1
            Host: it.slashdot.org
            User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; zh-TW; rv:1.9.0.10) Gecko/2009042316 Firefox/3.5.5
            Accept: text/html
            Connection: keep-alive
            Referer: http://88.80.13.160/custom_feed.xml [88.80.13.160]
            Cookie: __unam=ff611ea-121c61ef92e-7d0ca25d-4; PHPSESSID=g4cu6pdclgqverrf2a522uofl1

            Well, Anonymous Coward will never get caught out this way!
      • Comment removed based on user account deletion
      • by deek ( 22697 )

          Crikey! We're rooted!

          Two phrases for us as well, mate. That's fair dinkum.

      • by grcumb ( 781340 )

        Or 'Goodness, old boy, that's dashed inconvenient!' for us Brits. So two phrases. Gosh.

        Or in Californian:

        "Duuu-uude..."

        That's two phrases as well.

    • 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.

      • by The Archon V2.0 ( 782634 ) on Monday November 16, 2009 @07:54PM (#30124434)

        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.

        • by grcumb ( 781340 )

          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.

          @me: OWIE PC keeps OW kicking OW REALLY HURTS pics here: http://bit.ly/3423dghe [bit.ly]

      • And this person is called Anil Kurmus. I'm not sure what a Kurmus is but I'd prefer not to take one anilly.
  • by Monkeedude1212 ( 1560403 ) on Monday November 16, 2009 @06:38PM (#30123710) Journal

    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.

    • by Oewyn ( 1526739 )

      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.

  • As will the next one. And the one after that, and the one after that...

    • Re: (Score:2, Funny)

      by pookemon ( 909195 )
      However the one after that will take a bit longer...
    • "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

      • 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, 2009 @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

          • by sorak ( 246725 )

            That gives me kid Icarus flashbacks...Can I borrow your brass knuckles?

          • I'm compelled wondering what elabor8 && arcane malice you'd devise && visit upon me for my versioning system:

            $majr.$minr.$ptim

            e.g., 1.4.9BHD2cg (Major Version 1, [Relatively] Stable Minor Revision 4, Released 2009 Tuesday November 17 13:02:38:42)

            HTTP://Ax9.Org/pt

            It utilizes my Base64 (/[0-9A-Za-z._]+/) encoding to store d8 && time (down to 60th-of-a-second frames) utilizing only 7 characters.

            HTTP://Search.CPAN.Org/~Pip

            It's handy for me sin

        • Re: (Score:3, Informative)

          by deek ( 22697 )

          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)

            by Lennie ( 16154 )
            You have to remember it's not a fix. It's a workaround, it just disables part of the protocol.

            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.
        • Well, the obvious search http://www.google.com/search?q=debian+openssl+%220.9.8l%22 [google.com] comes up with

          http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=555829 [debian.org]

          Which ends:

          Subject: Bug#555829: fixed in openssl 0.9.8k-6
          Date: Thu, 12 Nov 2009 18:48:39 +0000

          Source: openssl
          Source-Version: 0.9.8k-6

          We believe that the bug you reported is fixed in the latest version of
          openssl, which is due to be installed in the Debian FTP archive:

          [...]

          Closes: 555829
          Changes:
          openssl (0.9.8k-6) unstable; urgency=low
          .

  • No doubt some government somewhere around the world will use this to grab as much information as possible before the exploit is patched.
    • Re: (Score:2, Interesting)

      by Gothmolly ( 148874 )

      Do you seriously believe the NSA hadn't exploited this, and other bugs, already ?

      • 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.

    • they'll just keep posting reading those state secrets right off the spy's twitter . . . yeaaaaaaah.

  • Kinda bad summary (Score:5, Insightful)

    by Virak ( 897071 ) on Monday November 16, 2009 @06:53PM (#30123856) Homepage

    Important part of the article:

    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.

    • by teh_commodore ( 1099079 ) on Monday November 16, 2009 @06:58PM (#30123898)
      Oh good. We're totally fine. It only works on sites that are poorly designed. And Twitter's been patched, so that leaves, well, I guess no one.
      • Re:Kinda bad summary (Score:4, Interesting)

        by dimeglio ( 456244 ) on Monday November 16, 2009 @07:11PM (#30124052)

        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.

        • Re:Kinda bad summary (Score:4, Interesting)

          by teh_commodore ( 1099079 ) on Monday November 16, 2009 @08:51PM (#30124822)
          1) Which banks have an open-to-the-public API?

          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.
        • Internet banking is 100% SSL/TLS based.

          <keith>In America.</keith>

          Seriously, though, internet banking has very little in the way of standardization across countries. HTTPS is popular but then you also have HBCI/FinTS (Germany) or SEED (S. Korea) and most likely other local standards in other countries.

          I'm happy with my HBCI+Smartcard homebanking. Granted, I need to use proprietary apps for it but I still prefer it over PIN/TAN via HTTPS. With the right card reader (class 2 or 3), not even my

    • Kinda bad article (Score:5, Informative)

      by Virak ( 897071 ) on Monday November 16, 2009 @07:05PM (#30123960) Homepage

      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.

    • Re: (Score:3, Interesting)

      by Culture20 ( 968837 )

      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.

    • by Fred_A ( 10934 ) <fred@ f r e dshome.org> on Monday November 16, 2009 @08:41PM (#30124774) Homepage

      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 !

  • What to do? (Score:4, Informative)

    by whathappenedtomonday ( 581634 ) on Monday November 16, 2009 @07:00PM (#30123914) Journal
    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].
  • 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]

  • 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?

    • Anyone have good ideas for authentication mechanisms

      Genome scans and very large automatic rifles!

    • 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)

    by LBt1st ( 709520 ) on Monday November 16, 2009 @08:42PM (#30124782)

    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

    • Re: (Score:3, Insightful)

      by Frosty Piss ( 770223 )

      It would be nice if FireFox updated with detection for sites that would allow this (and other) kinds of attacks.

      FF already nags enough.

    • > ...it's hard to know what sites to trust.

      None. The Web is inherently insecure.

      • by socceroos ( 1374367 ) on Monday November 16, 2009 @11:27PM (#30125740)
        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.
      • by LBt1st ( 709520 )

        I agree, hence why I use a whitelist to prevent sites from using any scripting on my machine. I even whitelist cookie usage. But this exploit is on a whole new level.

  • Shut. Down. EVERYTHING.
  • Nothing of value was lost.

  • Securing Servers (Score:4, Informative)

    by StartCom ( 1018308 ) on Monday November 16, 2009 @08:55PM (#30124846) Homepage

    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!!

  • Debian Linux (Score:3, Interesting)

    by jchawk ( 127686 ) on Monday November 16, 2009 @08:55PM (#30124856) Homepage Journal

    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...

    • by XanC ( 644172 )

      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?

  • Hackers (Score:1, Redundant)

    Hack the planet!!
  • 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."

  • I can't help but smile at the title and subtitle of TFA:

    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.

  • by account_deleted ( 4530225 ) on Tuesday November 17, 2009 @08:20AM (#30127992)
    Comment removed based on user account deletion
  • "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 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 suite

  • 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

If all else fails, lower your standards.

Working...