Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Security Encryption Firefox Privacy Social Networks Software Wireless Networking News

Firefox Extension Makes Social-Network ID Spoofing Trivial 185

Orome1 writes "A simple-to-use Firefox plugin presented yesterday at Toorcon in San Diego has hit the security world with the realization that squabbles about Facebook's changing privacy settings and various privacy breaches simply miss the point. 'When it comes to user privacy, SSL is the elephant in the room,' said Eric Butler, the developer of the extension in question, dubbed Firesheep. By installing and running it, anyone can 'sniff out' the unencrypted HTTP sessions currently allowing users on that network segment to access social networks, online services and other website requiring a login, and simply hijack them and impersonate the user."
This discussion has been archived. No new comments can be posted.

Firefox Extension Makes Social-Network ID Spoofing Trivial

Comments Filter:
  • Illegal? (Score:5, Informative)

    by Anonymous Coward on Monday October 25, 2010 @08:09AM (#34010574)

    I don't dispute author's work or goals (I've been using SSH tunneling on public WiFi for years to prevent just this) but he should have mentioned that clicking on information you gathered (and logging in as another user without their concent) is very likely against federal laws in US (and likely most other locations). Just gathering this information can likely be argued to be illegal as well (wiretapping?)

    So be careful where you click..

  • by buchner.johannes ( 1139593 ) on Monday October 25, 2010 @08:10AM (#34010578) Homepage Journal

    here: http://codebutler.com/firesheep [codebutler.com]

    They apparently call it "sidejacking", i.e. sniffing other users cookies from a wifi, and using it. Not new, but made userfriendly.

  • Re:Illegal? (Score:1, Informative)

    by Anonymous Coward on Monday October 25, 2010 @08:23AM (#34010642)
  • by pinkeen ( 1804300 ) on Monday October 25, 2010 @08:54AM (#34010838) Homepage
    It is wifi sniffing. The data is in the air. All you need is to be in the range of client's radio transmissions. If the network is encrypted then you need WEP/WPA(2) key.
  • by betterunixthanunix ( 980855 ) on Monday October 25, 2010 @08:55AM (#34010846)
    To be fair, most of those people do not actually care. There is a small minority of users who do care, but for some reason continue to use those websites; the rest just want to follow the crowd without stopping to question anything.
  • by Anonymous Coward on Monday October 25, 2010 @08:58AM (#34010854)

    It also misses the point that Facebook is about *SHARING* data. The idea is you are sharing things with people. If you want to keep things private ... Facebook is not the place to do it.

    If I do not want people to know something. It is simple I do not put it on the internet.

    Facebook has created this idea of privacy itself that it will never match. They did it accidentally by putting a login on the front page in the first place. People have an expectation of privacy when you have to log in. Facebook was just using it so you can post as yourself. Not as a privacy feature.

    Also people have a gut reaction of 'lets just ssl everything'. That is not practical. As ssl breaks caching of many things. By default ssl is not cached both on the browser and at many proxy servers (this is a good thing in many cases). But in this case that picture of you wolfing down hotdogs somewhere probably will never change. Yet it will not be cached if you pipe it over ssl. Not everyone has DSL or higher. There are people who are stuck on dialup and it will not get any better any time soon for them.

  • by Anonymous Coward on Monday October 25, 2010 @09:06AM (#34010930)

    "not hard". Well maybe not for your blog with 2 users per week. But for facebooks loadsize it's not a matter of signing up with digicert and enabling SSL.

    Facebook's issue isn't buying & installing a certificate, it's that they have so much web traffic that the CPU load of encrypting all that traffic (or buying dedicated encryption acceleration hardware) is significant.

  • by mbone ( 558574 ) on Monday October 25, 2010 @09:08AM (#34010960)

    What permissions do you need for this? Do you have to be the owner of the network in order to sniff things out in this manner? Or is it possible for me to steal accounts off a public network?

    None, no, and most emphatically yes.

  • by The Mighty Buzzard ( 878441 ) on Monday October 25, 2010 @09:11AM (#34010998)

    While I'm inclined to agree that any remotely commercial website should offer and default to encrypted transfers, it also serves you right if you use a service that doesn't encrypt everything. Using a service that doesn't at least offer you the option of encryption is akin to driving a car that you know has defective brakes (ha, car analogy!). If shit goes badly and you knew better, you've no one to blame but yourself. If you didn't know better, it's your own fault for not educating yourself about such basic things and I shall mock you.

    Unless you're a cookie baking grandmother willing to bribe me with baked goods. Principles be damned when there are fresh, warm cookies involved.

  • by thomst ( 1640045 ) on Monday October 25, 2010 @09:11AM (#34011002) Homepage

    here: http://codebutler.com/firesheep [codebutler.com].

    Steve Manuel of TechCrunch claims that the Force-TLS 2.0 [mozilla.org] Firefox extension can defeat Firesheep. (You have to configure it manually for each site you want to protect, though, so it's somewhat of a PITA.)

    Another option is the HTTPS Everywhere [eff.org] Firefox extension from EFF and the Tor Project. Although HTTPS Everywhere has a predefined ruleset that includes some of the most popular Web sites, you'll still have to write your own ruleset [eff.org] for any site not on their default list.

  • Re:How does it work? (Score:4, Informative)

    by will_die ( 586523 ) on Monday October 25, 2010 @09:12AM (#34011008) Homepage
    You first need to installWinPcap [winpcap.org] this is the program that does the actual work. You then log on to the wifi, using password if required, and the program starts looking for know cookies. If it finds them it captures the info and gives you a nice userfriendly way of using them.
    It can capture the wifi since anyone can capture them if you are within range of the transmissions. You if you are not monitoring when the signals go out you cannot capture them.
  • Re:https everywhere (Score:3, Informative)

    by skywatcher2501 ( 1608209 ) on Monday October 25, 2010 @09:28AM (#34011184)
    And here's the link: https://www.eff.org/https-everywhere [eff.org]
  • by muckracer ( 1204794 ) on Monday October 25, 2010 @09:34AM (#34011240)

    > Kudos to FaceBook and most other networks for NOT using encryption for anything but the log in [--DrYak]

    > I still have to manually change http to https in the URL every time they decide to sign me off. [--cindyann]

    Install the HTTPS-Everywhere FF Plugin. It will SSL-encrypt Facebook and a host of other domains. Only draw-back: Chat doesn't work via SSL atm.

    https://www.eff.org/https-everywhere [eff.org]

    And while you're at it, also install the BetterPrivacy Add-on:

    https://addons.mozilla.org/en-US/firefox/addon/6623/ [mozilla.org]

    which will get rid of the LSO cookie Facebook sets each time you use it. Best used in conjunction with AskforSanitize.

  • by maxume ( 22995 ) on Monday October 25, 2010 @09:36AM (#34011266)

    When Google switched Gmail over to HTTPS all the time for everything, they found it accounted for 1% of CPU load:

    http://unblog.pidster.com/imperialviolet-overclocking-ssl?c=1 [pidster.com]

    So Facebook probably wouldn't need to do much more than get their software set right.

  • by lavagolemking ( 1352431 ) on Monday October 25, 2010 @09:42AM (#34011304)

    Facebook does submit your information over HTTPS; they just load the page over HTTP by default. Passive sniffing won't work on it. Here, take a look at the following code from http://www.facebook.com/ [facebook.com]:

    <form method="POST" action="https://login.facebook.com/login.php?login_attempt=1" id="login_form">

    The problem with this approach is, while it saves server resources, an attacker could trivially perform a man-in-the-middle attack on an average person connecting to http://www.facebook.com/ [facebook.com] rewriting the above code to HTTP or running a squid proxy or something, and they would never notice because their browser says "http" like always.

    That said, if you're worried about it you could always install HTTPS Everywhere [eff.org] and it will make Facebook always load using SSL.

  • by Compaqt ( 1758360 ) on Monday October 25, 2010 @10:02AM (#34011506) Homepage

    Leaving aside md5 cracks (use another algo if you want):

    md5 the password with Javascript on the client end before sending it. Then un-md5 it with PHP on the server.

    Plenty of security-conscious CMS's have been doing this before Mark Z even thought of an electronic facebook.

  • by ogapo ( 1420605 ) on Monday October 25, 2010 @10:16AM (#34011648)
    I think you may not understand how a cryptographic hash works. In the scheme you are describing, the password is typically hashed on the client side (along with some value specified by the server which changes every time). When the server gets the hash, it hashes the password (as stored in the DB and possibly also hashed) along with the same value and compares the result. Regardless, what this plugin does is not steal passwords, but simply looks for authenticated credentials (usually cookies). See, once you authenticate, the server gives you a cookie (your session identifier) that you pass back with every request to prove you are who you say you are. Since the traffic is not encrypted, this can be intercepted by anyone on a network between you and the facebook servers. If you live on a college campus or work for an ISP, this could very well be many people. Even if Facebook is smart enough to tie this session to your IP, it's likely that someone in a correct network position to sniff your packets can also viably spoof your IP (both sending and receiving). This is effectively the same as them hijacking your account except the ability goes away when your session expires.
  • by Aqualung812 ( 959532 ) on Monday October 25, 2010 @10:27AM (#34011828)

    You have the choice - if you visit https://facebook.com/ [facebook.com] it will let you run your entire session on the site in https. They obviously support SSL for those who want it... I fail to see how it's their fault?

    Follow the link you attached. Log into Facebook. Click the Facebook icon on that page to return to your home page, or click on a link to a fan page you have, or click on a link to a friend's page. You just went from SSL to HTTP. They make it hard to STAY on SSL, even if you go through the work of going there manually.

  • by Stray7Xi ( 698337 ) on Monday October 25, 2010 @10:28AM (#34011846)

    What permissions do you need for this? Do you have to be the owner of the network in order to sniff things out in this manner? Or is it possible for me to steal accounts off a public network?

    You need to be administrator to place your network card into promiscious mode [wikipedia.org] or rfmon for wireless.

    So in a public wifi network you're screwed. In a public ethernet network it depends if it's a switched or hubbed network. But even in a switched network you could be vulnerable to this via ARP poisoning.

    The takeaway is what we've known for decades, if you want private communications use encryption.

  • by jwietelmann ( 1220240 ) on Monday October 25, 2010 @10:32AM (#34011920)

    Hash = 1-way crypto

    The only way to "un-md5" anything is to crack it. Also, I'm not sure you actually put any real thought into this.

    Since it's best practice to store only password hashes (and not the passwords themselves) in your database (or whatever), your process is apparently:

    1. Client md5's the password, sends it to server
    2. Server "un-md5"s the password (let's say for argument's sake that this makes perfect sense)
    3. Server md5's the un-md5'd password
    4. Server checks hash against user's hash in the database
  • by Mashiara ( 5631 ) on Monday October 25, 2010 @10:43AM (#34012106) Homepage

    You are missing the point.

    The problem is not reading the password as plaintext from the cookie (now that would be monumentally stupid design) but that since the cookie equals valid session authentication copying the cookie equals session hijacking (or sidejacking since the original cookie is still there on the original users machine).

  • by sznupi ( 719324 ) on Monday October 25, 2010 @11:07AM (#34012500) Homepage

    http://m.facebook.com/ [facebook.com] ...not saying the mobile browsers can't have the security, just that "hope" isn't required to render Facebook without js.
    And apparently such access is quite popular - there were some news from FB itself about explosive growth; also according to stats of Opera Mini [opera.com] (the #1 mobile web browser worldwide by site hits, despite many of its users being evidently rather frugal with numbers of sites visited / data transferred), Facebook is quite often near the top of popularity.

  • by KBJorgensen ( 1819456 ) on Monday October 25, 2010 @11:19AM (#34012672)
    The Chrome extension KB SSL Enforcer automatically redirects you to SSL every time you visit Facebook (and other sites) and changes all links to point to SSL. Although I do agree that they should just use SSL by default on a site with so much personal info. Disclaimer: I made this extension.
  • by Anonymous Coward on Monday October 25, 2010 @11:50AM (#34013178)

    Its pretty well documented which cards support promiscuous mode these days. You are correct that most drivers dont support it however. I have an ALFA

    http://www.aircrack-ng.org/doku.php?id=faq&DokuWiki=8a7d493ef4d8a6ce9779a7c8b2f0259a#what_is_the_best_wireless_card_to_buy

He has not acquired a fortune; the fortune has acquired him. -- Bion

Working...