Slashdot Log In
Phishing For Bank Info Without Any Pesky Malware
Posted by
timothy
on Fri Jan 16, 2009 12:06 AM
from the but-the-convenience-is-incredible dept.
from the but-the-convenience-is-incredible dept.
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."
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
The Best Defense is Offense (Score:4, Insightful)
This is real scary. And it goes to prove that bad guys always come up with new ways to steal. I don't believe there is a technical solution to this arms race.
Instead, I'd love to see our law enforcement friends be more pro-active and setup traps. Pose as a fake victim. Go out and seek those phishing sites. When the thieves come after your money thinking they just ripped off a stupid Internet newbie, then you can trace their activity and catch them.
That's the best way I can think of scaring the bad guys: when they never know if their next victim might be a cop.
--
FairSoftware.net [fairsoftware.net] -- work where geeks are their own boss
Re: (Score:2, Informative)
I've heard of something like this before.
Though there's this magical thing called noscript.
If people would stop putting law before them to prevent them from making stupid choices then we might have a more informed society.
(I ironically didn't read TFA.)
Re:The Best Defense is Offense (Score:5, Interesting)
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.
Parent
paranoia-plus... (Score:5, Insightful)
Looks like I was right about the monsters behind the sofa after all.
Parent
Re:paranoia-plus... (Score:5, Insightful)
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.
Parent
Re: (Score:3, Funny)
My paranoia has led me into a practice of doing my banking by going to the bank.
You insensitive clod. How do you get there - in your gasoline powered, carbon-emitting, smog-making car? /.er would stay in his basement and do his banking on the internet and not risk having to interact with other humans.......
A real
You must be new here.
Re: (Score:3, Funny)
dieing indeed....
Re:The Best Defense is Offense (Score:5, Informative)
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 [hackademix.net].
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.
Parent
Noscript Is Pretty Much Geek-Only (Score:4, Insightful)
Noscript requires a level of knowledge about attacks, protocols, etc., that precludes it from being adopted outside the geek community.
A tool intended for widespread use needs to have two buttons: Safe and Unsafe.
Parent
Re: (Score:2)
Re: (Score:3, Funny)
Elbonia uses trenches as we cannot afford your extravagant tubes.
Re:The Best Defense is Offense (Score:4, Insightful)
Well, the nature of an arms race is such that it has technological approaches.
In this case, for example, there most certainly is a technological approach. JavaScript in one loaded tab in your browser should have no shared knowledge with other tabs in your browser. Data separation needs to be enforced at a finer level. You should also know, if you have two tabs open to different sites, which one of the two a popup is associated with.
Parent
Re: (Score:3, Informative)
When you're currently visiting one site, and open a new tab and go to a different site, those two open tabs should have no capacity to share information -- they should function as if they were separate browser sessions. (Obviously this isn't the same as if you clicked on something in a tab that causes another tab or window to open, as they may need to share knowledge. But then, the fact that those two tabs/windows are tied to the same context should be made apparent to the user.)
Re: (Score:3, Interesting)
Re:The Best Defense is Offense (Score:4, Funny)
4. Find out that the phisers are using a proxy to bounce off of.
5. Find that proxy is some poor schmuck who got hacked.
6. Realize poor schmuck is you.
7. Boom.
Parent
Re:The Best Defense is Offense (Score:5, Funny)
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.
Parent
Re:The Best Defense is Offense (Score:5, Interesting)
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.
Parent
Re:The Best Defense is Offense (Score:5, Insightful)
Parent
Re: (Score:2, Troll)
The solution is to make the bad guys "disappear," not to seek out "justice."
Why the hell would Elbonia care if some local scumbags show up dead in a gutter somewhere?
Re:The Best Defense is Offense (Score:4, Insightful)
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.
Parent
Re:The Best Defense is Offense (Score:5, Insightful)
Parent
XSS (Score:5, Informative)
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 (Score:5, Insightful)
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.
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.)
Parent
Re:XSS (Score:4, Interesting)
so wait..
as you explain it, I guess the idea is that once the user logs into the secure site, the malware script can magically access the lock.gif because the site and browser tell them that.. yup.. the user is logged in and thus should have access.
however.. presumably, the script is not from a page that's actually -on- https://www.mybank.com/ [mybank.com].. if it was, you and the bank probably have bigger problems.
So let's say that instead it's on http://www.malware.lol/ [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/ [mybank.com] ?
Is there any valid purpose for allowing something like that? I can understand it for non-secure sites.. from inlining content that's hosted on another domain to allowing local applications to grab data off of e.g. websites that do not provide a nice API. But for secure sites? I'm baffled.
Parent
Re:XSS (Score:5, Interesting)
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.
Parent
Re: (Score:3, Insightful)
Well that's the thing - why not? They are superspecial to my browser already.. doing its certificate check and throwing a big fat "passport check" image at me (FireFox 3) if it think something's not quite up to snuff. I don't see why a page on anything other than https://www.mybank.com/ [mybank.com] shouldn'
Re: (Score:3, Insightful)
Re: (Score:3, Insightful)
And that one is JavaScript too. Has anyone else noticed that pretty much every piece of nasty coming down the pipe uses JavaScript? I've said it before and I'll say it again: JavaScript is a BAD Idea, just as ActiveX was a bad idea. They both are havens for malware. The only difference is ActiveX was Windows only. But in either case it is still a giant security hole. If this keeps up and enough folks are burned I could see it dying off just as ActiveX did.
Now as for Noscript, while I use it every day it j
Simple Solution... (Score:5, Informative)
Don't have multiple tabs/windows open while you're doing your online banking!!!
Oh, and use NoScript! [noscript.net]
Re: (Score:2)
This, like most phishing attempts, targets users who don't know about NoScript or basic internet safety practices.
Yelling "Install NoScript you n00bs!!1!" won't register noobs... because they're newbs.
Re:Simple Solution... (Score:5, Insightful)
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.
Parent
Re:Simple Solution... (Score:5, Informative)
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
Parent
Re: (Score:3, Interesting)
Oh, and use NoScript! [noscript.net]
Another simple change is to set dom.disable_window_open_feature.location [mozillazine.org] to true. That should make it pretty obvious when a popup comes from source different than what it's claiming.
And it's been there all of these years (Score:2)
Things to learn from this. (Score:5, Insightful)
more fixes for the security model (Score:4, Insightful)
Any browser window containing content from more
than one security context must NOT display any
sort of lock icon, and must display a warning
banner.
"more than one" would include an https site that
uses some http images. It's not secure if it's
a mix.
Parent
Re:Things to learn from this. (Score:5, Interesting)
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
Parent
Re: (Score:3, Interesting)
I try and shy away from online-Banking as much as I can. Never mind separate browser. I use a Live Linux DVD and load up my bank site from there. When I do this its boot, bank website, print if necessary, shutdown and back to Windows.
Re:Things to learn from this. (Score:4, Interesting)
I, for one, have a dedicated VMWare virtual machine with Ubuntu installed, and Firefox. Firefox has NoScript installed, is set to saving no user story, and I use it only for banking. I find the setup a bit unwieldy sometimes, but is sure safer.
Parent
Re: (Score:3, Insightful)
It would be cool to have firefox "mode" doing exactly this. Press an "online-banking" button and a new isolated firefox session would be started with all needed restrictions and settings.
Re: (Score:3, Interesting)
Or you should get a one time key generator.
My key changes every 60 seconds. Could they exploit this within that time frame. (Especially if I'm already logged on and the bank does not allow a second simultaneous login)
Use a separate Firefox profile for banking (Score:2, Interesting)
This is why I use a separate Firefox profile for banking and bill paying. And I only have one tab open at a time.
The article doesn't describe the actual exploit (Score:4, Interesting)
The only way I can imagine that js on one site can detect if a user is logged into another (assuming the other site is secure and I cannot post js to it) would work like this:
Use an Asynchronous request to "curl" out to a well known page of that site and then "grep" the response for typical "you are not logged in" text. If it is not found, commence shenanigans.
BTW, this comment kind of made me roll my eyes:
"Klein says placing a low-profile piece of malicious JavaScript on a high-profile Website isn't difficult to do, and the malware is basically invisible to the user."
"Klein" makes it sound like this is a walk in the park. I don't know. After the myspace worm a few years back, I think validation and filtering on those sites has gotten pretty good. Low-profile sites? Sure. High-profile sites? Not so much. I'm not saying it's not possible, but "not difficult"... maybe Klein is just conceited.
Re: (Score:2)
Re: (Score:3, Informative)
I agree. Most XSS attacks would require the banking site to have a vulnerability. This article implies that all one needs is a vulnerability on the first (high-profile) site.
Not common yet.....? (Score:2)
From the friendly article: although he and his research team have not spotted full-blown attacks like this in the wild as yet
I'm sure they will now after this.
A 'secure mode' for browsers? (Score:5, Insightful)
That way users can both bank online securely and not have half the web break for them because they've disabled javascript.
Re: (Score:3, Interesting)
Javascript alerts would be fine, as long as they would stay only with their own content and not interrupt other tabs/windows or other programs on the system.
There is a very long-standing bugzilla bug about this for Mozilla, you can read:
https://bugzilla.mozilla.org/show_bug.cgi?id=59314 [mozilla.org]
Bug 59314 - Alerts should be content-modal, not window-modal
(comment #39 describes a security problem that sounds similar to the problem here)
Lots of good ideas in that page about how alerts could be handled differen
Re:The article makes it sound so simple... (Score:5, Insightful)
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.
Parent
Re:Already dedicate browser sessions to banking on (Score:5, Informative)
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.
Parent