×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

cancel ×
This is a preview of your comment

No Comment Title Entered

Anonymous Coward 1 minute ago

No Comment Entered

232 comments

The Best Defense is Offense (3, Insightful)

alain94040 (785132) | more than 5 years ago | (#26478655)

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:The Best Defense is Offense (2, Informative)

Anonymous Coward | more than 5 years ago | (#26478679)

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 (4, Interesting)

Gerzel (240421) | more than 5 years ago | (#26479531)

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.

paranoia-plus... (5, Insightful)

BrokenHalo (565198) | more than 5 years ago | (#26479987)

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:The Best Defense is Offense (4, Informative)

DigitAl56K (805623) | more than 5 years ago | (#26480111)

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.

Re:The Best Defense is Offense (2, Informative)

thetartanavenger (1052920) | more than 5 years ago | (#26480057)

NoScript breaks my online banking. Yeah it's a good idea and I tried to use it for a while, but I found that no matter what exceptions I gave it when it came to my bank, it refused to allow me access. Don't know why, but it kinda kills your argument if you have to turn NoScript off completely to use your online banking.

Re:The Best Defense is Offense (1, Insightful)

Anonymous Coward | more than 5 years ago | (#26478705)

Unfortunately, the police can't do squat when the bad guy is operating out of Elbonia.

Re:The Best Defense is Offense (1, Troll)

X0563511 (793323) | more than 5 years ago | (#26478731)

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 (0)

Anonymous Coward | more than 5 years ago | (#26478821)

Because what is illegal here may not be in Elbonia and vice versa. What if posting a Youtube link is illegal in Elbonia and they send someone here to make the guilty "disappear"?

Re:The Best Defense is Offense (2, Funny)

Anonymous Coward | more than 5 years ago | (#26478973)

Of course we would then have to send someone to Elbonia to disappear the disappearers.

In fact we could lay traps for them by disappearing people in a country where that is illegal and then see who comes after them.

Re:The Best Defense is Offense (4, Insightful)

eln (21727) | more than 5 years ago | (#26478993)

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.

Re:The Best Defense is Offense (1)

calmofthestorm (1344385) | more than 5 years ago | (#26479409)

No but we can request that they be extradited or, failing that, tried there, for the crimes that are illegal in their own country.

Re:The Best Defense is Offense (1)

Dasher42 (514179) | more than 5 years ago | (#26479423)

I've got a question. Where did the parent say anything about "disappearing" anybody? Instead I thought that was a good approach to finding and prosecuting phishers of this variety.

Re:The Best Defense is Offense (0)

Anonymous Coward | more than 5 years ago | (#26479623)

Cnsitutions are laws of the state, so, as any other state law, just cover that state's territory, so your belief is quite wrong.

Also, all countries do have information services and agencies(CIA and NSA in the US, MI5 and MI6 in UK, DIS, AISE and AISI in Italy, and so on...And many others we don't even have knowledge of probably, like what Gladio was in Italy), just do do what they should or could not do if they just respected the laws.

Re:The Best Defense is Offense (1)

rolfwind (528248) | more than 5 years ago | (#26479871)

No idiot. The Constitutions defines the US Government and therein always binds the US Government when it acts, no matter what, where, or when. At least that's the theory.

Just because the government is acting outside of state boundaries, doesn't give it the means to do whatever the hell it pleases.

Re:The Best Defense is Offense (1)

moderatorrater (1095745) | more than 5 years ago | (#26478751)

Police have boundaries and borders. The internet, alas, does not.

Re:The Best Defense is Offense (3, Insightful)

blueg3 (192743) | more than 5 years ago | (#26479097)

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.

popups (1)

DeadDecoy (877617) | more than 5 years ago | (#26479157)

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.

Re:The Best Defense is Offense (2, Interesting)

retech (1228598) | more than 5 years ago | (#26479227)

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

Re:The Best Defense is Offense (3, Funny)

Gerzel (240421) | more than 5 years ago | (#26479557)

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.

Re:The Best Defense is Offense (0)

Anonymous Coward | more than 5 years ago | (#26479571)

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

Except that you'd end up bombing schools and hospitals, even if you get the tracing right, because that's where the phishers will move then. And their host country would probably declare war, and/or support more terrorists attacking Americans where ever...

Re:Schools! (1)

TaoPhoenix (980487) | more than 5 years ago | (#26479887)

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??

Re:The Best Defense is Offense (5, Funny)

ushering05401 (1086795) | more than 5 years ago | (#26479705)

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.

Re:The Best Defense is Offense (1, Interesting)

Anonymous Coward | more than 5 years ago | (#26479361)

Is that what interpol is supposed to be doing but if I recall right they are doing alot of work on getting fans to stop downloading music why dont they arrest the real criminals :(

Re:The Best Defense is Offense (1)

ushering05401 (1086795) | more than 5 years ago | (#26479775)

Is that what interpol is supposed to be doing but if I recall right they are doing alot of work on getting fans to stop downloading music why dont they arrest the real criminals :(

Interpol doesn't really work like that.

Each member country has an NCB (basically a central office) staffed by their own agents that can escalate issues through Interpol. So if Interpol is looking at piracy, then that started within a member nation's NCB, was escalated, and was deemed a valid cause by enough other member nations to become an agenda item. Furthermore, the only part Interpol would be interested in is assisting the actual enforcement officers in sharing information with other participating member nations, or facilitating training for participating members that do not have the resources to pursue a particular class of crime.

Interpol is an organization composed of 'Secretary General' types and special counsels. They only facilitate cooperation and are relatively poorly funded these days.

There is another organization known as the International Police that are actually police who arrest people, but they only operate in areas without the capability to raise a police force (ie: war torn countries).

Re:The Best Defense is Offense (1)

azenpunk (1080949) | more than 5 years ago | (#26479433)

you know, i used to wonder if a malware site could look across into another tab and look at what i was typing. guess i'm closing the browser and restarting a single tab to do banking stuff now.

Of course there is a technical solution (1)

Ed Avis (5917) | more than 5 years ago | (#26479607)

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.

Re:The Best Defense is Offense (0)

Anonymous Coward | more than 5 years ago | (#26479639)

Yeah, those Russian & Chinese guys are shaking in their chapkas about the FBI all right.

Re:The Best Defense is Offense (1)

macraig (621737) | more than 5 years ago | (#26479735)

This is precisely the sort of evolutionary cat-and-mouse game that is likely to lead to the first true artificial intelligence. It won't be some well-meaning altrustic researcher in some AI lab, it will evolve out of this cyber-warfare.

Re:AI (1)

TaoPhoenix (980487) | more than 5 years ago | (#26479903)

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

XSS (4, Informative)

AKAImBatman (238306) | more than 5 years ago | (#26478671)

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 (5, Insightful)

AKAImBatman (238306) | more than 5 years ago | (#26478737)

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 (1)

camperdave (969942) | more than 5 years ago | (#26478833)

Wouldn't this mean they'd have to ping every bank? If I bank at www.otherbank.com, loading anything from www.mybank.com isn't going to get them very far. Now, if they sniffed my temp folder for lock.gif or other footprints... that might work.

Re:XSS (1)

Culture20 (968837) | more than 5 years ago | (#26479033)

It doesn't take them any more time to "ping" the top 20 banks than it would just one. It's all done by your browser on your machine in response to a web page. It's just the difference of 20 img tags or just 1.

Re:XSS (3, Interesting)

Animaether (411575) | more than 5 years ago | (#26479045)

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.

Re:XSS (5, Interesting)

AKAImBatman (238306) | more than 5 years ago | (#26479127)

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] ?

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.

Re:XSS (2, Insightful)

RockMFR (1022315) | more than 5 years ago | (#26479139)

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.

Re:XSS (1)

FalleStar (847778) | more than 5 years ago | (#26479141)

Looking for protected images is one of the ways that can be used to determine if the user is viewing the website; however there is another way [securityfocus.com] apparently.

As you can see IE, Firefox, Safari & Chrome are all included on the vulnerable list.

NoScript will (as usual) keep you protected however.

Re:XSS (2, Insightful)

hairyfeet (841228) | more than 5 years ago | (#26479373)

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.

Re:XSS (0)

Anonymous Coward | more than 5 years ago | (#26480037)

The defense is much simpler than changing the cookie model: Just give all resources which are only available after login a "salted" URL. So name the image "https://bank/image.jpg?salt=5937853240596428465135542" for that particular user and make it so that only salted URLs are dependent on log-in. The other page can't guess the salt, so it can't try to load the image to see if the user is logged in.

Yes, this does break caching, but there are only two sensible options here: Either the availability of the image depends on a log-in, then it shouldn't be cached in the first place, or the availability does not depend on the log-in, then you shouldn't use salted URLs and the image should be available whether the user is logged in or not.

Re:XSS (0)

Anonymous Coward | more than 5 years ago | (#26479685)

This has nothing to do with XSS. RTFA.

Simple Solution... (4, Informative)

Klootzak (824076) | more than 5 years ago | (#26478691)

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

Oh, and use NoScript! [noscript.net]

Re:Simple Solution... (1)

Bozzio (183974) | more than 5 years ago | (#26478709)

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... (4, Insightful)

X0563511 (793323) | more than 5 years ago | (#26478757)

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... (4, Informative)

Klootzak (824076) | more than 5 years ago | (#26478759)

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 ;)

Re:Simple Solution... (1)

calmofthestorm (1344385) | more than 5 years ago | (#26479459)

HOW CAN I INSTALLS NOSCRIPTS ON MY WINDOWS MICROSOFT EXPLORER VISTA? KTHANKSBYE!

Sarcasm aside, that's not going to cut it. We may be in an arms race, but we do need to try to keep up. The internet should not just be for technogeeks any more than medicine should be only for doctors. But I guess you can argue that this is like a doctor telling you to eat well, excercise regularly, and lose Windows--erm, weight.

Re:Simple Solution... (0)

Anonymous Coward | more than 5 years ago | (#26480155)

Nice of you to help other people Klootzak.

Sorry, couldn't resist;)

(For non dutch people, Klootzak=asshole/dick/very bad person/smeerlap)

Re:Simple Solution... (0, Flamebait)

Anonymous Coward | more than 5 years ago | (#26478953)

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.

You're onto something, but I'd like to kill the problem at its source: The fuckwit marketroid goons who demand the use of Javashit on the fucking login page in the first place.

(I'm not a fundamentalist about this. There may be legitimate reasons why you might want to use Javashit, served via https, to customers who are already logged into a banking website. But there is no legitimate reason to use Javashit on a login page.)

Sorry if I come across as bitter. I remember the first fucking time that Bank of America switched to the "new and improved" login page. I saw so many flashes to "www.liveperson.com" that I thought the box had been compromised.

Turns out that the domain was a legitimate provider of "outsourced chatbot-in-india" services. The stupid marketing motherfuckers at BAC were loading third-party Javashit so that n00b customers too stupid to figure out "login" and "password" could resolve their confusion by "chatting with a live person". In so doing, they exposed all of their customers to risk, because one required Javashit to log into the damn site in the first place. I uttered a few more oaths too foul for even the tender ears here, and blocked the goddamn domain just out of spite.

Anyways, you're right in that the root cause of this problem isn't n00bs who don't know how to install something like noscript. The root cause is the clueless twats at the banks, who disallow logins from users with Javashit deactivated.

Seriously, you don't need Javashit to accept an entry - be it login, acceptance of a third-factor authentication, or a password - in an https:/// [https] form.

Don't use Javashit on the login page, and then users won't have to turn enable the security hole in order to log into the website.

Re:Simple Solution... (0)

Anonymous Coward | more than 5 years ago | (#26478965)

"register WITH noobs"

damn, I wish I had proof-read that last commie.

Re:Simple Solution... (1)

Spacejock (727523) | more than 5 years ago | (#26478915)

I second that. I've been using noscript for years, and wouldn't browse the net without it.

thus making the web suck ass (1)

r00t (33219) | more than 5 years ago | (#26478955)

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.

Re:thus making the web suck ass (1)

SleepyHappyDoc (813919) | more than 5 years ago | (#26478999)

Are you suggesting I shouldn't be able to cut a link from one window and paste it into another? What about legitimate cross-site scripting, like using your Facebook account to comment on Gawker Media blogs? It's not nearly so black-and-white.

Re:thus making the web suck ass (0)

Anonymous Coward | more than 5 years ago | (#26479421)

Nobody wants to disallow cut and paste. What a straw man.
And if site A wants me to use my account on site B, it should ask me for my OpenID. There's nothing legitimate about login info (and logged-in state is login info) being shared automatically between browser tabs, without even an option to disable it.

Re:Simple Solution... (1)

postmortem (906676) | more than 5 years ago | (#26479077)

I do that practice, because I never know what other sites are doing. However this might not be sufficient for two reasons: 1. Well crafted site could manage to remain hidden after you navigate it, by simply having some event-driven routine that is called when user leaves page - we all have seen these popups when you leave the page. 2. Firefox is known to keep your viewed pages in RAM, even after you leave the site. I assume that this is well guarded and probably secure.

Re:Simple Solution... (3, Interesting)

j01123 (1147715) | more than 5 years ago | (#26479177)

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.

Re:Simple Solution... (1)

Cato (8296) | more than 5 years ago | (#26479511)

Thanks for the tip. At least for Firefox 3 on Linux, this is set to true by default.

And it's been there all of these years (1)

SpaceLifeForm (228190) | more than 5 years ago | (#26478693)

Funny how I got a Flash ad thrown my way when I visited the link.

Re:And it's been there all of these years (1)

stonedcat (80201) | more than 5 years ago | (#26478755)

Change all your bank accounts and destroy your computer quickly! The bad guys are gonna get ya!

Things to learn from this. (5, Insightful)

john.picard (1440397) | more than 5 years ago | (#26478749)

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.

more fixes for the security model (3, Insightful)

r00t (33219) | more than 5 years ago | (#26478983)

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.

Re:more fixes for the security model (1)

h4rm0ny (722443) | more than 5 years ago | (#26479781)


Oddly enough, this is something IE7 did (by displaying a very annoying mixed-content warning) but which Firefox 2 did not by default (though you could turn it on). I'm not sure about Firefox 3.

Re:Things to learn from this. (5, Interesting)

Fian (136351) | more than 5 years ago | (#26479027)

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:Things to learn from this. (1)

sonamchauhan (587356) | more than 5 years ago | (#26479137)

Does Google's Chrome browser do something to this effect? I recall something about Chrome each webpage in an independent process, not as independent threads.

Re:Things to learn from this. (1)

Fian (136351) | more than 5 years ago | (#26479173)

Haven't really looked at Chrome but I'd assume each process (tab) would still be looking at a centralised cookie cache.

Re:Things to learn from this. (0)

Anonymous Coward | more than 5 years ago | (#26479587)

Each process has its own session, so session cookies should be safe.

Re:Things to learn from this. (2, Interesting)

failedlogic (627314) | more than 5 years ago | (#26479537)

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. (3, Interesting)

OpenSourced (323149) | more than 5 years ago | (#26480055)

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.

Re:Things to learn from this. (4, Insightful)

ljubom (147499) | more than 5 years ago | (#26479257)

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:Things to learn from this. (2, Interesting)

labnet (457441) | more than 5 years ago | (#26479683)

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 (2, Interesting)

Anonymous Coward | more than 5 years ago | (#26478769)

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 (3, Interesting)

dmomo (256005) | more than 5 years ago | (#26478787)

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:The article doesn't describe the actual exploit (1)

The MAZZTer (911996) | more than 5 years ago | (#26478817)

It's called Cross-site scripting [wikipedia.org]. Except in this case I don't think XSS exactly describes the type of attack we see here.

Re:The article doesn't describe the actual exploit (2, Informative)

dmomo (256005) | more than 5 years ago | (#26478967)

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.

Re:The article doesn't describe the actual exploit (1)

SlashRSlashN (1036626) | more than 5 years ago | (#26478963)

"cURL" out to those sites?
Sir, if we had the credentials needed to send a cURL request with your cookies (to see if you were logged in), you've already been hijacked. (cURL requests are server-side.)

The vulnerability comes more from the fact that some browsers let JavaScript "see" what the URL of another window is.

Oh, that, and many people won't notice that the URL isn't form their bank.

Funny, though. A modern pop up blocker will stop this 9/10 times (unless you do the infamous body.onclick trick).

Re:The article doesn't describe the actual exploit (1)

blueg3 (192743) | more than 5 years ago | (#26479107)

It's true. There's been quite a bit of research into it, mostly at Google. While you might not be able to pick a particular high-profile site and sneak JavaScript onto it, getting your JS onto "high-profile sites" in general is not difficult.

Re:The article doesn't describe the actual exploit (1)

sugarmotor (621907) | more than 5 years ago | (#26479919)

What if the cookie of the target site is against a host name such as

http://094ec182f4a74bc1382206407.bank.com/ [bank.com]

The attacker would not waste their time trying to guess the (randomly generated) 094ec182f4a74bc1382206407 part.

So when you login your logging in with a host name with a token.

Stephan

Re:The article doesn't describe the actual exploit (1)

Terrasque (796014) | more than 5 years ago | (#26480109)

That's actually a pretty interesting idea. They could for example allocate *.in.bank.com for this purpose.

This would of course have to be in addition to all other security layers.

Not common yet.....? (1)

biocute (936687) | more than 5 years ago | (#26478819)

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.

Already dedicate browser sessions to banking only (1)

Raul Acevedo (15878) | more than 5 years ago | (#26478827)

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.

Re:Already dedicate browser sessions to banking on (4, Informative)

totally bogus dude (1040246) | more than 5 years ago | (#26479671)

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.

Is Chrome vulnerable? (1)

olddotter (638430) | more than 5 years ago | (#26478851)

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.

maybe being obsessive pays off (1)

NotQuiteReal (608241) | more than 5 years ago | (#26478861)

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.

Re:maybe being obsessive pays off (1)

Spacejock (727523) | more than 5 years ago | (#26478951)

For some reason, FF 3.0 freezes for about eight-ten seconds after I start it up, every single time. It's very, very irritating, and the behaviour encourages me to leave it open as much as possible. (This never happened with FF 1 or 2)

I have a dual core cpu with gigs of ram, so it's not a hardware issue. Running another profile (with few bookmarks) on the same PC doesn't exhibit the same problem, and I can only assume it's the browser rechecking links, favicons or something else every time I start it up. (places.sqlite is 31mb)

I disabled the url security thingo which reads/writes the 10mb urlclassifier2.sqlite file, but that made little difference. I guess I could delete 90% of my bookmarks, but I really don't want to do that.

you don't use web email (1)

r00t (33219) | more than 5 years ago | (#26479015)

You might have an account, but you certainly
aren't depending on it and getting lots of
email through it.

New ways to steal. (1, Offtopic)

dinther (738910) | more than 5 years ago | (#26478937)

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.

The article makes it sound so simple... (1)

BUL2294 (1081735) | more than 5 years ago | (#26479001)

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

Re:The article makes it sound so simple... (4, Insightful)

blueg3 (192743) | more than 5 years ago | (#26479125)

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.

Ban Pop-ups (1)

Spy Hunter (317220) | more than 5 years ago | (#26479007)

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.

Re:Ban Pop-ups (2, Interesting)

robo_mojo (997193) | more than 5 years ago | (#26479121)

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 differently. I like the one where the alert becomes an infobar. If you aren't on that tab when the alert happens, you won't be forced to see it, and it can't interrupt anything else you're doing.

In the meantime, closing all open browser windows before you visit your bank site is still the safest thing to do.

A 'secure mode' for browsers? (4, Insightful)

dnwq (910646) | more than 5 years ago | (#26479095)

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.

Oh those nasty promiscuous cookies (0)

Anonymous Coward | more than 5 years ago | (#26479261)

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 [mozdev.org]. It should be default behavior of browsers.

I thought I was paranoid (1)

zeldorf (1448633) | more than 5 years ago | (#26479647)

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?

Javascript *is* a typical attack vector (1, Insightful)

Toffins (1069136) | more than 5 years ago | (#26480019)

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

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.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Sign up for Slashdot Newsletters
Create a Slashdot Account

Loading...