Researcher raids browser history for webmail login tokens

In a disclosure that has implications for the security of e-commerce and Web 2.0 sites everywhere, a researcher has perfected a technique for stealing unique identifiers used to prevent unauthorized access to email accounts and other private resources. Websites typically append a random sequence of characters to URLs after a …

[Anders Jensen]

Frozen?

uhh, won't your browser be frozen for 2 minutes then ? I'm not gonna let a webpage load for that long (the examples i've seen of the history sniffing freezes my firefox, at least).

[Anonymous Coward]

Simple Fix

Use Firefox. Set options to delete everything when a session is closed. When going to a site where money or personal accounts are going to be accessed, bring up a browser from scratch and visit no more than 1 site per browsing session. Paranoid? You betcha. There people far smarter than I out there.

Beer, for the money you don't hand over to hackers, crackers, whatever they are calling themselves these days.

[Adam Foxton]

So you just need

a 20-character code and it'll take vast amounts of time until someone invents a useable quantum computer? Doesn't sound too bad.

Is there any way of seeding your history so the CSS History Hacking throws up some sort of token that can be used to track down whoever's trying to get your details? Sort of a reverse-Spam (i.e. you're sticking unwanted, unneeded crap on your computer); they'd read off that I'd been to a secure page on, say, egg.com (which isn't my bank in real life or the example) and the bank's website had used token ABC123.

Villian then goes off and tries to connect to egg.com with token ABC123, it's flagged up by a program on egg's computers and details of the computer used to try to connect are recorded or sent off to the police or whatever.

Bish bash bosh, job's a good 'un, villian is known or can be tracked down.

[Sebby]

Nothing for it

All forms will henceforth be sent using POST, over SSL, and javascript will be checked for and if found the operator of the browser will be told how important it is to turn it off.

Really, it's getting stupid, you can't run a browser for five minutes without the latest web 2.0 threat poised to squish you.

Cheers,

Sabahattin

PS: hang on, how about a web tag that says, "Stop following me everywhere for my domains/subdomains"?

[Jeremy 2]

Erm...

I have to admit that I haven't thought very much about this and I'm tired and hungry but two points spring to mind...

1) Nobody with any sense would pass the session token for a security critical application in the query string these days. You'd use a cookie instead, precisely so it doesn't appear in the user's history, etc. This is especially true because we're in an age where nobody thinks twice about sharing URLs with their mates, Twitter, their blog, etc and you can bet your bottom dollar that the vast majority don't take care to remove session tokens from URLs before doing so even though sessions can remain valid for weeks or months.

Put the session token in the URL and you deserve to end up with it all over the web. The proportion of people who have cookies blocked these days is so close to nil as makes no odds. There's no point coding to a 'no cookies' requirement in the same way there's no point coding to a 'IE3 compatability' requirement.

2) Anyone who doesn't hash the supplied session key with (for example) the user agent string and IP address of the expected client and use *that* key for login verification is an idiot. There are of course other things you could do to be more sure that you're communicating with who you think you are but at the very least, applications should be comparing the client IP address with the one that was used during login. Again, so few people use rapidly changing dynamic IP addresses these days as makes no odds.

[Anonymous Coward]

This is nonsense.

Most tokens are about 20 ascii / base 64 characters, for crying out loud. Showing that you can brute-force five base16 characters does not really prove a weakness. That took two minutes, and how big was the CSS file with those over-three-hundred-thousand entries? Trying to enumerate any halfway-decent long UID is one of those not-enough-atoms-in-the-universe problems, it aint gonna happen, and this toy demonstration doesn't prove anything. It's like saying that you can easily brute-force a 1-char password - well duh, don't use one char passwords! I'd like anyone to name a real website that uses a five-char identifier.

[Inferno]

Inferno here...

@Anders - no your browser won't be frozen, that is why i put setTimeouts in PoC. you can put some nice content in a post, or run a pirated movie site, etc. anyway, 2min is for searching entire key space, and attacker might discover your token early

@Anonymous - nice suggestion and too secure....

@Adam, nice idea, but really this attack will run on your vulnerable client, who just accidently visits a evil site. So, it will be poor guy going to jail. if we think more, we can work it out :)

@Sebby. LoL..

Cheers,

Inferno

[Inferno]

Inferno here...

@Anonymous Coward - you should understand security before making any accusation. This token is not sessionid, but your csrf protection token. your sessionid will be automatically sent by browser in every request if you are authenticated. Regarding your CSS file argument, please first go and check out the proof of concept code. you won't see any hardcoded token there.

If you need real world examples, check out the last comment on the post on my site.

[Anonymous Coward]

Hotlinking & referrer URLs

I was recently looking through the logs of my website to find out who was hotlinking images, then remove ot swap out those images to mess with the hotlinkers (hey, geeks get bored you know!), when I noticed some of the referrer URLs contained an encrypted password with plaintext username.

So I copy'n'pasted one of referrer URLs into my browser and discovered I has signed into a chatroom as someone else completely.

The funniest thing about this was that the chatroom is on a conspiracy theory website. :D

[Whitter]

Different browsers for different tasks

Bizarrely, the most insecure browser (IE) is the one I use for all 'secure' transactions - mainly 'cos you have to - thanks to sloppy website design.

Which means I've ensured that IE remembers nothing; blitzs all cookies, temp files, history, the lot, every time on shut-down. When I'm going to do anything on any website that involves a meaningful password / transaction, its fire up IE time - fresh as it is, use it for that task only, then shut down and wipe.

For usual browsing - use something else, operah in my case (mainly for the mouse-gestures, though there's probably a copycat Firefox download for that yada yada...)

[TeeCee]

Re: Frozen?

Nah, most users'll just think that the site's trying to load a bit of Flash.

Note to e-tailers. Getting a blank screen with the word "loading" and a progress bar in the middle does not leave me breathlessly awaiting the mind-numbingly fantastic multimeeja UI experience I am about to receive*. It does make me piss off sharpish to spend my money elsewhere. You know who you are.....

*However much your CV-polishing web monkey may tell you it does.

[David Hicklin]

VM it

I have a VM used *just* for my banking and nothing else (the p0rn is on another VM).

Paranoid? yes maybe but I am much happier that way around.

[Doc Spock]

Same Problems, Different Place

Dear God! How long has the security community known that short encryption keys can be easily brute-forced? A 64-bit key (8 base16 characters) has been insecure for well over a decade now.

Why are people still using weak keys in secure settings?

It's not f**king rocket science.

In fact, there's a whole field entitled "Security Protocols" which specifically caters towards secure communication over insecure networks and is designed to prevent things like replay attacks.

Of course, the real problem is that your "typical user" has no way of knowing their favourite site uses such pathetic security (and almost certainly doesn't care to check).

And then there's the issue that most webmail sites don't encrypt the traffic once you've logged in, so anyone on your network can easily read the e-mails you view and send.

</rant>

[George Marian]

RE: Same Problems, Different Place & VM it

@David

Same Problems, Different Place: Keep in mind that VMs may contain their own exploitable vulnerability. Don't be lulled into complacency; it's only a matter of time before exploiting VMs becomes a practical concern.

@Doc

Same problems, different place: Most businesses, unfortunately, operate with a good-enough mentality. Realistically, we have to come to some reasonable compromise between security, performance and ease-of-use. However, too often good-enough errs on the side of saving time/effort/money. Probably because it's easy to put a cost on the effort to implement and maintain software, but it's rather difficult to put a price on potential security issues.

[Jamie Jones]

@Jeremy 2

"1) Nobody with any sense would pass the session token for a security critical application in the query string these days. You'd use a cookie instead, precisely so it doesn't appear in the user's history, etc."

Even worse. Then there is no token for the evil hacker to guess! They simply link you to the raw url!