It exists. Don't go there.
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 …
It exists. Don't go there.
Unless you're using Internet Explorer, obviously.
"Unless you're using Internet Explorer, obviously".
In which case it's your home page.
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/
That gets an upvote just for the name.
I love a Tommy Pornin' in the morning!
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.
So we should ignore it then. Thanks for that.
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.
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
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.
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
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.
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.
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.
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 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.
Easily mitigated by site sending a new authorization token after each request.
"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.
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...
Yep. A wise man once said 'Security is not a state, it is a process.'
I'm British, so a "nonce" will always be a man that fucks children. Lets keep this discussion civil ;)
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
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.
I agree this is being overhyped but it is very clever and I do rather admire the people who worked it out.
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.
The sound in the background is that of millions of flamethrowers backfiring simultaneously.
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.
Loverock Davidson, Is that you?????
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 ....
Because no, it's not just you.
Another attack facilitated by client-side browserbling tech?
My bank says the internet is secure.
Don't worry, Checkpoint secures the Internet.
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".
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.
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.
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.
I'll tell you what's a crime - that acronym!
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.
Only a criminal would think it's a crime to call a crime a CRIME
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 .
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.
TLS, I knew there was a reason I disabled that in my web browser with better options enabled
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.
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.
Biting the hand that feeds IT © 1998–2017