Cookiejacking: 0-day exploit of all Internet Explorer versions | Hacker News Reader

Cookiejacking: 0-day exploit of all Internet Explorer versions

sites.google.com

171 pointsjpadvo29 comments

I mean, this is clever and all, but what am I missing? Isn't this just an IE bug? That you can access cookie files as IFRAME targets? Is there some part of the IE architecture that depends on that functionality, or is Microsoft just going to patch that?

Because pretty much all the browsers, on a better-than-quarterly basis, fall victim to attacks that allow arbitrary web pages to upload code into their processes and run it.

Just not sure this needed the "attack class" name.

Agreed. This is a one-off bug and certainly not something warranting its own term, since we're unlikely to ever see something quite like this again. Definitely a clever attack, though.

Agreed. This IE bug does seem to have some interesting behavior though:

https://twitter.com/#!/superevr/status/73920079921815552

> Because pretty much all the browsers, on a better-than-quarterly basis, fall victim to attacks that allow arbitrary web pages to upload code into their processes and run it.

> Just not sure this needed the "attack class" name.

You are being too generous.

By default, all web browsers ALLOW execution of ALL code encountered since all browsers ship with javascript enabled. Similarly, allowing hidden and/or transparent elements ENABLES clickjacking by default.

In other words, the fundamental design is flawed, and it remains flawed because of vested interests. Most argue the risks are worth the rewards, and anyone who disagrees is promptly told that their tin foil hat is on so tight that it's cutting off their circulation.

Seriously, do you really want to be the person who advocates removing all javascript and hidden/transparent elements?

We both know what would happen to said person.

EDIT: Getting down-voted for just stating the underlying problem on HN doesn't bode well for HN as a community.

> By default, all web browsers ALLOW execution of ALL code encountered since all browsers ship with javascript enabled. Similarly, allowing hidden and/or transparent elements ENABLES clickjacking by default.

Woah, woah, woah. There's such a huge difference between "they can run Javascript and maybe consume some CPU time" and "they can run native code and completely own my machine" that I don't even know where to begin. If you could do "eip = shellcode.ptr;" in Javascript, maybe this would be a logical argument, but really there's just a massive, massive difference here.

Please name any javascipt "sandbox" that has a perfect security track record.

That's the real point.

Sure, javascript can be useful and even beneficial, but the key is making a decision on whether the risks are worth the rewards. The same is true for ANY code you decide to run.

You can make the very same argument for images -- remember the libjpeg and libtiff vulns a couple years ago? You can make the same argument for CSS -- remember the type confusion in Webkit a couple months ago? I'm sorry, but you are completely off base here. That is why you're being downvoted.

You're trolling, whether you mean to be or not. You can't name an anything with a perfect security track record. And this time, you're trolling in service of a stupid argument: that we can have either an insecure Internet-as-we-know-it, or no Internet-as-we-know-it at all. Well, no shit.

tptacek, you built a false dichotomy, and then you pretended I said it so you could have a straw man to knock down. We can laugh about it over a beer the next time you visit the valley.

When a friend tells me I'm trolling, even unintentionally trolling, and even if it was expressed through a fallacious argument, it's time to stop and rethink. Something is definitely wrong.

I seriously thought about just dropping this, not responding and letting this thread die of natural causes. But I would be setting a bad example by doing nothing, or taking it privately to email. $DIETY knows HN needs more good examples of responding properly under pressure on contentious issues, and with some luck and effort, I'll hopefully write one.

It seems tptacek meant "Web-as-we-know-it" but I really do get his point; people are now accustomed to executing code from any source via web browsers and javascript. It undeniably is the status quo. Me and my outdated, curmudgeonly views have never agreed with the idea of executing code from any source. I am undoubtedly a minority.

The problem is, why is it such a terrible sin to question if the risks are worth the rewards, voice flaws in the design, and try to look for better alternatives? --In other words, why is everyone forced to accept the "as-we-know-it" part without question?

Wanting to improve the as-we-know-it is vastly different from wanting to abandon everything. I'm always in favor of trying to improve the status quo. I know for certain the same is true for tptacek and although I don't know him, I'd bet the same is true for daeken.

It's safe to say all of us "violently agree" that there is no such thing as perfectly secure code, and it makes no difference if the code is only handling data or if it is attempting to execute other code in a sandboxed virtual machine such as javascript.

Javascript has unimaginably huge investment and momentum behind it. The overwhelmingly vast majority of people have a vested interest in javascript, either as a company or developer, but also as just a user. It won't be abandoned overnight. Similar is true for other problematic aspects of the web including CSS and frames. In short, there is a damn good reason why unpopular views are very unpopular --Billions (if not more) of investment would be lost if these things were abandoned.

With all of that said, browser exploits are painfully common. If you reread tptacek original comment:

> Because pretty much all the browsers, on a better-than-quarterly basis, fall victim to attacks that allow arbitrary web pages to upload code into their processes and run it. Just not sure this needed the "attack class" name.

you can see browser exploits happens regularly enough to cause significant damages, but even mentioning the underlying problems results in, "You're trolling... Internet-as-we-know-it... no shit." and similar. It doesn't need to be that way, but around here, it almost always happens. The very idea of finding something better than the status quo of javascript and endless browser exploits is far too intimidating and unreasonable for most people. If you make your living from javascript or you're just a casual user, it is terrifying to think what would happen if it suddenly stopped working at 3pm tomorrow. When an idea contrary to the status quo is voiced, many people succumb to the irrational thinking of a sudden change and the associated irrational fears. But...

  The reasonable man adapts himself to the world. The unreasonable
  man persists in trying to adapt the world to himself. Therefore,
  all progress depends on the unreasonable man.
  -- George Bernard Shaw

Being unreasonable is never a license to troll; the efforts and investments of others have value and should be respected, but making improvements should remain open for discussion. Maybe I am unreasonable, but I do have good reason for it; our status quo is repeatedly broken. Taking offense to reality will simply prevent you from improving the situation, and worse, shouting-down others for venturing where you fear to tread may prevent them from improving the status quo for you.

If you can't talk about a problem, then you have a bigger problem.

The problem is that you said they would execute 'ALL' code, which is not only terribly misleading but technically incorrect. It's a false statement that has no place in a proper discussion.

Also I think it's unreasonable to expect a browser without javascript to be significantly safer. Look at all the code-execution exploits in image decoders.

I skimmed this.

Insistently trying to relitigate all of Javascript on HN in response to an IE news story is trolling. The first such comment was just annoying, but when you pushed the point with someone who clearly wasn't interested in your orthogonal argument, it crossed the line.

Except qmail, of course (http://cr.yp.to/qmail/guarantee.html )

:-)

Qmail does not have a perfect security track record (though AFAIK djbdns does).

Actually, djbdns does not have a perfect record: http://article.gmane.org/gmane.network.djbdns/13864

Just about all nontrivial code that accepts input, whether or not that input is "code," has a tainted security track record. There is no point because you're not addressing the issue. Running code in the browser certainly creates its own class of security issues no matter how safe the execution environment is, but the fact that browsers do very complex things with a huge variety of inputs means that there are tons of vectors for manipulation. This is much closer to what your trying to talk about, but is pretty meaningless to discuss in the broad sense.

Apparently that page has been shut down by Google?

"This site has been disabled for violations of our Terms of Service. If you feel this disabling was in error, please fill out our appeal form."

Any mirrors?

http://www.lo0.ro/2011/cookiejacking-stealing-cookies-with-i...

Novel approach, but I'm curious how many networks let 445 smb over tcp out? Enterprise networks sure shouldn't, my office doesn't, my house doesn't though admittedly most people won't be configured this way. But don't big carriers like comcast also filter common microsoft ports like this and 139 because of worm and exploit activity?

You only need the SMB connection to grab the username, right? That seems straightforwardly guessable.

Apropos little: UNC path filtering is something the Rails generation of webdevs have a bad habit over overlooking.

Yeah, only the username. Still, that seems like a pretty hard thing to blind guess at in most attack scenarios if you can't get it through the cifs connect. My reading is that you couldn't brute force it, you'd have one chance to set up the iframe with the cookie file in it which needs the username, or at least just one chance per clickjacked drag action that the user executes for you.

If it's a targeted attack I suppose you have a better shot, are most home windows user names set to the user's full name like "John Doe"?

That's my thinking; it seems like it'd be most relevant in a targeted attack. Presumably there aren't so many patterns of usernames that you'd run out of chances to get one.

It's clever! I don't want to take anything away from it, except that I think it's been written up somewhat breathlessly.

Grossman probably has a good point that most applications aren't even superficially protected against clickjacking, and so this isn't going to be a common attack any time soon.

> My reading is that you couldn't brute force it, you'd have one chance to set up the iframe with the cookie file in it which needs the username, or at least just one chance per clickjacked drag action that the user executes for you.

But if you made some sort of Javascript "game" (which used drag and drop) and required the users to register their name first, then you should have a fairly high chance of guessing their username without CIFS.

I seem to recall at least one XP box that I've set up that came with a preconfigured account; if e.g. Dell does/did this, there may be a lot of such accounts out there...

Can someone describe the white hat credo with respect to 0 day exploits?

Did he give Microsoft a head's up about these and a chance to respond before going public? Or does he just give a conference talk and post it to his blog, potentially providing the information allowing thousands of browsers to get compromised (assuming they weren't already) before privately letting Microsoft get a chance to patch it?

I don't know, but Microsoft doesn't care anyway (or so they say), according to http://www.computerworld.com/s/article/9217116/Microsoft_dow... .

But I do hope that he told Microsoft before the world.

If this attack involves "simply sniffing TCP 445" why not just MITM the whole session?

The state of security is becoming an over-hyped sideshow of late where the most trivial attacks, which would work maybe 1% of the time in the wild, are getting mass exposure.

I have a 0day in RHEL 5, you simply need to log onto the machine as root and run this script...

"If this attack involves "simply sniffing TCP 445" why not just MITM the whole session?"

Because it doesn't. The attack involves using a bug in IE (an iframe will render cookie data from the local computer) with clickjacking to steal cookie information. Sniffing on port 445 is only mentioned in the context of figuring out the username of your target (by causing the target to connect to your SMB server, running on port 445).

I'd suggest you go back and re-read the whole page before making sweeping generalizations.

> If this attack involves "simply sniffing TCP 445" why not just MITM the whole session?

Hmm, because port 445 is not port 443?

Reply on news.ycombinator.com