Phishing For Bank Info Without Any Pesky Malware

Emb3rz writes "DarkReading.com brings us news of a new approach to phishing that targets online banking sites. Here's the novel part of it: it doesn't involve any of the typical attack vectors we all know and love. Instead, it uses JavaScript from a remote page to detect if you have a banking site open, and prompts you for info via popup if you do."

Comments

XSS

[AKAImBatman]

Here's the novel part of it: it doesn't involve any of the typical attack vectors we all know and love.

A cross-site scripting attack sounds like a pretty typical attack vector to me. Javascript should not be able to "detect" if they have a banking site open. Pure and simple.

Re:XSS

[AKAImBatman]

BTW, for those of you who are curious about this attack (and are too lazy to RTFA), this basically uses a common image set behind a protected login. e.g.

<img src="https://www.mybank.com/protected/images/lock.gif" onerror="notLoggedInSoRefresh();" onload="hahaGotEm();">

If you ping the blasted thing for long enough, you will be able to detect the user logging in. One pop-up later and you've stolen their info.

Now protecting against this sort of issue is an interesting question. Ideally static resources should never be behind closed doors. But that answer is a bit of a cop-out. The next best thing is to ensure that session cookies are maintained inside the login tab ONLY and that persistent cookies are not used for auto-login.

(Interesting question: I wonder if Chrome is vulnerable? With process isolation, this trick would require that the main Chrome process delegate the handling of session cookies. Which seems like a bad idea anyway, so I would hope they implemented the browser in a more secure manner.)

Re:XSS

[AKAImBatman]

So let's say that instead it's on http://www.malware.lol/ - why would a script on a page from malware.lol be allowed access to a resource - in this case 'pinging' the 'lock.gif' - *on* https://www.mybank.com/ ?

There's a great deal of internet history behind this one. Originally, there were no barriers what so ever. Anyone could link anything from any page. Of course, as Javascript entered the scene and grew in sophistication, this was soon realized to be a problem. In result, most browsers adopted security behaviors for the really powerful stuff like XMLHttpRequest and locked out scripting across frames.

However, that still leaves a hole like this one. And it's not an easy hole to plug. Quite a few sites are actually structured around the idea of cross-site linking. (e.g. The HTML may be www.mainsite.com while the images come from the web server media.mainsite.com.) Interestingly, this sort of structure is actually a solution to the problem posed. So it's difficult to dispose of it out of hand.

Some of the web standards are moving toward highly restrictive models for HTTPS sites. e.g. HTTPS resources can only be accessed by pages whose origin is the same HTTPS site. More likely though, I expect to see more explicit security configurations along the lines of what Flash does. Flash uses a crossdomain.xml file on the target site to broadcast if a resource can be accessed or not. This scheme allows for situations like a media server separate from the primary site, but it also allows for those cross domain accesses to be tightly restricted.

Of course, the scheme is not without its problems. Nothing prevents an attacker from transmitting information he may have collected TO a server that he has configured with a permissive policy file. If he finds a vulnerability that allows him to collect the information in the first place, he's going to be able to make off with the info scott-free.

In result, web security is an ongoing area of research. It's incredibly complex due to the nature and history of the web, but standards bodies are working hard to find more reliable solutions that don't negatively impact existing sites and current usage.

Simple Solution...

[Klootzak]

Don't have multiple tabs/windows open while you're doing your online banking!!!

Oh, and use NoScript!

Re:Simple Solution...

[X0563511]

Once more, Darwin extends into the internet.

Computers are tools. They do what they are told without question. The internet is made of computers. By extension, it is a tool that does exactly what it is told.

Kind of like a handgun, and you don't (usually) let people run around with those without some kind of training.

Also like a handgun, most tools don't care who is issuing the instructions - they just do it. That tablesaw doesn't care if it's a 2x4 or your forearm, it saws anyways.

Yes, I'm an elitist bastard sometimes.

Re:Simple Solution...

[Klootzak]

Yelling "Install NoScript you n00bs!!!" won't register noobs... because they're newbs.

Well, I wouldn't call them n00bs firstly... and secondly, most of the technically-savvy geeks/nerds I know read Slashdot and find out new and interesting stuff from here.

One of the best things about Slashdot is if you write something on here, ALOT of people will take notice. So if by providing solutions/information that people can read and take away to tell other non-technically-savvy individuals helps protect at least one person from being scammed, I'm more than happy to yell on Slashdot about it ;)

Things to learn from this.

[john.picard]

The next thing you know, they'll make up a screen scraper in JavaScript. There are several things to learn from this. For the users, one, that you should completely clear your browser (Clear Private Data or similar) before going to a banking website, two that you should NEVER open other websites (or have them open) while you're signed in to a banking website, third that when you've finished banking, you should completely clear your browser again. For the browser makers (Firefox devs reading this?), third party cookies should be disabled by default, the option to turn them on should come with stern warnings, and each website can ONLY read cookies previously set by itself. Further when an encrypted page is opened, its memory should be such that other pages cannot access any part of it. In other words, the same sandboxing approach taken to deal with other security issues, within the browser for encrypted pages.

Re:Things to learn from this.

[Fian]

Perhaps it is time to have a dedicated banking browser? One that does not use cookies/cache data/allow more that one tab etc etc

Re:The Best Defense is Offense

[eln]

Some of us like to believe that the Constitution, as well as all other laws and treaties the government operates under, restricts the government's actions everywhere that it operates, not just on American soil, and that it also precludes the government from encouraging other nations to do what it itself is prohibited from doing. I don't see how we can call ourselves a just nation if we simply outsource acts that we would find deplorable if our own government were carrying them out.

I don't deny that our government has had something of a bad history of clandestinely encouraging foreign powers to "disappear" people we find troublesome, but that doesn't make it right or legal, and it certainly doesn't mean we should encourage it to happen more often.

A 'secure mode' for browsers?

[dnwq]

Internet Explorer has a porn^H^H^H^H privacy mode where privacy settings are locked down. Why not build an analagous 'secure mode' for Firefox or Konq. where security settings are all locked to high heaven for that browsing session only?

That way users can both bank online securely and not have half the web break for them because they've disabled javascript.

Re:The article makes it sound so simple...

[blueg3]

You don't need to hack a high-profile site to put malicious JavaScript on there. Most high-profile sites, directly or indirectly, load tons of third-party objects.

Advertising, for example, is an excellent JavaScript injection vector.

Re:The Best Defense is Offense

[Gerzel]

Problem is with no-script you still have to decide if you trust or not-trust the site and if that level of trust you have is worth what the site is offering.

If the site offers a useful service which requires scripts you have to decide if it is worth the risk.

While in most cases it is easy to tell and block only those sites you trust. Those that you don't block may also allow third party scripts to be run such as in ads on the site.

Re:Already dedicate browser sessions to banking on

[totally bogus dude]

It's explained in a few comments above. You just reference a resource (usually an image) that requires you to be logged in at the target site in order to access. If your attempt fails, the user isn't logged in at that site. If it succeeds, you know the user is currently logged in.

Re:The Best Defense is Offense

[ushering05401]

There's a simple technical solution to this:

      1. trace the phishing to their location
      2. send a missile to that location
      3. problem solved

I don't get it. Then the bad guys would have a missile. That is worse, not better.

paranoia-plus...

[BrokenHalo]

My paranoia has led me into a practice of doing my banking in a single browser session, clearing cookies, cache and history before and after, and closing/restarting the browser when finished.

Looks like I was right about the monsters behind the sofa after all.

Re:paranoia-plus...

[stranger_to_himself]

My paranoia has led me into a practice of doing my banking in a single browser session, clearing cookies, cache and history before and after, and closing/restarting the browser when finished.

My paranoia has led me into a practice of doing my banking by going to the bank.

Re:The Best Defense is Offense

[DigitAl56K]

Problem is with no-script you still have to decide if you trust or not-trust the site and if that level of trust you have is worth what the site is offering.

That slightly over-simplifies the protection that NoScript offers. For example, even when you allow script to run NoScript still provides protection against certain types of XSS, you can use it to force cookies to be exchanged over https for certain domains, it can block some plug-in types (Java, Flash, Silverlight), it features click-jacking protection, and just a couple of days ago it even added protection against attacks on twitter.

So yes, you do have to make that trade-off, but even when you click "allow" you're potentially better off with NoScript installed than without it.

Re:The Best Defense is Offense

[N1AK]

Slashdot: Where fining people for copyright infringement is wrong but killing people for stealing login details is "Insightful".

Re:The Best Defense is Offense

[RonTheHurler]

How about this one-

I got a letter in the mail (usps snailmail) from Bank of America asking for a lot of personal information that was missing from my account, and that if I didn't supply that information they'd have to report me to the IRS.

The letter was spelled correctly, had proper grammar and even had the BofA logo printed in full color. The return address was a PO box in Dallas. Nothing fishy at all.

Problem is, I don't have a BofA account. But I'm sure a LOT of other people do.

Phishing - it's not just an on-line phenomenon.

Re:The Best Defense is Offense

[Muad'Dave]

Maybe "you" do, and you don't know it. I think it would be prudent to call BoA, tell them what you received, and make sure someone isn't laundering money using an account opened with your SSN, name, or address.