The web is a generative and wild place. Sometimes I think I missed my calling; being devious is so much fun. Too bad my parents brought me up with scruples.
Most phishing attacks depend on an original deception. If you detect that you are at the wrong URL, or that something is amiss on a page, the chase is up. You’ve escaped the attackers. In fact, the time that wary people are most wary is exactly when they first navigate to a site.
What we don’t expect is that a page we’ve been looking at will change behind our backs, when we aren’t looking. That’ll catch us by surprise.
How The Attack Works
- A user navigates to your normal looking site.
- You detect when the page has lost its focus and hasn’t been interacted with for a while.
- As the user scans their many open tabs, the favicon and title act as a strong visual cue—memory is malleable and moldable and the user will most likely simply think they left a Gmail tab open. When they click back to the fake Gmail tab, they’ll see the standard Gmail login page, assume they’ve been logged out, and provide their credentials to log in. The attack preys on the perceived immutability of tabs.
- After the user has entered their login information and you’ve sent it back to your server, you redirect them to Gmail. Because they were never logged out in the first place, it will appear as if the login was successful.
I dub this new type of phishing attack “tabnabbing”.
There are many ways to potentially improve the efficacy of this attack.
Using my CSS history miner you can detect which site a visitor uses and then attack that site (although this is no longer possible in Firefox betas). For example, you can detect if a visitor is a Facebook user, Citibank user, Twitter user, etc., and then switch the page to the appropriate login screen and favicon on demand.
[*] Think looking for the exact error thrown when embedding <script src=”http://gmail.com”/> it will be differ depending on if the user is logged in or logged out.
Even more deviously, there are various methods to know whether a user is currently logged into a service. These methods range from timing attacks on image loads, to seeing where errors occur when you load an HTML webpage in a script tag*. Once you know what services a user is currently logged in to, the attack becomes even more effective.
You can make this attack even more effective by changing the copy: Instead of having just a login screen, you can mention that the session has timed out and the user needs to re-authenticate. This happens often on bank websites, which makes them even more susceptible to this kind of attack.
Every time you include a third-party script on your page, or a Flash widget, you leave yourself wide open for an evil doer to use your website as a staging ground for this kind of attack. If you are the evil doer, you can have this behavior only occur once in a while, and only if the user uses a targeted service. In other words, it could be hard to detect.
You can also use a cross-site scripting vulnerabilities to force the attack to be performed by other websites. And for browsers that do not support changing the favicon, you can use a location.assign call to navigate the page to a controlled domain with the correct favicon. As long as the user wasn’t looking at the tab when the refresh occurred (which they won’t be), they’ll have no idea what hit them. Combine this with look-alike Unicode domain names and even the most savvy user will have trouble detecting anything is amiss.
Try it Out
You can try it out on this very website (it works in all major browsers). Click away to another tab for at least five seconds. Flip to another tab. Do whatever. Then come back to this tab.
It’s hard to find, isn’t it? It looks exactly like Gmail. I was lazy and took a screenshot of Gmail which loads slowly. It would be better to recreate the page in HTML.
Update: Many people have reported that the attack doesn’t change the favicon in Chrome. This was due to a bug in Chrome which has been fixed in the version 6.0.408.1. Chrome is fully susceptible to this attack.
You can get the source code here: bgattack.js.
This kind of attack once again shows how important our work is on the Firefox Account Manager to keep our users safe. User names and passwords are not a secure method of doing authentication; it’s time for the browser to take a more active role in being your smart user agent; one that knows who you are and keeps your identity, information, and credentials safe.
No related posts.
This is pretty slick and scary.