Slashdot Mirror
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."
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 -- work where geeks are their own boss
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.)
Javascript + Nintendo DSi = DSiCade
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.
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.
For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
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.
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.
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.
There is nothing special about secure sites. HTTPS doesn't mean "this site is super special and you should do special things with it". This same attack can be applied to non-secure sites, too.
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 just isn't friendly for 99.999% of home users. What we need is a "simple" option setting for Noscript, perhaps set up by allowing the user to choose on first install, which instead of listing every single blockable element, would have a "play video" button which would look for *.flv, *.mp4, etc and play the video. Because it is video sites that have made Noscript useless for handing out to non techies. I have watched my customers and they quickly get frustrated because they can't figure out which of the dozen blocked elements is the video they want to see and soon start clicking "allow all on this page" which makes it as useless as Vista's UAC prompts. By having a "play video" option at the bottom you would still have the high security, since nothing is being run by default, but it would allow the non techs to play their videos without killing the security.
ACs don't waste your time replying, your posts are never seen by me.
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.
Anybody who knows the history of security vulnerabilities in browsers knows that Javascript itself is the all-time-best attack vector. If Javascript is enabled in any browser, that browser can be immediately compromised when you visit a compromised website. There are latent epidemics of Javascript zero-day vulnerabilities in all browsers.
Want much better security in your browser? Just disable Javascript. Learn to dislike Javascript. I have yet to see any website whose information could not be equivalently usefully displayed without any Javascript. Every time Javascript's "interactivity" is celebrated, critical reading dies another death. Don't regret losing all the "interactivity" of Javascript. There are far too many bad developers who write websites that require Javascript. Turn the tide. Reject Javascript for the toxic waste of space that it is.
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/ shouldn't be told to piss off.
"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.)" - AKAImBatman (238306)
That I understand - as per my post, for inlining things etc.
However, I think that in the specific case you mentioned - e.g. media.. presumably images - those images *should* either come from the same domain as the secure site *or* come directly from an insecure site. Yes, a browser will pop up a warning that there's mixed content.. it does that for a reason, I would think. But the way around that is not to stick your images on a completely different-but-still-secure domain (I've not actually seen this, so for all I know that throws up an error as well anyway), but by keeping things on the same domain. Any sysadmin worth their pay can easily offload resources to a different media server if there's some manner of capacity issue at play that would have them put the media on a different domain otherwise.
Maybe making things more strict would indeed break a few sites, but other than webmasters/sysadmins realizing they need to be more careful, I don't see the harm in that other than short-term mumbling and cursing from the aforementioned groups.
crossdomain directives sound like another security problem just waiting to happen, in my humble opinion, but I'm certainly not an expert on that topic.
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.
-- Slashdot: When Public Access TV Says "No"