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
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.
Javascript + Nintendo DSi = DSiCade
Don't have multiple tabs/windows open while you're doing your online banking!!!
Oh, and use NoScript!
A Man's ethical behavior should be based effectually on sympathy, education, and social ties -- Albert Einstein
Funny how I got a Flash ad thrown my way when I visited the link.
You are being MICROattacked, from various angles, in a SOFT manner.
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.
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 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.
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.
Virtual Betting on Facebook for non-geeks.
I already make sure that if I'm going to visit my bank, I close my browser, start a new one, do the banking thing, then close the browser before I do anything else. While banking I don't browse other sites.
I figured an attack like this was possible but had no idea there was a way to check other sites you are visiting via JavaScript. That seems like a very obvious security flaw. Anyone know how that is possible? Is it via standard JavaScript, or does it require a bizarre hack that happens to work on today's browsers? The article doesn't say.
In a real emergency, we would have all fled in terror, and you would not have been notified.
I wonder if Chrome's idea of running each tab in a separate process makes it less vulnerable to this type of attack? I suspect that it is much harder for there to be a cross tab or cross window attack via Javascript it each has its own full process.
Think Deeply.
I always see folks bitching and moaning that FireFox burns memory... if you leave it open all day. Why would you do that? I must open FireFox 50 times a a day, and never complain about the extra 1.5 seconds it takes to do that, at least I know I have a "fresh start".
Often, I also delete all the cookies too, just because I am a neat freak, not due to paranoia. Maybe I get more secure sessions as a side effect.
Anyhow, keeping your kitchen neat and clean is healthy. Maybe keeping your computer neat and clean is more secure. Sometimes, a reason like "because I said so", works out to be a good thing, even if the reasons are not articulated.
This issue is a bit more complicated than you think.
Are you kidding? Internet security clowns have a very limited imagination. They go nuts on securing one aspect beyond usability while completely ignoring other areas.
Here in NZ there is a problem with ATM machine skimmers. Criminals equip the ATM machine with camera and fake card reader and collect card and pin codes from unsuspecting users after which they raid their bank accounts.
So everyone is worried about this now. Yet, the most popular form of electronic payment in shops in NZ is the user of a bank card combined with a pin code (EFT Pos).
I user it all the time to the point that I rarely see cash. Yet, it only takes a single merchant borrowing a mobile EFTPos installation to skim as many cards as he wants.
Simple. Grab a card reader, fake entry terminal and a simple micro processor and sell some stuff cheap so you get many customers. Add a simple bit of programming. The client payment experience is the same on the fake payment system and they won't pay any attention. After all they are not pulling cash out of a machine but are excited making a payment for a deal too good to be true. No need to suspect anything, after all they walk away with the goods. You collect the card data and pin code and make the same transaction later. Now you either sell on the card data or use it to make small payments or large payments as long as you can get away with.
Unlike ATM machines, Equipment for electronic bank transactions in shops are completely in the hands of the vendor and totally open to abuse. Yet nobody worries about it because it has not happened or had not been detected to the extend that the media jump on it.
And don't get me started on credit cards.
Half my desktop or more is web. These days you
can use the web for spreadsheets, word processing,
email, chat, and so on.
Closing all those windows would suck ass.
The browser damn well ought to isolate the
web sites 100% from each other. WTF?
Instead, the damn thing frustrates any attempt
at manual isolation. If I try to start a second
instance, that one does some retarded RPC thing
to have my other browser instance spawn the new
window -- and then that second instance exits!
It's not even fail safe. Crash in one window,
and all the windows go.
IMHO, a retarded bovine could get security right.
It took real effort to fuck things up.
My father warned me about this. Hate it when he's right.
"Violence is the last refuge of the competent, and, generally, the first refuge of the incompetent" - Thing_1
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.
From TFA: "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."
I don't see how any well-designed high-profile site wouldn't account for the possibility it might get hacked, let alone not have an automated method for undoing the damage... A simple approach would be to generate an MD5 checksum from each file (i.e. ASP, JPG, flash) and compare it to the MD5 checksums of what they're "supposed" to be. Generate & compare every 15 or 30 seconds. If there's a discrepancy, copy the file back from a read-only source and send an administrative alert. Hell, it's a simple VBScript...
Windows 3.1x calc: 3.11 - 3.10 = 0.00
Yet another reason to ban pop-ups. IMHO Javascript should not be allowed to create, close, move, resize, or in any other way affect OS-level windows, period. That includes modal dialogs like alert popups and that "do you really want to leave this page" dialog.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
You might have an account, but you certainly
aren't depending on it and getting lots of
email through it.
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.
What about just implementing a general pop-up blocker? If something actually does pop-up, and you don't get the request that it's from such-and-such a site, you know something fishy is going on. Anyways, I think there are two problems that exist here. The primary one is user education. More aware users may be harder to con unless by a very direct fishing attack. The second would be to standardize how sites can transmit secure information. I don't mean just encryption, but perhaps have a standardized protocol that all sites must go through to get your information. I.e. no popups, visit their site, validate their url location. Some of this probable wouldn't work, but it might be useful to consider.
Why is there no way to restrict session cookies to the tab that set them and its spawns? Or does Chrome do that? It's well known that a site doesn't need direct access to a cookie to check for its effects.
A quick search turned up an extinct Firefox extension that seems to do this: CookieStore. It should be default behavior of browsers.
I believe there is a technical solution to this attack and to other attacks. But if a technical solution does not exist, then online banking is inherently insecure and should not be used by anybody.
In this particular case: (a) block Javascript in different tabs from seeing what sites you are visiting, and (b) all popups should be clearly labelled by the browser with what site they came from. If it's an SSL site with an extended-validation certificate, then show the company name in large writing at the top. If not, display a clear visual indication that it's from an unknown site. Personally, I think some kind of Microsoft Bob style assistant could give non-technical users the hint they need to understand that a page or popup is not from their bank, even though it may display the bank's logo inside the page. The assistant should appear next to the popup window with a suspicious look, and require extra confirmation before entering data into an unknown popup if you have a secure site open.
-- Ed Avis ed@membled.com
I always close all my other browser windows when I'm using online banking, and start with a fresh Firefox session (set up to clear everything on shutdown). I thought I was just being paranoid, turns out not so much!
The best security I've seen my bank use is an external hash thing that looks like a small calculator. You have to stick your card in, enter your pin, enter a bunch of numbers and you get a code back to enter into the site when you transfer money. Surely that kind of security would render this sort of scam pointless?
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.
Thats's awesome!
So some Terrorist could live inside a locked school broom closet for years hosting hacking stuff! Who'd ever accuse a school of Not Thinking Of Children??
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
Both.
With semi-apologies to certain TV shows,
"My mother was a prototype from an AI lab and gained all the lexical parsing rules and dictionaries. My father was a real-time self modifying system born out of the cyber wars. It's the unification of both that made me possible."
My first Journal Entry ever, in 8 years! http://slashdot.org/journal/365947/aphelion-scifi-fantasy-horror-poetry-webzine
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.
With no other specific information released to the public it is difficult to say if this report merely reiterates one of these problems, or discusses a new vector; but regardless of this, it is a well-understood property that users sadly need to live with for the foreseeable future.
Over here in the Netherlands most banks (maybe all) don't use passwords. In my case I have a card reader that will generate a code after I give it my card, PIN number and a code generated by the website. I have to do this to log in and to initiate transactions. That makes this attack pretty useless. Also, a prompt should always clearly indicate by which website it was called and it shouldn't block other tabs.
I noticed that Chrome 2.0 isn't affected by this however I have to ask the question..
How can Chrome be affected by this in the first place? Isn't the whole point of Chrome that it's sand boxed in and unable to get information from other tabs.
If this isn't the case then I see no point in using Chrome. It means all that Chrome marketing was just fluff.
I am sure there are several, but I distinctly recall stopping in at a place with a sign that read "Eat Here! Get Gas!" on my way to Maine one year.
Have you thought about using a separate Firefox profile which is only for banking? This would enable you to maintain temporal continuity in the other profile.
Google security researcher Chris Evans has a very informative blog post which notes that to avoid attacks like this one you must set your http proxy to localhost:1 thus killing all http traffic and only letting https (to your bank) go through.
-Malloc
___________________ I want to be free()!
The bank should check the REFERER header, and if it's not the bank's own site, return a 400 error.
That way, javascript loaded from another site won't be able to get information about whether the user is logged in to the banking site.
One that does not use cookies
Web apps must track changes (user management, breadcrumbs, back links, etc) from page to page. Otherwise they are of little utility. Web apps make pages stateful by tracking a session in one of two ways: Storing session IDs in cookies or URLs. Cookies can be secured with encryption. URLs are plaintext. Session URLs are like writing your pin number on your bank card. So ... take your pick.
(There are actually other ways. But they suck worse: 1) Form value submission. *Everything* you click has to be a form with a hidden field to submit the session value... bye bye <a> tag. The forms also have to POST or the session will end up in the URL anyway ... see above. 2) Javascript cookies... need I say more? 3) Flash cookies... I think other posters have already pointed out security flaws in this approach 4) some other approach with huge drawbacks? )
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"
I don't have enough money to care about banking scams.
Google Chrome creates a separate session in each tab. How would the malicious javascript in one tab know about the separate session in another tab?
My dad and I were driving through Alaska about 15 years ago. We passed a sign on the highway advertising "Skinny Dick's Halfway Inn." It had been a long haul, and we weren't very sharp, so we'd already passed it by the time it sunk in (no pun intended). I wish we had gone back to get a picture.
Yes, it is stupid but there are banking sites that use java script and don't work if you disable it.
That's not 100% secure : an attacker could install a proxy on your machine on port 1 , thus breaking your security principle.
Slipping shoelaces ?
Uh, if an attacker can install a proxy on your machine on privileged port then you've got a whole lot more problems than browser security.
This discussion is about a *secure* machine getting taken in by extraneous http requests. The technique above blocks them.
___________________ I want to be free()!
The common problem with all these so-called "security" devices is that they authenticate you to some degree, but not the originating bank. The RSA one time password gadget simply churns out numbers, but you have no idea if you're giving this to a Man in the Middle pretending to be you or the actual bank. The challenge-response gadgets (which is what you are talking about) challenges YOU, but you can't challenge the bank (although this ought to be theoretically possible) so again not quite Man in the Middle(/Browser) proof.
You have NO idea if you're actually looking at the bank - even assuming your client has a clue where to look to check it is still possible to make a mess of things in the browser. The idea of using SSL as site identification as well as carrier security has never been foolproof, and the average end user is OK if you just show them a PICTURE of a padlock on the page. Sigh.
The gadgets you have to install (USB keys et al) rely to a degree on the client system being at least safe or unable to affect the transmission, and the new Swiss IBM ZTIC is about the only one of those "installables" that has at least some authenticated channel - but has zip to ensure the actual user is using it. So it gets the transport right, but not the user verification (AFAIK, I haven't had it in my hands yet)..
The hack seems already quite old now, I found this 3-years old post : http://it.toolbox.com/blogs/puramu/javascript-hack-to-display-your-browsing-history-12694 Proof of concept : http://ha.ckers.org/weird/CSS-history.cgi
You have NO idea if you're actually looking at the bank - even assuming your client has a clue where to look to check it is still possible to make a mess of things in the browser.
You are saying that even when I see the padlock, *and* the correct URL in the browser, *and* the details of transactions I know to be mine over the last years, I could still be looking at a 'middle man' instead of at my own bank?
Even if so, one of my banks is sending the confirmation codes to my mobile phone, so an attacker would have to have my internet connection, my phone, and my brain. Still hackable?
Don't even get me started on ASP.Net or whatever it's called this month - it absolutely, positively REQUIRES Javascript on browser side, else that idiotic __doPostBack (which, btw, is attached to everything) will break. Yeah, yeah, I'm sure you could persuade it not to, but it probably involves black candles and a goat - at least, that's my assumption from the JS/non-JS ASP.net sites' frequency distribution. And get off my lawn, too!