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