Feeds

back to article The perfect CRIME? New HTTPS web hijack attack explained

More details have emerged of a new attack that allows hackers to hijack encrypted web traffic - such as online banking and shopping protected by HTTPS connections. The so-called CRIME technique lures a vulnerable web browser into leaking an authentication cookie created when a user starts a secure session with a website. Once …

COMMENTS

This topic is closed for new posts.
Gold badge

Evil.com

It exists. Don't go there.

0
0
Coat

Re: Evil.com

Unless you're using Internet Explorer, obviously.

2
0
Silver badge

Re: Evil.com

"Unless you're using Internet Explorer, obviously".

In which case it's your home page.

4
0
Thumb Up

The 'Thomas Pornin' attack.

Read the Security Stack Exchange blog post which Ars followed up on here: http://security.blogoverflow.com/2012/09/how-can-you-protect-yourself-from-crime-beasts-successor/

1
0
Paris Hilton

Re: The 'Thomas Pornin' attack.

That gets an upvote just for the name.

2
0
Paris Hilton

Re: The 'Thomas Pornin' attack.

I love a Tommy Pornin' in the morning!

0
0
Thumb Down

Theoretical ?

Relies on the attacker sniffing the packets - for example by being in the same coffe shop wi-fi - AND forcing you to visit a site hosting the malware. Proabably restricted to dodgy coffee shops.

1
2
Anonymous Coward

Re: Theoretical ?

So we should ignore it then. Thanks for that.

0
1
Silver badge
Facepalm

Re: Theoretical ?

You do realize that the whole point of HTTPS is to protect you in situations where the attacker can sniff your packets, right? Otherwise there wouldn't be much reason to use encryption in the first place.

4
0
Silver badge

Re: Theoretical ?

I never understood why they don't just wrap the real packets in fake packets so that the sniffers will only smell the outside fake packet not the real one inside. That would completely eliminate the threat of sniffers. I discovered this use of packet wrapping at college years ago so it's a surprise that so-called security "professionals" haven't latched onto it yet. Actually nothing much surprises me these days so

1
4
Boffin

Re: Theoretical ?

Because it's trivial for a sniffer to read the inner packet. Considering that your proposed "packet wrapping" protocol will have to be well known for a useful number of servers to actually support it, sniffers will know about it too.

It's called security by obscurity, and it works very badly.

3
0
Anonymous Coward

Re: Theoretical ?

Speaking as a security professional, I'm excited to hear about your packet wrapping idea. All it needs is a cool name and you're made of win. Maybe "SSL" or "IpSec" or something

0
0

Mitigation

If the web-site logs people out when the ip address presenting the session cookie changes then its going to be a lot harder for the attacker to do anything useful with the cookie even if they can steal it.

You might get spurious logouts if your device re-connects to a network with dynamic ip addresses but that is probably acceptable in cases where you care about security.

1
0
Silver badge
Boffin

Or...

Just don't use the stupid "remember me" checkbox on sites you're really worried about. Most of the sites I use that really need to be secure don't even have an option to store an authentication cookie.

0
2
Stop

Re: Mitigation

Doesn't work for large corporate environments where all traffic goes via a cluster of proxies; each request _could_ come from a different IP address.

Wouldn't solve the problem in the case of a cafe WiFi or a hotel where all the traffic might be NAT'd to a single IP address.

IP-binding of information has never worked too well; even in the early days of the web, all AOL-users would be proxied.

1
0
Silver badge

Re: Or...

Are you sure you understand how authentication works? HTTP is stateless, and without presenting authentication tokens on each request, like basic auth, or presenting a client certificate, the browser must be presented with and return an authorization token, usually a session cookie.

(Sidenote, its only authentication if you are presenting your credentials; if it is just allowing you access, it is an authorization token. An 'authentication cookie' would be a cookie with your username and password in it)

I need my bank to be secure, and that uses cookies. Unless service providers start issuing me with client certificates for authentication, that will always be the case - there is no other way for me to authenticate and subsequently be authorized for future requests.

I also think this behaviour could be easily mitigated by browsers inserting a different random arbitrary token into each request. This extra data would make it significantly harder to determine whether compression changes occurred due to the requested filename matching the session key.

3
0

Re: Or...

Easily mitigated by site sending a new authorization token after each request.

0
0
Bronze badge
Thumb Down

Re: Or...

"Easily mitigated by site sending a new authorization token after each request."

1. you obviouslt meant "authentication", not "authorization". 2. there is nothing "easy" about issuing new token for each request. You would need huge space of tokens and that implies large amount of data per token and large calculation cost creating and validating one.

Can be done. Easily? Don't think so.

0
0
Bronze badge

Re: Or...

I also think this behaviour could be easily mitigated by browsers inserting a different random arbitrary token into each request.

That's called a "nonce", and yes, it would help. If it varied in length as well as content, it ought to block the compression-size side channel completely. In general, this technique is called "whitening" (because it adds random noise to a channel, obscuring the signal).

It's a simple fix, and it's only necessary because the TLS designers didn't take the compression-size side-channel into account. This is the history of HTTPS, though: each new revision falls to some some side-channel attack. With HTTP 1.0, it was side channels that leaked the (pseudo)random information used to generate the session key. Later we had timing- and power-channel attacks. The more things change...

0
0
Silver badge

Re: The more things change...

Yep. A wise man once said 'Security is not a state, it is a process.'

0
0
Silver badge
Joke

Re: Or...

I'm British, so a "nonce" will always be a man that fucks children. Lets keep this discussion civil ;)

0
0
Facepalm

meanwhile, elsewhere....

BBC You and Yours discussion of online fraud and LloydsTSB.

A Doctor and his wife each had their accounts hacked in circumstances in which the fraudsters somehow obtained:

- BT land line number, BT account number, home address

(for divert, so could confirm setting up a payment )

- mobile phone number, presumably some other details (for divert)

- bank account details of both adults (two IDs; not the account numbers, two sets of memorable details)

this was presented as a bank security issue

1
0
Bronze badge

So if I have my non-HTTP traffic intercepted and modified by a piece of external hardware with complete sniffing capability over all the connections my computer makes, and then it modifies the HTML in those sites to include malicious Javascript (hell, by that point, they probably have my computer anyway, but let's press on...), that then brute-force tries this technique to reveal an locally-stored authentication cookie for another website that I go on (spotted by the external machine noticing the size of said brute-force requests changing), it might let them log into that HTTPS website as me.

Except most sites don't store such cookies (because of such risks as people who can log in as you being able to "automatically" get into your bank account just by sitting on the right computer) and let's be honest, if you're in the position where someone can sniff ALL your connections and inject malicious Javascript into a non-HTTPS site that you visit, it's already game over.

It seems hugely over-hyped and far-fetched for a flaw in what is obviously XSS measures in browsers (of which neither IE nor Opera are susceptible anyway, and when IE isn't susceptible you KNOW you had some dodgy logic in there in the first place) - why can Javascript push HTTPS requests to domains foreign to the original Javascript arbitrarily (I assume this is one of the "wonders" of being able to include Javascript libraries from arbitrary domains in your HTML that should NEVER have been allowed in the first place) and nobody running the browser notice when it fails thousands of times (shouldn't that pop up a connection error to the user, anyway)?

Like BEAST, it's a nice theoretical hit if you are really determined and have an extraordinarily dumb browser on the other end, but otherwise it's completely useless. And it's a side-channel attack. At no point does it actually attack the actual TLS except (possibly) in a kind-of-obscure "known plaintext attack" on the encrypted data (if you have compression turned on, and it does what you expect, which I'm guessing is NOT a given). And it's trivially defeated - again - by using a proper SSL library that pads out such things if they are in any way reflective of the original unencrypted data.

I'm fast becoming tired of the hype surrounding what is basically a "stupid browsers allow remote injected malicious code to do stupid things" attack like BEAST was.

4
4
Bronze badge

I agree this is being overhyped but it is very clever and I do rather admire the people who worked it out.

3
0
(Written by Reg staff) Silver badge

I'm with Lord Voldemortgage on this one. I don't think the Reg has gone bonkers over it, and it's a pretty neat trick.

C.

2
0
Gold badge
Flame

"..Internet Explorer is not vulnerable to the attack..."

The sound in the background is that of millions of flamethrowers backfiring simultaneously.

4
1
Silver badge

Re: "..Internet Explorer is not vulnerable to the attack..."

and the "cool kids" in the office laugh at me for using IE 7 still. They won't be laughing once their bank call them up and say "sorry the hackers got in through your browser and stole all your money" and then they will turn to me and ask "why are you so smug?" and I say "I was using Microsoft Internet Explorer 7, the browser you've all been bad mouthing for years but now guess who is invulnerable to hacker attacks on my bank? yes me." Never tried all those new chrome and google firefox browsers, never plan on doing so. Given I am using Microsoft Windows as my operating system, would I run a browser by a company who know nothing about Windows or the company that built it? not a tough question.

0
9

This post has been deleted by its author

Bronze badge

Re: Enquiring Minds Want To Know......

Loverock Davidson, Is that you?????

0
0
Anonymous Coward

Is it just me...

Or does the guy from Whitehat security not actually discuss the CRIME exploit at all, but instead some other exploit he's imagining?

ie; "I’m not at all familiar enough to comment on the details of this CRIME. My first thought when reading was if an attacker is positioned properly on the network to man-in-the-middle a user, they should be able to accomplish the same outcome using old school HTTP traffic injection techniques and perhaps also some XSS. That’s what I’d like to discuss here."

And he then goes on to discuss that ....

1
0
Anonymous Coward

Is it just the two of us?

Because no, it's not just you.

0
0
Silver badge

Bah!

Another attack facilitated by client-side browserbling tech?

Get Rid Of Useless Javascript Now!

3
1
Trollface

not a problem

My bank says the internet is secure.

4
0
Silver badge
Pirate

Re: not a problem

Don't worry, Checkpoint secures the Internet.

0
0
Silver badge
Facepalm

Re: not a problem

Sadly too true. While doing a refinance on a mortgage a short while ago to take advantage of the low rates I had the loan officer offer to email all the forms to me so I could check them, make corrections and send them back. You know the forms, the ones with a full credit check, so-so security, address, mother's maiden name, birthplace & date, etc. Basically an all in one new identity kit for anyone who might be interested in becoming me. I asked what encryption they used and she replied, "oh, we have secure email". Needless to say once I reclaimed my jaw from the floor I declined and told her it would be picked up in person. Worse yet, I couldn't get it through her skull that sure maybe their VPN might have some modicum of security and that a "secure login" to the server doesn't impact any server to server traffic or the rest of the internet.

I can only imagine what else passes out their mail servers to unsuspecting sods the world over. If the crooks were really smart, they'd sit on the mail servers and collect as much data as they could. I imagine it would be far easier than cracking a database even though the bank says it's "secure".

0
0
Silver badge

Re: "oh, we have secure email"

After that you went through with having your loan with them anyway?!?!?!???

I realize you probably had a significant chunk of time already invested with them, but I think I would have just walked away at that point. If they were that stupid with your application, what makes you think any of their other processes are better? Doubly true if they are just an originator who are going to resell your mortgage anyway, which unfortunately still seems to be the standard model even after the banking collapse.

0
0
Silver badge

Re: "oh, we have secure email"

I did because, believe it or not, they were the best* of a bad lot. The previous four banks I tried were as bad if not worse. The worst of the lot was a chap who said I had to use the web app but if I wanted we could do it in his office but it would still be the same web based application. Keep in mind when I inspected the first few of their frames I noticed weren't even https. At some point you just give up and it may be true that the paperwork all just gets transcribed by some 15 yr old kid in Estonia working on a ancient compaq laptop running Win95 over a SLIP link anyway. I just wish my usual Credit Union could have carried the loan but it was my mum's house and at several hundred miles away she doesn't live in their service area.

*Not the best rate but competitive.

0
0
Silver badge

Re: "oh, we have secure email"

IOW, at some point you gotta make up your mind. Trouble is that sometimes you can't get a break. You either go down path A and get peeked at all along the way, go down path B and get your pocket picked, go down path C which happens to be the way you came and get mobbed, or stay where you are and end up facing the wolves. Sometimes, failure is the only option, especially in a game like life where you are forced to play.

0
0
Silver badge

CRIME

I'll tell you what's a crime - that acronym!

0
0
Bronze badge

Re: CRIME

Indeed, a serious discussion of the issue is inevitably marred by being obliged to include the term "CRIME" in block capitals. It looks un-serious when you do that.

0
1
Silver badge

Re: CRIME

Only a criminal would think it's a crime to call a crime a CRIME

1
0
Unhappy

ether reality ..sniff :('

Now how did our border router wan interface move to promiscuous mode with those fake snmp controls,oh snmp must have been enabled with a blank write pwd,must look at that .

1
0
Silver badge
Black Helicopters

Re: ether reality ..sniff :('

Promiscuous mode is the least of your problems. You company has installed a cert into your PC which makes it look as though you have an SSL connection to your bank, when it really only goes as far as your proxy, where everything is decrypted (in a misguided attempt at data loss prevention) and then re-encrypted.

1
0
Facepalm

I got as far as TLS and laughed

TLS, I knew there was a reason I disabled that in my web browser with better options enabled

0
3
Silver badge

Re: I got as far as TLS and laughed

IIRC, there IS no better option available. And CRIME affects ALL implementations of TLS and SSL because it works AROUND rather than THROUGH encryption (CRIME is a side-channel attack). The only way to remove the side channel at this time is to remove the compression (which is what they're recommending IIRC), but then that still leaves the problem of optimizing secure-channel transmissions while not leaving side channels open.

4
0
Thumb Up

Re: I got as far as TLS and laughed

Thank you, I had overlooked that this effected SSL as well, so much for just disabling TLS all these years, though in that I tried with the tools available.

Nice explination of the issues - the ability to convert a full paper into the size of a tweet and make it explain it better is a skill, I stand corrected and happily so, thank you.

0
1
This topic is closed for new posts.