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.
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.
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
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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-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.
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.
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:
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...
"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.
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.
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!
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.
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.
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.