Liar, Liar, Sheep on Fire

Discuss

31 Responses to “Liar, Liar, Sheep on Fire”

  1. Anonymous says:

    Does this work over SSL? It seems to me that it must only work over normal http…

  2. davidkris says:

    There are a few different approaches that people can take to protect themselves. Most are over the technical abilities of most users unfortunately.

    One simple option is a Firefox plug-in http://www.getCocoon.com and it provides secure SSL encryption on any connection and is literally just download and go, instant protection. Full disclosure, I do work for the company, but the product is in beta and free, so give it a try and please share your feedback. Thanks! David

  3. Dan Tentler says:

    How to firesheep before firesheep:

    atenlabs.com/blog/how-to-steal-facebook-authentication-cookies/

    I wrote that back in June, but the actual vulnerability is inherent to ALL PHP SITES.
    Well, all php sites that don’t encrypt, anyway.

  4. Hybridan says:

    Thankfully I am currently using a secure connection so I can log in to boingboing, a site that can be sidejacked by Firesheep easily. For those of you wanting to try this, you do need a wireless card which can function in passive or “monitor” mode. If in Windows you will probably need to use different drivers then your standard set.

    For those who care, the program is great. I have already helped different people understand how to be more secure in there lives. It is funny how a friend will not listen to what you have to say about security until you begin posting the warnings as him on his favorite social networking site. Also interesting is that many sites that have a mobile variant are vulnerable even if the non-mobile version of the site is not.

    I this program is most important not b/c of what it does (since many people have been able to do exactly what this program does for several years at least) but because it makes it so incredibly easy. Btw, I will not list them, but not all banks are protected from this type of exploit, although they all should be.

  5. bitman362 says:

    Seems to me the security issue is inherent in the wireless router, not the web hosting service.

    addressing the issue where it is broke would be more effective than shotgunning the upstream services.

    Secure encryption between the pc/laptop/smart-phone and the wireless router would close this hole.

    So how about an SSL-like security protocol for each connection on ‘open’ wifi networks?

  6. Nawel says:

    Thanks for bringing this into the attention of the less tech-savvy among us.

  7. Anonymous says:

    OK, now explain how the average web user is supposed to protect themselves. Specifically, what are the settings for our laptops and where exactly do we go to set them????

  8. Anonymous says:

    I installed this on my mac and a day later Virus Barrier caught it as a virus. I uninstalled either way.

  9. sheepdawg says:

    The problem with HTTPS everywhere, unfortunately, is that you need a trusted signature signing authority. Currently, as I understand it (and I only know this second hand, so correct me if I get some details wrong), you need to pay several hundred dollars a year for one of the commercial signing authorities to sign your SSL cert and allow for easy HTTPS. Otherwise, if you run a small website and want to use HTTPS, you’re users will get an ‘untrusted certificate’ error.

    This is of course not an issue for a big company like Facebook or Google, but a big problem with universally extending HTTPS to the entire web ecosystem.

    • codesuidae says:

      The problem with HTTPS everywhere, unfortunately, is that you need a trusted signature signing authority.

      Are you sure about that? Can sites not self-sign their certificates?

      That obviously loses some of the features available with a trusted signing authority, but still gets you some useful features.

      • dragonfrog says:

        Can sites not self-sign their certificates?

        That obviously loses some of the features available with a trusted signing authority, but still gets you some useful features.

        I would argue they lose nearly all of the security benefits of SSL, and even makes it worse for users of sites that implement SSL properly, by getting them used to ignoring SSL errors.

        • codesuidae says:

          I would argue they lose nearly all of the security benefits of SSL

          I’d like to know more about what you see as the benefits of SSL.

          For most traffic all I need is to know that the communication to the server is encrypted so that other users at the coffee shop or whatever can’t hijack the connection or see what it is carrying.

          For my bank and other such high-value systems obviously I want a greater level of security where there are more reliable protections against more sophisticated types of attacks.

          • Chesterfield says:

            For most traffic all I need is to know that the communication to the server is encrypted so that other users at the coffee shop or whatever can’t hijack the connection or see what it is carrying.

            Your communication to the server will be encrypted all right. The problem is you won’t know what server you are connected to. It could very well be that hipster looking dude over there playing man-in-the-middle with his laptop.

          • codesuidae says:

            The problem is you won’t know what server you are connected to.

            Can you explain briefly how SSL with certificates signed by a signing authority prevents a man-in-the middle?

          • dragonfrog says:

            Did Glenn Fleischmann’s explanation make sense to you?

            Just to reiterate – that’s what the CA signing process is for – it’s the CA certifying that they have verified that the person who submitted the certificate request to them, is in fact
            - who they claim to be (in the case of a personal cert such as you might use for email encryption), or
            - a legitimate operator of the domain name for which they requested the certificate (in the case of a certificate for a server)

            So, now, you enter https://bankofamerica.com in your browser’s address bar, and hit return. The browser requests the OS to make a DNS query, to look up an IP address based on the name, but that result could be incorrect due to error or deliberate tampering. The browser makes a connection to that IP address, but that connection could also be misrouted due to error or deliberate tampering.

            Now, the browser establishes the SSL connection. It checks that the certificate is for the host name bankofamerica.com, that the period of validity of the cert hasn’t expired, and that the cert is signed by a trusted CA.

            If all that holds, then the browser will let the connection proceed without alerting you of an error, having ascertained that
            - It is in direct, untamperable, unsnoopable contact with a server that is in possession of the certificate that was just presented to it.
            - The host name in the certificate matches the host name the user intended to connect to.
            - The certificate is currently valid.
            - An organization this browser (or operating system) is configured to trust has certified that the certificate presented to the browser, was requested by a person who was entitled to make such a request on behalf of the Bank of America.

            That last statement is actually somewhat weaker than the others – a basic certificate only certifies that they’re entitled to make the request on behalf of the domain bankofamerica.com. An extended validation certificate (if I’m remembering the term correctly) will extend to cover what corporate entity is making the claim to the domain name. Modern browsers will display additional information when they see an extended validation cert.

          • Glenn Fleishman says:

            Browsers and operating systems come preconfigured with certificate authority information to bootstrap SSL/TLS. CAs can sign other CAs, too, through chained certificates, allowing the use of CAs not included in a browser/OS as de facto valid.

            When a browser and server initiate an SSL/TLS connection, the browser can opt, using the CA information that it has built in or from the OS out of band (not in the same communications channel that could be compromised) to contact the CA to validate the server’s certificate information.

            A man in the middle would need a valid certificate for the domain signed by a valid CA in order for the browser to accept that security is established. There have been social engineering attempts, and also some revoke CAs that improperly issue certificates without checking the identity of the party requesting it. (There’s a certificate revocation process, too.)

            A man-in-the-middle with a still-valid certificate for a popular domain signed by a still-valid CA (before it’s discovered) could compromise connections if it could also poison ARP and potentially poison DNS!

    • dragonfrog says:

      Yes and no, sheepdawg.

      The key term in “HTTPS everywhere” is actually the “Everywhere” part. The vulnerability Firesheep targets is the use of authentication cookies sent without SSL, after a login process that (typically) used SSL for the credentials themselves.

      It’s true that SSL certificates cost a few hundred bucks, which can be an issue at times for smaller sites, but this is targetting sites that already have SSL certificates, but design their sites to not use that SSL protection completely.

      Oh, and @IPFREELY – If you’re on a small coffeeshop network, the odds are very high that the WiFi network will use private addresses, and everyone in the place will be NATed to the same Internet-visible IP address once their web traffic hits the Internet. At that point, you and the cookie-hijacker at the next table have the same IP anyway. And, depending on the NAT scheme, it’s quite easy for a single internal computer to bounce around from one Internet-visible IP address to another, inside the expiration lifetime of a cookie (to say nothing of walking down the block from the coffeeshop to the library).

  10. IPFREELY says:

    I remember reading an article a while back, in which there was an interview with an undisclosed source working at Facebook. I could have swore that they were using coded storage to prevent theft and manipulation, but yeah, there’s some other old school tracking software and even Microsoft has free TCP monitoring. Can the same cookie be used by multiple IPs?

  11. Cowicide says:

    It should be noted that Hotspot Shield is actually Adware, not Freeware.

  12. marco antonio says:

    Um, I’m installing AnchorFree and came across this on the EULA: “It is AnchorFree’s policy to respond to notices of alleged copyright infringement that company with the Digital Millennium Copyright Act, For more information, please go to AnchorFree’s DMCA Notification Guidelines.”
    Isn’t that a bit ominous from a supposedly anonymiser/secure service? Makes it sound like AnchorFree is a honeypot rather than a serious service… am I wrong or paranoid on this one?

  13. pato pal ur says:

    It’s not only coffeeshop Wi-Fi you should be concerned about – don’t forget about securing your home router as well with a crytopgraphically-strong password.

    • Chesterfield says:

      pato pal ur, a strong password isn’t going to help you if you are using WEP. In fact, you can probably crack WEP in less time than it takes to enter your cryptographically strong password.

      Use WPA with a strong password.

  14. Anonymous says:

    If I would like to catch weirdos all over the net, I`ll create service that will offer anonymity

  15. Clemoh says:

    I have some policy blocking ad ons (ie requestpolicy and betterprivacy) and windows can’t get this add on to work. I guess I’m safe lol?

  16. semiotix says:

    I don’t know nothin’ bout no SQL/MAC/HTTPS/VPL/SSL/LOL juju, but I do know that tempting people with free software that would let them snoop on or log in as other people in the room…

    …would be a great way to trick people into downloading your malware. :)

  17. BungaDunga says:

    I’ve wondered about this vaguely for a while- at my school, the wifi is unencrypted. You need to register your MAC to get on, but it’s not actually encrypted.

    In other words, Firesheep should work beautifully here. My wifi card doesn’t seem to like it, though, so I can’t say for sure.

  18. flosofl says:

    If you have access to a server that accepts SSH connection (and can get to the internet), you can always set up a SOCKS5 proxy using ssh. It’s pretty straight forward (I’m using port 9999 as an example)

    ssh my.ssh-server.net -D 9999

    In your SOCKS aware programs (email, browser, etc…), set the SOCKS5 proxy as localhost:9999

    It’s not as good as having a VPN with a proxy at the other end, but it will work in a pinch.

Leave a Reply