Tabnabbing: A New Type of Phishing Attack (2010) | Hacker News Reader

Tabnabbing: A New Type of Phishing Attack (2010)

azarask.in

273 pointsgkop95 comments

Man did that fool me.

I clicked on the link and started to read the story, but then had to look up an IIS error in a new tab. After my search I closed the current tab and I'm face to face with an old gmail login page. I'm sitting there like "WTF?". I refresh the page and the blog post comes back?!?!?

I finish reading the post and realized what had just happened. Kudos to the author. That really is a brilliant attack.

One solution I have seen, is you select a custom image during the account signup process, and it appears on the login page. That way, if there is no cartoon elephant on the login page, then it is not right.

My chinese bank account does this. I am not sure how effective it is, and it requires a two step login, so it is terrible from a usability standpoint.

It's basically useless. Any decent attacker should be able to proxy your info through, retrieve your image, and show it to you in the expected time frame.

how would that work? How would the attacker "proxy your info through"?

Yahoo’s implementation of this (Sign In Seals) works with a Flash (LSO) Cookie. So, they remember your username (and your personalized picture / seal) by inspecting the Flash cookie. I remember the first time I tried it—and being impressed—but then wondering how the fuck they did it. Then being less impressed when I realized that it doesn’t work after clearing your Flash cookies (or if you have Flash turned off).

Suppose that to log in to friendface, you enter your username, then it shows you the cartoon elephant that you selected beforehand, and you enter your password.

When fake-friendface wants to phish you, they get your username, then they give that username to friendface and receive your cartoon elephant in exchange. They show you the cartoon elephant, and you decide that this must be friendface.

And how do they "get your username" before you entered it?

How does friendface show your cartoon elephant before you enter your username? (hint: it won't)

The way this works looking at banking websites is that the user enters a username. Then they get some secret image + description that they previously wrote and can enter their password.

Most of the banking websites that do this also remember information about your browser and IP. If it's a new computer, you're required to verify the computer before they show you the image.

It is a simple man-in-the-middle attack. The proxy will forward the username and echo back whatever it receives from the bank.

The reason it might work in this case is because the assumption is that people will only verify the browser bar when they first arrive on the page, and not when they have been "tab nabbed" like this

Correct.

Plus, the secret image assumes I actually remember which image I select for every page. Given that none have the same collection of images, I'm likely to have only a vague notion of which one I picked at account creation.

The original implementation of this was from Yahoo. The image selection was stored locally in a cookie.

This is not the common implementation since most seemed to have missed the point.

Don't try to cover up the fact that you got played as well ;) We're all friends here, you can admit your mistakes :)

Yeah, me too. I opened up a bunch of tabs from the front page (as is my usual habit here, reddit, etc), and by the time I got to this it had changed to Gmail and I was totally fooled. I've gotta be more careful!

Fortunately, if you're using a password manager (and you don't have your password memorized), your password manager plugin will probably say "no logins saved for this site" which will clue you in on the attack.

> which will clue you in on the attack.

I would just assume that this is due to browser lag (since at my machine using Chrome, I've usually written my credentials before the browser's delay for notifying me about saved logins pops up.

No, most password managers (1Password, for example) will only fill in the passwords if the domain matches.

Truth be told, I don't think this hack would work on anyone who is sophisticated enough to use a password manager though. Who enters login info without inspecting the URL?

I use a passowrd manager (KeePass), but don't have it connected to my browser to auto-complete forms. Yet this hack could potentially work on me. I can imagine browsing several tabs at night, opening gmail, fb, my bank, etc. while reading reddit and getting tricked into filling in a phishing form. Granted, I always double check my bank login, but this is still a very valid attack no matter how "sophisticated" you are.

Another truth, is that phishing attacks are targeting the masses. If unsophisticated people will be facing difficulties, it is going to be enormously successful attack vector. Despite of the fact, that it completely fails in deceiving IT people.

This is analogous to the Nigerian scams that are engineered on purpose to be very crude in order to single out the most gullible persons.

Don't you ever lose focus for a moment? I do. Especially with 35 tabs open.

Hmmm. I use a password manager (Password Safe) and this is something that it won't do. With an attack like this I'd be better off just using the password feature built into the browser.

Another thing that's bitten me from time to time is what might be called FocusNabbing: where you're entering a password into one site and something else steals the focus, so now you're potentially typing part of your credentials there. It could be some other application running in your OS showing a modal alert or some other tab suddenly stealing focus (looking at you, Google Calendar).

While this attack vector is far more difficult to exploit, there should be protection against this kind of focus stealing. If your browser detects that you currently have the focus in a password field, it should block any attempt to switch the focus away to something else. The same should apply to the OS itself.

Focusnabbing is (currently) a non-issue at the OS level because of keyloggers. At least on X11, it is possible for a program to capture the key events of any other program (in the same session), even if the other program is running as a different user (including root).

I do not know if other systems are simmilarly vulnerable.

Favicon isn't changing for me in Firefox 33. Also worth noting that it still triggers when it's the frontmost tab in an unfocused window. I'd pulled up a smaller window on top of it, so the change to Gmail was hard to miss.

Despite that, I can imagine people falling for this even if the favicon doesn't match. They'll just say "Oh, Gmail's favicon is wrong. Silly web browser." If they notice the favicon at all.

Even with those things, most phishing is a matter of trying to get one out of thousands to respond. So a few people may notice the change, but that doesn't help the hundreds who may not.

I think this was published in 2010, so not really new - but probably still a possible attack vector.

I didn't realize how old this post was when I submitted it :/

For as much as Aza brags about his UX expertise, not dating his technical blog posts is inexcusable.

It is ok. Thank you for submitting an interesting article.

This attack vector is very relevant to this day. It works remarkably well on mobile phones, especially with the new trend of hiding the URLs to save screen estate. Together with throwing up a fake website, you could also try throwing up a fake address bar.

Also with mobile phones you can emulate a native application. This will show when the phone is re-activated with the browser app on.

A redirect to something like a Googleusercontent domain would be tricky, even with a visible URL. The author could also mine the referrer: visitor from HackerNews? Phish the log-in form with a bad gateway message.

Some view it as a best practice: https://training.kalzumeus.com/newsletters/archive/content-m...

And some would argue that truly timeless writing will transcend any timestamp you put on it, but the timestamp still has immense value.

You can, and should, make the strategic decision that you'll primarily write things which retain their value.

With this, I heartily agree; leaving off a date, though, that's just rude. If there are those who would judge your writing by the date it was written, there's either something wrong with them, or something wrong with the writing. As for the former, you can't do much about them, and probably don't want much to do with them. As for the latter, well, keep aiming higher! The date can be handy, though. Consider it a nod towards transparency and openness, and in more technical pieces with specific instructions, a great boon to those dealing with a version of the software a few years removed.

Additionally... how are we supposed to figure out when things fall out of copyright if nobody puts dates on anything? You might not think your blog post will be worth anything to anyone by then, but otoh, we're absolutely terrible at predicting what'll be valuable even 5 years down the line.

"Some view it as a best practice"

NO, IT IS NOT

That's probably the stupidest thing I've heard today

Things in IT change all the time. Heck, even non technical things. One text saying something, even if about something pretty "stable", may change tomorrow. It's one of the most important contextual information we have.

I shouldn't have to explain why not having a date is BS so I won't. Time is money after all.

ALWAYS date your texts, and brush your teeth (even though tomorrow someone may come up with something better)

I just let a domain lapse that was going to be about this issue - wrongtutorial. "Your tutorial is wrong and you should feel bad". Not updating / timestamping / putting a big fat "outdated" warning on an article is inexcusable.

This article, however, probably isn't that out of date - the attack still works!

> Some view it as a best practice: https://training.kalzumeus.com/newsletters/archive/content-m....

A marketing best practice; concealing information that might be of positive value to very many users because some users will treat it as a negative input (perhaps incorrectly in some cases, but that's not really important one way or the other from a marketing perspective) has obvious content marketing utility.

That doesn't mean it isn't universally a disservice to thoughtful readers.

As a user though, I find it extremely annoying when I'm trying to find out how old an article is and can't find a date anywhere on the page.

Yeah, if it doesn't have a date, that's (to me) a much stronger negative signal than an old date. If its old, I can take that into account (and, particularly, I can properly contextualize it and understand what it must not have considered because of timing.)

If it doesn't have a date, I can't contextualize it, and its value drops.

Depends on the subject. Marketing and conversion stuff, like he posts, is mostly timeless. Things related to specific pieces of web technology or security or other things that tend to change rapidly really ought to be dated in an easy to find way.

That article's commentary on dating articles is largely complaining about HN's policy. You can still stick a date somewhere on your page - put it at the footer, and anyone who gets that far will already have invested enough in the article to have at least scrolled down a bit.

> That article's commentary on dating articles is largely complaining about HN's policy.

No, it is using the observed effect of HN's policy as a piece of evidence for the broader claim that using dates is bad content marketing because it leads people to discount the dated content as it ages; the thesis is that, to maximize the value people ascribe to your content, you should avoid dates.

Ah, that's why the gmail page looked dated. Still interesting. It's obvious in hindsight but I have never thought of it before.

That it still works today (at least on Chrome 37) is probably the real news here.

Because it's not using anything special. It's just checking when you are inactive and then changing the favicon/title and HTML. Three things which you should be able to do on any site. I'm struggling to think of how this could possibly be prevented

There doesn't seem a lot one can do against that kind of attack, other than maybe introducing a convention for a reminder on each login page that the user should check that the URL starts with "http://%SUBDOMAIN%.%COMPANY%.com".

An attacker could still create a subdomain like http://mail.google.com.evil.com/. The problem comes for mobile phones not showing the whole domain due to lack of screen space.

A nice reminder of the critical design failure of dns - putting the domains from leaf to root (reverse of file-systems) will be a security and usability problem for decades.

interestingly, the attack even works when you view the page on archive.org

https://web.archive.org/web/20100527035243/http://www.azaras...

Yep, still works as advertised in current Firefox Aurora "34.0a2 (2014-09-08)".

Aaaand that's why I always have JS disabled by default.

Hardly foolproof, but 95% of the time it truly doesn't improve my web experience.

That's not the point. 99% of the people out there have it on.

> 95% of the time it truly doesn't improve my web experience

Really? I find that hard to believe. Do most sites that use extensive JS (Facebook, Mint, etc) have non-JS supported versions?

No. Facebook is only vaguely usable without JavaScript (and actually has a banner telling you to turn JS on or use their mobile site), but most sites are not. For one of my projects we use Invision, Slack, and Trello for collaboration, and none of them work at all without JavaScript (though the latter two do at least prompt you to enable it). Google, in its primary function at least, does work perfectly without JS.

Periodically on here, and elsewhere, you hear people banging the "I browse the web with JS disabled and it's fine" drum, but I can only imagine that their use of the web is limited to a certain set of fairly static sites. RMS gets by just fine with web pages being emailed to him, but, you know, RMS isn't like most people.

I use NoScript which can whitelist domains where JS is allowed. Often, sites will degrade without JS but if you're only reading something or whatever, it doesn't really matter. And if it's totally broken, you can temporarily allow JS.

Mainly, it's that I don't want my PC executing code that I don't know about, if I can help it. If I notice a site is e.g. requesting to run JS from twenty or thirty different domains I can be more cautious.

Overall, turning Flash off by default (but still having it installed), using NoScript, Ghostery, and AdBlock, have really improved the web for me.

> Really? I find that hard to believe.

Really-really? Would you believe bacteria are the predominant global biomass even though you seldom think of them?

The vast majority of all time consumed (or forcibly-wasted) by default-enabled JavaScript goes towards... What? Ads, tracking-mechanisms, and various nonfeatures to eke out minor visual effects. Even ignoring the cost to dispel unfavorable interruptions, the cumulative load/render delays constitute a user-experience death of thousand cuts.

The few dependable repeat-visit sites are easy enough to whitelist.

Disabled by default meaning he enables it for sites that he frequents and need JS like Facebook, Mint, etc.

Ah got it. Makes much more sense.

Same here and I went a step further; I use two browsers. The websites where I need to login are in a different browser in a different workspace, so tab-nabbing by random websites can never fool me.

Nice spoof, hadn't seen this before. It would have gone really well with the RTL address bar spoof (CVE-2014-1723) I reported in Chrome back in February (since fixed in Chrome 34), it would have made the tab very close to indistinguishable from the real thing.

Do you have a screenshot of this exploit in action before it was patched?

Looks like the issue is marked public now in the chromium bug tracker and it has been fixed for a while now in release, so I assume it is ok to link that. The ruse is not perfect due to bolding and coloring, but good enough to fool most people not expecting it, I think, if you look at the bottom part of the second attached screenshot it gives you a good idea of what it looked like:

https://code.google.com/p/chromium/issues/detail?id=337746

For a really sophisticated attacker, even 2-factor authentication isn't secure from this.

They can ask you for the 2-factor authentication code the same way Google does. You would type it into the phishing site.

Oooh.

The favicon and title change work on mobile, but the URL is clearly wrong.

http://www.imgur.com/qn3pUIL.png

I suppose this is another use for typo domains.

You can combine this with a redirect to something like `http://mail.googlemaillogin.com/` which will fool a lot of people

I think the wrong URL is the biggest indicator that something isn't right - and to think that several months ago, there was quite a bit of activity around removing URLs from browsers completely...

It appears to be entirely foiled NoScript (i.e. Javascript whitelisting).

The proof of concept is foiled. But how about something similar like:

  <noscript>
    <meta http-equiv="refresh" content="600" 
    url="phish.php"> 
  </noscript>

I believe NoScript will pop up a message asking if you want to take the redirect, in that case.

I think you are right:

"Forbid META redirections inside <noscript> elements"

but then I immediately wondered, what about META redirections outside <noscript> elements? I tested this with a fresh install of Firefox and latest NoScript, and those still work. Also: To forbid meta redirections inside noscript elements you have to toggle an option, it's not standard for non-trusted sites.

Did you test the META redirection with a background tab? I'm pretty sure NoScript added an unconditional block of background redirects within a week or so of this attack being publicized.

Though NoScript is a security measure that 99.XX% of users do not use.

Not for me - I use NoScript and the only domain pre-enabled was googleapis.com. I haven't seen any change on the tab or the site.

I think parent was saying that the attack is foiled by NoScript, not that the attack foils NoScript.

Ah, it's a bit garbled and I read it the other way. Ta.

It's certainly that.

Make the initial site something that obviously needs javascript, and some percentage of NoScript users will enable it.

But that's already a big improvement, actually. With NoScript, if a site (not on the whitelist) has to run JS, the user will be consciously aware of it. Aside from the obvious benefits, NoScript, and other plugins like it, force the user to remember that the web is a potentially hostile place.

I'm sure it's an improvement; I'm not sure how big a one - that doubtless depends in part upon just what the NoScript user's habits look like.

When this came out I posted about a no-Javascript version of this: http://blog.eitanadler.com/2010/05/tabnabbing-without-javasc...

An impressive sort of attack, I would never have thought twice about it.

Is there any valid use case for the onblur event on the window object?

Stopping animation or other CPU-costly visual processing that won't be seen? Stopping sound playing? Pausing a game?

Still works in Chrome 37. Not sure how you could fix this though..

Browsers or browser add-ons can mitigate this attack by blocking the use of the same password on two different sites. That might also be helpful for other reasons.

Tried opening the video. It didnt play. Tried full screen mode..still no luck. But when I returned back to the page, it turned out this page implements Tabnabbing!

This would certainly fool me. Another reason for 2 step authentication... which could also be cheated from you with this trick by the way.

1) It didn't work for me; probably because I'm using NoScript.

2) Also, I don't use GMail; say what you will, it's another defense against this.

3) Never, ever enter important credentials to a site you didn't open from a bookmark.

EDIT: Downvotes for effective strategies against this attack? Stay classy, HN. Stay classy.

2) Also, I don't use GMail; say what you will, it's another defense against this.

As the article states, you can use this to replicate any website. It's not just isolated to GMail.

Part of my comment on GMail was an implicit jab at the monoculture it engenders. It was crystal clear to me that this attack isn't limited to GMail. I would like others to consider what other service could be spoofed like this with anywhere near as good return on investment, precisely because other services aren't as widely used.

3) Never, ever enter important credentials to a site you didn't open from a bookmark.

Sure, but most users are careful when they first login to a site like gmail, but then leave the tab open. Mentally, you know you only opened your gmail tabs from a bookmark, so any gmail tab already open must be safe. That's what the attack plays on - you're not on your guard, so don't check the URL.

Really, Google shouldn't encourage bad behavior by asking you to re-enter your credentials in the existing tab.

>> 2) Also, I don't use GMail; say what you will, it's another defense against this.

Using a mail client to get your GMail instead of a web client is a defense against this too.

There is that as well. If I did use GMail, it would probably be through a non-web client.

That works for us but not the average celebrity Joe.

BINGO!!!

OP doesn't understand that this kind of attack (or most attacks for that matter) aren't targeted to the sophisticated user, its targeted to the majority of the population. The majority of the population isn't running noscript, is using the vanilla settings that the browser came with (which means javascript is turned on) and doesn't think twice about entering in their credentials into a site that they trust.

Reply on news.ycombinator.com