Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

Create Account  |  Retrieve Password

Point-and-Click Gmail Hacking Shown at Black Hat

Posted by Zonk on Fri Aug 03, 2007 09:12 AM
from the man-they-get-all-the-fun-demos dept.
Security Communications IT
not5150 writes "Using Gmail or most other webmail programs over an unsecured access point just got a bit more dangerous. At Black Hat Robert Graham, CEO of errata security, showed how to capture and clone session cookies very quickly over connections without encryption. He even hijacked a shocked attendee's Gmail account in the middle of his presentation. 'While Ou was typing, Graham was running Ferret and sniffing all the cookies that were being sent from Ou's laptop and Google. Graham then clicked on Ou's IP address and Gmail page, complete with Ou's recently sent message on the screen. We photographed both Graham's and Ou's laptop at that time and posted it to the picture gallery. You'll see that the contents are exactly the same.'"
+ -
story

Related Stories

[+] Your Rights Online: Delete Cookies, Inflate Net Traffic Estimates 217 comments
eldavojohn writes "In my browser, I regularly go to the tools menu and clear my private data. This includes my cookies. As a result, people like me who destroy cookies by the thousands may be inflating estimates of Web traffic by up to 150 percent. People have good reasons for clearing out cookies — we've heard about bad cookies before (and I think the FCC is still investigating the issue). But every time you delete cookies, many of the sites you've visited count you as a new visitor next time."
[+] IT: Encrypt and Sign Gmail messages with FireGPG 206 comments
Linux.com (Same owners as Slashdot) has a story up about FireGPG and says "Gmail may be an excellent Web-based email application, but there is no easy way to use it with privacy tools like GnuPG. The FireGPG extension for Firefox is designed to solve this problem. It integrates nicely into Gmail's interface and allows you...
Encrypt and sign Gmail messages with FireGPG
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Point-and-Click Gmail Hacking Shown at Black Hat 50 Comments More /

 Full
 Abbreviated
 Hidden
More
Loading... please wait.

  • Slow News day? (Score:5, Insightful)

    by OverlordQ (264228) on Friday August 03 2007, @09:15AM (#20100753) Journal
    Somebody intercepted plaintext on an open network . . . . did I miss something?
    • The funny thing is, gmail offers the ability to sign-in securely, but not an option to keep it SSL throughout the entire session. It works when you manually change the http to https in the url after signed in, but there is still brief moment of unsecured traffic during this process.

      • Re:Slow News day? (Score:5, Interesting)

        by zippthorne (748122) on Friday August 03 2007, @09:36AM (#20101095) Journal
        That's odd. I go to https://mail.google.com/ and at no time during the login process do I ever see the address bar go from yellow to white. Are you sure it still works the way you say? Or is it sending something unencrypted so fast that I'm just not noticing (which would be kind of worrying).

        • Re:Slow News day? (Score:5, Insightful)

          by tizan (925212) on Friday August 03 2007, @10:40AM (#20102173)
          I believe if you use https://gmail.google.com/ [google.com] (note gmail instead of mail) your whole mail session is always encripted and not the login page only.

              • Re:Slow News day? (Score:5, Insightful)

                by SanityInAnarchy (655584) <ninja@slaphack.com> on Friday August 03 2007, @02:15PM (#20105589) Journal

                Because this means more computing for google servers.

                This is Google we're talking about. They can take it.

                I mean, seriously, even an old 200 mhz Linux box set up as a server can do crypto at wire speed (100 mbit ethernet). I'm sure it takes them more cycles to spellcheck it for you.

                And also because your mail is sent as plain text to the recipient's mail server (and it came as plain text on google server). So it would be useless to crypt only the first (or last) part of the way.

                "Not entirely secure" is not the same thing as "useless".

                Consider: The majority of most websites are mostly served as plain HTML over HTTP. Is it still "useless" for me to admin mine using SSH instead of unsecured FTP? I think not.

                The point I am making here is, if your communications with Gmail are unencrypted, it makes it possible for someone to not only intercept the content of the message, but alter it -- they could, in fact, hijack your whole session, gain access to your archived mail, and send mail pretending to be you. All of this is theoretically possible with that SMTP connection between Gmail and another mailserver, but it's also insanely difficult to get anywhere close to what you can get by hijacking the session.

                And there's even a point to encrypting it, as opposed to just signing it. Well, two points, actually:

                1. Browsers include SSL natively, but there's no spec for just signing something and sending it plaintext. Therefore, it would have to be done in JavaScript, which is MUCH slower.
                2. SMTP is only used for connections between Gmail and other servers. Mail sent between you and another Gmail address is entirely secure, once it gets to the server. Why let people hijack your session and make it insecure?

                I mean, I tend to agree with you somewhat -- I only really do email from the one machine that has my GPG key, and I wouldn't use Gmail for more than backup. I don't see much point to webmail, because I never login to anything from a computer that isn't my own, because I don't like exposing myself to keyloggers.

                But even if it can't be very secure, why make it even less secure than it can be?

        • Re:Slow News day? (Score:4, Informative)

          by gpuk (712102) on Friday August 03 2007, @10:54AM (#20102397)
          That is the correct behaviour.

          Essentially, if you enter via http://mail.google.com/ [google.com] Google remembers this and encrypts only the login process and then reverts back to plain text. If you enter via https://mail.google.com/ [google.com] your session remains encrypted throughout.

      • Re:Slow News day? (Score:5, Informative)

        by Kartoffel (30238) on Friday August 03 2007, @09:37AM (#20101105)
        That's easy enough to fix with a Firefox plugin: http://www.customizegoogle.com/ [customizegoogle.com]

    • Bottom line (Score:5, Informative)

      by Kadin2048 (468275) * <slashdot@kadin.xoxy@net> on Friday August 03 2007, @09:26AM (#20100921) Homepage Journal
      I think the upshot of this isn't really "look at us, we can sniff plaintext Wifi connections," but "look at one of the biggest players in web mail use plaintext connections even though they ought to know it's a hideously bad idea."

      It's more of an indictment of Google than anything, because they default to unencrypted HTTP rather than HTTPS, and most users won't know that they can go to https://mail.google.com/mail/ [google.com] to force smarter behavior.
    • I'd be a lot more impressed if they had altered Doug Song's toolsuite from 7 years ago to use wifi at layer 2.

      Dsniff / Monkey in the middle attacks [monkey.org]

      • Re:Slow News day? (Score:5, Informative)

        by Anonymous Coward on Friday August 03 2007, @09:28AM (#20100951)

        if the traffic is sniffed as the browser is sending the SSL requests, one could sniff the SSL key and just use that to get in.
        You have no idea how SSL works.

      • Re:Slow News day? (Score:4, Informative)

        by The Velour Fog (1087217) on Friday August 03 2007, @09:30AM (#20101007)

        Also, logging in via SSL doesn't always work either - if the traffic is sniffed as the browser is sending the SSL requests, one could sniff the SSL key and just use that to get in.
        SSL uses Diffie-Hellman key exchange [wikipedia.org] so no unencrypted key is ever sent

      • Re: (Score:3, Informative)

        by Aeiri (713218)

        This is the first time it's been compiled into an automated tool.
        No it's not, there's another that's better and it's been around for a long while. It was once Ethereal, and now called Wireshark [wireshark.org].

        • Re: (Score:3, Interesting)

          by Burz (138833)

          This takes way more work, and there will be a popup that says "This certificate has not been signed by a trusted authority, someone might be trying to sniff you out". No one with a tiny bit of computer security knowledge would fall for this, but a clueless user who clicks "Allow" on everything probably would be.

          And I try to educate everyone I know about handling certificate warnings. They are all worried about Internet insecurity, and I tell them their connection (assuming they have a clean systems) WILL be

  • Could be fixed easily by Google. Shame. (Score:3, Insightful)

    by OpenGLFan (56206) on Friday August 03 2007, @09:18AM (#20100795) Homepage
    This is shameful. It's 2007, Google. SSL has been a (reasonable) standard since 1996. USE IT.

    • Re: (Score:2, Informative)

      by ohearn (969704)
      Gmail will use SSL over any browser, it just doesn't by default (which is a shame, but easily fixed for those of us that care)
    • They offer it. All you have to do is go to https://mail.google.com/ [google.com] rather than http://mail.google.com./ [mail.google.com]

      I fail to see how the average person, as usual, being lax about their security is in any way Google's fault. This was something I found immediately, just because I won't check my email without a secure connection.

      • Re:Could be fixed easily by Google. Shame. (Score:5, Informative)

        by Bob 535604 (871095) on Friday August 03 2007, @09:30AM (#20101005)

        I fail to see how the average person, as usual, being lax about their security is in any way Google's fault. This was something I found immediately, just because I won't check my email without a secure connection.
        A lot of people wouldn't know about this or even look for it and you know it. Google could make https the default or even mandatory, and it would completely kill this entire issue.
      • A huge part of security is having sane defaults. If you support 'secure' and 'insecure' you should default to 'secure,' and let users who know what they are doing, and need 'insecure' behaviour opt into it. You shouldn't default to 'insecure' and make it the users' responsibility to select 'secure.'

        • It's not Google's fault... (Score:4, Funny)

          by overeduc8ed (799654) on Friday August 03 2007, @10:07AM (#20101631)
          It's not Google's fault -- gmail is still in beta! :)

          • The user must take responsibility for their own security.
            Yet we turn around and lambaste Microsoft for allowing users to run as Administrator by default, having no-password logins, not locking down the registry, and allowing 3rd party developers to still require admin privileges just to run a userspace application.

            The point is, security is more than just "what's available." It also has to be about how good the defaults are. The technical community cried foul when Microsoft included a firewall in Windows XP but didn't have it turned on by default, and we complained so much that in SP2 Microsoft finally changed the default.

            I agree that security is ultimately the responsibility of the user, but they should not have to seek out secure settings and turn them all on one by one. The default mode for any network-enabled program should be Secure. If the user needs Insecure, then they should have to change a setting to make it so. Spam should be opt-in, security should be opt-out. Anything else is unfair to the user.

      • Re: (Score:3, Interesting)

        by BewireNomali (618969)
        correct me if I'm wrong, but don't most who complain about microsoft OSes point to prior defaults to administrator privileges as a major security concern? If so, by that same reasoning, shouldn't web services default to more secure configurations as opposed to less?

      • Re: (Score:3, Interesting)

        by fbjon (692006)
        They shouldn't tell anyone, just transparently redirect to the secure URL. Sane defaults, and all that jazz. Or at least semi-transparently, with a "redirecting..." page that has a link to both encrypted and unencrypted login URLs, in case some network blocks https.

  • Correct me if I'm wrong but (Score:5, Informative)

    by trifish (826353) on Friday August 03 2007, @09:21AM (#20100825)
    Even if you don't have encrypted transfer, session cookies can be easily secured by associating them with a certain IP address. The attacker who captures the cookies has a differnt IP address so the cookie is rejected as invalid. The only situation where this solution may get a bit annoying is if you're behind a load-balancing proxy, which changes your IP address on every request (fortunately, this is somewhat rare.) It's better than allow easy hijacks...

    • Re:Correct me if I'm wrong but (Score:5, Insightful)

      by Stile 65 (722451) on Friday August 03 2007, @09:26AM (#20100901) Homepage Journal
      If the hijacker gets on your wireless AP, then he's NATed behind the same public IP address as you. Voila, he matches your IP. Another layer is to also fix the session cookie to the browser's UA string, but that won't work if the attacker knows you're doing it and changes his browser's UA string to match yours. In summary, secure your wireless AP if you're a user and buy some SSL acceleration hardware so you can support forcing all traffic on your website to use SSL if you're a service provider.

      • Re: (Score:3, Interesting)

        by TheRaven64 (641858)
        Even if he's not NAT'd, if he's on the same WLAN then he's on the same broadcast segment as the real owner of the IP, so he can just send packets claiming to be from the legitimate user and run his interface in promiscuous mode to grab the replies.
      • In summary, secure your wireless AP if you're a user and buy some SSL acceleration hardware so you can support forcing all traffic on your website to use SSL if you're a service provider.

        I agree with the latter recommendation about using SSL, but saying 'secure your wireless AP' doesn't do a lot to help the many public wifi locations; I think it's unhealthy to ever assume that a wireless connection will be secure. As more wireless networks are rolled out, and more people get laptops with built-in wireless and traipse happily from home to their local coffeeshop, where they're sharing an IP and an unencrypted connection with many untrusted users, opportunities for sniffing and hijacking are only going to become more common.

        As users demand more portability, security and authentication need to be moved (and kept) up at the application layer, and not simply assumed as part of the datalink or physical layers.
    • I've just read TFA and realised that all people in the room were sharing the same IP address, so what I described in parent post wouldn't help. The only thing they can do is force SSL to all requests.

    • Even if you don't have encrypted transfer, session cookies can be easily secured by associating them with a certain IP address. The attacker who captures the cookies has a differnt IP address so the cookie is rejected as invalid.
      More often than not, all users of a wireless net is behind a NAT device, which makes all the devices have the same official IP. The same applies to most domestic, workplace and school wlans, so really, that would make little or no difference. Now, in a IPv6 world, it would make a difference, since everyone has a unique IP there...
  • I don't have the extension that forces it to use SSL, but all you have to do to force the connection manually is add the 's' after http, and the session will reload under SSL. Hopefully you haven't already been compromised at that point.

    I'm going to look for the Firefox extension now...
  • I'm sure everyone's going to bitch about how Google should use SSL for everything. And from a marketing perspective, maybe they should.

    But the openness of your wireless network really isn't their problem. You don't blame the banks if you shout your PIN out while you're at the ATM, do you? Or, more aptly, you don't blame the bank if you trust your ATM card and PIN to some stranger in a coffee shop.

    It isn't Google's responsibility to secure your connection end-to-end. It's far more reasonable to think that it
    • That's dumb. An application should never assume that the network it's connected to is secure. It doesn't matter whether you're plugged into switched Ethernet, a wireless LAN, or IP over carrier pigeon -- if you're designing an application that's going to transmit sensitive/assumed-private data (which email clearly is), it's a mistake to just blithely assume that the network is in any way secure.*

      An application like Gmail should be treating all network connections as though they're unencrypted Wifi (or hubbe

  • Always use https://gmail.google.com (Score:3, Informative)

    by StandardCell (589682) on Friday August 03 2007, @09:35AM (#20101079)
    Although they don't have a public key scheme strong enough for the AES-256 (requires 15360-bit RSA or 256-bit ECC for public key), you should always be logging in using https://gmail.google.com/ [google.com] from all locations (even home) to ensure the entire session is encrypted.
  • if you put a https instead of http for gmail.google.com it'll work. I dont understand why they don't do this by default if they already support it.

  • Easy fix (Score:3, Informative)

    by teslatug (543527) on Friday August 03 2007, @09:56AM (#20101435)
    Bookmark the secure address and use that (who wouldn't over open wireless??). You could also use http://www.customizegoogle.com/ [customizegoogle.com] with Firefox if you're using Gmail to force it to go to the secure URL.

  • Make it default to https (Score:4, Informative)

    by ajs318 (655362) <{sd_resp2} {at} {earthshod.co.uk}> on Friday August 03 2007, @10:31AM (#20102029)
    #  This is how I did it:
    #
    #  Actual snippet from my Apache configuration .....  mostly.
    #  Some details have been changed to protect the innocent
    #  And some details have been changed to protect the guilty
    #
    #  The virtual host "secure.mydomain.co.uk" cannot be accessed
    #  by http; only by https.
    #
    #  The insecure port
    <VirtualHost 10.11.12.13:80>
        ServerName secure.mydomain.co.uk
        DocumentRoot /var/www/
        <Directory /var/www/>
            RedirectMatch ^/[^iI] /insecure/
            # In this directory is a page with a dire warning
            # that https is required to access this server.
            # NB.  To avoid creating an infinite loop, we never
            # redirect if request begins with I or i.
        </Directory>
    </VirtualHost>
    #  The secure port
    <VirtualHost 10.11.12.13:443>
        SSLEngine on
        .....
    </VirtualHost>
    • Under server settings for your mail account, make sure either TLS or SSL is selected if you want to ensure that your connection is encrypted. I think TLS, if available is the default. On servers that support STARTTLS, this is OK, but it won't warn you if your server does not support it. Its better to try the forced TLS, and if you get an error, try SSL. If you have to switch back because your server does not support either, at least you know its insecure and can change your behaviour on insecure networks to

    • Yes, it is. (Score:5, Insightful)

      by Kadin2048 (468275) * <slashdot@kadin.xoxy@net> on Friday August 03 2007, @09:46AM (#20101245) Homepage Journal
      You're right that the exploit itself really isn't that new. What's new is twofold:

      1) It's being done to Gmail, a service provided by People Who Should Know Better.
      2) There is now a tool that allows any script kiddie to do it, meaning that it's no longer a theoretical exploit; it's something that your next-door neighbor is going to be doing to you (or your slightly less-technically-savvy family/friends) if you don't take precautions.

      #2 is probably most significant, since it's really what's going to cause #1 to change. Sometimes, producing a GUIed, Windows-based exploit tool is the fastest way to get a problem fixed, because it's the easiest way to turn an academic argument into a real-world security issue that will get resources thrown at it. (Of course, it may also land you in jail.)

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2009 Geeknet, Inc.