Session hijacking with firesheep

My understanding is that this grabs the cookies independent of the browser *I* am using. In other words the Nasty Person using Firesheep and Firefox can get my cookies even if I am using Safari, etc. Is this correct?

I live in a small town in the backwoods of Brazil. Someone just hacked (changed the icon) of a friend's livemail, while she was on. It's almost viral, the speed it's spreading. Pity the linux version does not exist .... :P []'s

From what I read, correct. []'s

virtual o/s and bob's your uncle

I was born lazy and been tired for ..... I was probably born tired too. Too much effort just to read OP's private letters. People are boring. I'll wait for the linux version. :) []'s PS -- You are right about the virtual OS, of course.

Not cookies (plural). It only needs the session initialization cookie. Firesheep comes with a collection of scripts for various online services needed to extact the cookie.

How it works and a somewhat inept attempt at using it:

Note that a stolen cookie only works as long as the original user, that created the cookie, is logged in. When they logout, the cookie becomes useless and the hijacked session dies. That means an effective but ugly countermeasure is to login and logout many times during an online session.

Countermeasures, of sorts, are being thrown together:

So far, with the obvious exception of logging in and out multiple times, all of the countermeasures are FF add ons? This leaves all other browser vulnerable?

Yes, all browsers are vulnerable. Including firefox. The problem is the method the sites use to check you are logged in. They send a cookie, and the browser stores it , and uses it to say you are still connected. These cookies have to be there, or you would have to type your password in, every time you change a page. (how I hate that!), one "cure" would be to make a random algorithm for each session, constant for that session. Like this: live.com sends a cookie, the "session add-on" makes a random hash, using the algorithm,then sends it back. Next page visited, the browser sends the hashed cookie, hashed by the same algorithm AGAIN. The site checks the cookie has been double hashed, by the same value, before sending the data. Ad-infinitum, until you end the session. When the algorithm is deleted. Hard to reverse engineer a random algorithm in the time it takes for a hacker to hi-jack your page. If the fire-sheeper sends the original cookie, without the right hash, he gets an error message. Better still, a slow reply. []'s

The counter measure detailed above uses a bug in Firesheep. That's not going to last. It also won't work in a coffee shop that has "AP isolation" or "client isolation" enabled in the wireless router.

The browser is not specifically vulnerable. It's the web server, that dispenses "portable" cookies, that's the problem. If your wireless traffic is not encrypted, it is possible to grab the session initialization cookie, which is how the web server identifies you as having successfully logged in. I can copy this cookie to another machine, run a completely different browers (and operating system), and hijack your online session. As long as the web server doesn't use the machine hardware, operating system serial number, CPU serial number, or something unique to your system, you're screwed. (Note: This should offer a clue for a possible fix for the web server).

Which, natch, will be used as an excuse by all those App writers for the iPod that (invisbly to the user) send across the unit's individual hardware-coded ID...

The solution to the problem if the server owner want to fix it. I am wondering what *I* need to do to protect myself. Currently, the only way for ME to be proactive is to use a VPN or one of the FF add ons. Is that correct. There is no way to self innoculate (so to speak) with other browsers. Also, I am not clear if this is still a problem if the WiFi is protected. Many of the Holiday Inns (for instance) now require you to sign on. Can it still sniff me out?

Jeff Liebermann wrote in news: snipped-for-privacy@4ax.com:

again.

independent of the

Firesheep

etc. Is

initialization

various

original user,

the cookie

an

many times

I use Tor, but Tor with wireless is frequently slow and unstable. Also I do not trust the Tor node operators as anyone, criminals or pedophiles alike can run a Tor node, as can government agencies anonymously. SSL with Tor is encrypted end to end so supposedly cannot be hijacked.

Ummm... there are no apps for the iPod. There are apps for the iPod Touch and the iPhone. I'm not sure what this has to do with session hijacking.

It can get worse: "Android App Sends Personal Data to China".

Or, prehaps you might enjoy the microsoft scheme of having the government license users, which I'm sure can be extended to include web servers. It's for your own safety and security, of course.

The trick is to not allow anyone sniff your traffic. For wireless, that means SSL, HTTPS, SSH, TLS, VPN, etc. I believe (i.e. not sure) that Gmail is currently safe because all their traffic is encrypted.

There's also a potential problem of someone sniffing traffic on a wired ethernet or DSL line. Neither of these is encrypted and is therefore subject to sniffing. Cable modem traffic is all encrypted and is therefore safe. Ethernet through a switch is also slightly difficult because each port only sees its own traffic, not everyone elses.

It is NOT a problem if you're using encrypted wireless. Holiday Inn is using a RADIUS server to issue unique logins and associated encryption keys, which will quite effectively prevent sniffing. However, if you 're using a shared WPA or WPA2 key, you're potentially in trouble because the evil bad guy with the sniffer might have the shared key. All he needs to do is capture the encrypted sniffed data, and decrypt it later with various tools.

My mistake. I meant the iPhone.

The point was that there are many Apps that currently, unknown to the user, send across the UDID. Which, natch, can be used for tracking across multiple web pages and other ugly stuff.

(Kind of like a super cookie.).

Anyway, this recently got into the news and Apple is under a bit of a cloud. But... they can respond that sending the permnanet UDID is a way of verifying that the end user (or at least the end unit) is the same one that initiated the session.

Someone has reading the group and then in the local sunday paper made a big deal from it ..

Not so, here.

Firesheep on a Macbook with OS X connected to an open AP. Start Capture.

Logon to Hotmail, and later to New York Times - my two accounts, where java scripts come pre-installed - with Windows XP and IE8 on a Thinkpad, and with OS X and Firefox on a PPC Powerbook, both connected to the open AP.

In both cases, I could log out, but the session cookie still gave me control over the account from the Macbook.

I've also tried it with a hub. Same results.

There are no counter measures, that the victim can take.

However, most open AP's (here in Denmark) use L2 Separation (sometimes called L2 Isolation). This would prevent the attack, because the AP works like a switch, isolating the clients from each other.

Yes. The AP the functions like a switch, isolating the clients from each other.