Phishing with XUL: demonstration of address bar spoofing

danm · Post by **danm** » July 19th, 2004, 11:34 am

Remote XUL is a pretty awesome security issue. I've been lobbying to restrict it even more, but even tiny steps in this direction garner howls from the community that wants to write legitimate XUL apps. For now, if you're concerned about this you can set various of the window_open_feature prefs such as

dom.disable_window_open_feature.menubar=true

Do this and visit rat144's demo page, and it's obvious something's amiss.

Fusion · Post by **Fusion** » July 19th, 2004, 11:37 am

A few comments:

First, I don't think any solution that changes the appearance or behavior of legit sites should be relied on. People just won't make the connection. People don't look for the lock icon as it is. I would consider some type of warning on illegitimate sites to be the minimum level of defense.

Next, lets look at the big picture. I don't think we can really consider this a JavaScript issue, and I don't think we should mess with JavaScript settings to fix it. The real issue is that XUL can be used to display just about anything a person wants. There may be repercussions for this beyond faked-up web pages. XUL is the real problem, I think. It's also fundamental and necessary, of course.

What about a warning dialog for remote pages that load XUL? OK, Kylotan already suggested this, as well as another idea that I like a lot: Warning if a page contains a password field but is not secure. Is there any reason that these would be problematic, or fail to address the problem well?

rat144 · Post by **rat144** » July 19th, 2004, 12:35 pm

Fusion wrote:What about a warning dialog for remote pages that load XUL? OK, Kylotan already suggested this, as well as another idea that I like a lot: Warning if a page contains a password field but is not secure. Is there any reason that these would be problematic, or fail to address the problem well?

Fusion: Can we assume that no bad guy will ever obtain a certificate from a trusted CA? I don't think we can rely on this. What if the bad guy makes a legit e-store, and asks verisign for a certificate? They'll eventually give it to him, so any page on his domain will get a padlock. Now all he has to do is put up a phishing page. This bypasses the warning.

danm wrote:Remote XUL is a pretty awesome security issue. I've been lobbying to restrict it even more, but even tiny steps in this direction garner howls from the community that wants to write legitimate XUL apps. For now, if you're concerned about this you can set various of the window_open_feature prefs such as

dom.disable_window_open_feature.menubar=true

Do this and visit rat144's demo page, and it's obvious something's amiss.

danm: Yes... but unfortunately, I can remove the menubar from the spoofed browser, and then things add up right again. The only things that I, as a bad guy, need to have hideable are the location bar and the status bar (dom.disable_window_open_feature.menubar, dom.disable_window_open_feature.status), and I still contend that even if the real status bar is underneath a fake status bar, most users would just shrug their shoulders and not get concerned.

I think disabling or limiting XUL is may be the best way to go. Yes, lots of people say that they want to write the world's most amazing XUL web-application, but honestly here, who has? How many sites would we break if we limit XUL support (except from a list of excepted websites, like the popup blocker's "Permissions"...)?

Warning: This website (www.spoof-forge-fake-phish.com) is requesting application privileges. You should only allow this if you know that this domain is trustworthy. Where do you want to go today?
[Do not trust] [Allow limited application features] [Give full trust]

polidobj · Post by **polidobj** » July 19th, 2004, 1:42 pm

I think we can follow what java applets do and keep XUL in a sandbox. And clearly letting any site configure you're browser chrome or access your profile is outside of that sandbox. So don't let it happen. I don't know of anyone who browses around without their addressbar. This thread is a good backup of that :
http://forums.mozillazine.org/viewtopic.php?t=98232

Other measures can and should be taken but this should be done. If your XUL app needs more than that then it should run on its own outside the browser. There's alot we can learn from Java.

"Java security relies on three prongs of defense: the Byte Code Verifier, the Class Loader, and the Security Manager. Together, these three prongs perform load- and run-time checks to restrict file-system and network access, as well as access to browser internals. Each of these prongs depends in some way on the others."
http://www.javaworld.com/javaworld/jw-0 ... urity.html

While a byte code verifier wouldn't work because XUL is interpreted and not compiled in any way, The other 2 can be followed. Like classes that are from the applet don't have as much security clearance as built in classes.

michaell522 · Post by **michaell522** » July 19th, 2004, 2:32 pm

rat144 wrote:I think disabling or limiting XUL is may be the best way to go. Yes, lots of people say that they want to write the world's most amazing XUL web-application, but honestly here, who has? How many sites would we break if we limit XUL support (except from a list of excepted websites, like the popup blocker's "Permissions"...)?

I don't really see how that helps - the current batch of phishers are using bitmaps to mimic the IE UI. If they can't use XUL and they want to spoof Firefox/Mozilla, they can do it with bitmaps instead. As you say, the appearance doesn't need to be that close - get it pretty close and people won't notice.

I don't think restricting remote XUL would be a huge issue - you could do a whitelist type thing, like with pop-ups and now XPIs - but I don't see how it solves the problem.

danm · Post by **danm** » July 19th, 2004, 2:51 pm

polidobj: Remote XUL is already very limited in what it can do. Phishing is the only vulnerability known in recent builds.

rat144: Remote XUL is important to Mozilla. Folks are working on seamless web applications, and they claim to be stymied by the restrictions already in place, although the complaints I've heard seem really, really minor to me. Search for forum messages from deepgloat to see an unsatisfied customer.

Your warning dialog would be the effect of bug 248207. It's languishing, though. Other solutions aimed more toward opening up XUL a little more seem to be carrying the day. Personally I'm more on the fearful side.

michaell: I agree there are other, more standard phishing problems as well. But rat144's issue seems the most serious one to me.

Kylotan · Post by **Kylotan** » July 19th, 2004, 2:59 pm

To be honest I don't think the problem can be 'solved' - after all, some people will click through any number of warnings and ignore anything you tell them - but anything we can do to make life more difficult for phishers, such as requiring a whitelist for remote XUL execution and/or the purchase of a secure certificate (which theoretically makes them easier to track down), or showing warning dialogs when submitting forms from pop-ups, is going to reduce the scale of the issue. Which can only be good, right?

Molerat · Post by **Molerat** » July 19th, 2004, 3:30 pm

Kylotan wrote:To be honest I don't think the problem can be 'solved' - after all, some people will click through any number of warnings and ignore anything you tell them - but anything we can do to make life more difficult for phishers, such as requiring a whitelist for remote XUL execution and/or the purchase of a secure certificate (which theoretically makes them easier to track down), or showing warning dialogs when submitting forms from pop-ups, is going to reduce the scale of the issue. Which can only be good, right?

Yeah it seems like people tend to underestimate the power of social engineering. Dialog boxes won't work, nor will warnings and "education." The only solution is to make this kind of exploit impossible in the first place. it comes down to a question of who the intended userbase is. Who is Firefox being developed for? Is it for the developers? Geeks? Hobbyists? The unwashed masses?

Here's a loaded question: what's more important, grandma-proofing online banking, or the wishes of the developer community? Maybe that's an unfair question, and maybe it isn't. You can't always cater to both. Microsoft tried to, and look where that's gotten them. ActiveX anyone? I often see Firefox sold as secure first and extendable second. But there are times such as these when extendability seems to trump secuirty. I think the Mozilla Foundation would do well to decide whether Firefox is secure and extendable, or extendable and secure. It's an important distinction.

rat144 · Post by **rat144** » July 19th, 2004, 4:59 pm

Ok, I posted bug 252198 on it.

I also updated the demo page so that it works with the latest nightly builds.

quickkk · Post by **quickkk** » July 19th, 2004, 6:31 pm

Am I right in thinking that a temporary solution to this phishing problem would be to use the password manager in firefox (or any other browser) to remember my passwords? Before today, I never thought that storing any sensitive passwords was a good idea, but now I think that I've changed my mind. Say that I ask Firefox to store my online banking password and user name, and that one day my bank's site is affected by that XUL problem where I am now taken to a fake login page. Would Firefox recognise that this isn't the same page anymore? Would it simply insert my username and password into this fake page?

If not, then I think that the best solution would be to create a "banking and such" user account (at the operating system level), which would be protected by a good password to prevent unwanted users from accessing your confidential info. You'd only have to enter your passwords a single time and then have the browser input them during your next visit, so even if your unfortunate enough to get some sort of key-logger trojan installed on your system, you'd still be safe. In order for someone to get into your banking account, they'd have to break into your house (I'm only going to use my desktop for sensitive things like banking), and then somehow get into your banking user account. If it's too annoying to switch users to the "banking and such" user, then you'd just have to make sure that you're the only one using your computer, or at least, your personal account.

Anyway, that's just my two cents. This isn't a permanent fix by any means, but I think that this is what I'm going to to from now on. I just hope that firefox's password manager is REALLY secure... (is it?)

big_gie · Post by **big_gie** » July 19th, 2004, 7:02 pm

Molerat wrote:ActiveX anyone?

Thats exactly the point. How can the community bash on IE about its unsecure ActiveX when Firefox has the same philosophy of doing things???

Molerat wrote:I often see Firefox sold as secure first and extendable second. But there are times such as these when extendability seems to trump secuirty. I think the Mozilla Foundation would do well to decide whether Firefox is secure and extendable, or extendable and secure. It's an important distinction.

There could be some well hidden options where the geeks could allow those kinds of things. That way the normal installation, like the one grandma is using, would be protected. But power users could then change this to let it use.

Never will I accept that my browser isn't secure because some people like a feature a minority will use. Hey, thats why we all switched to FF isn't it? And it wasn't even a minority who was using this unsecure thing! Security is so much more important then features. That's what MS never understood, and thats why the mozilla fundation is this popular.

Lets vote for bug 252198 and support FF philosophy.

rat144 · Post by **rat144** » July 19th, 2004, 7:34 pm

quickkk wrote:Am I right in thinking that a temporary solution to this phishing problem would be to use the password manager in firefox ....
... create a "banking and such" user account (at the operating system level), which would be protected by a good password to prevent unwanted users from accessing your confidential info. You'd only have to enter your passwords a single time and then have the browser input them during your next visit, so even if your unfortunate enough to get some sort of key-logger trojan installed on your system, you'd still be safe.

I really like that idea. Thanks to the magicks of certificates and SSL, Firefox can KNOW that it is talking to the REAL banking website. It will produce the password then, and only then. This XUL problem occurs because Firefox is vaguely aware that this isn't a real bank site, but it has trouble communicating that fact to the user.

I almost want to say that the stupid user shouldn't even *know* the password; let firefox decide on an appropriately complicated and random one, and it will fill it in for you when you need it. How can you screw that up? (er... get your ffx profile corrupted...)

But seriously, what if whenever you created an account at some website, Firefox hashed the password you typed in with a hash of the OU on the certificate? You would think that the password is "cat", but really, Firefox sends Hash("cat", "PayPal, Inc."). That way, even if the phisher had a SSL certificate, it wouldn't do him any good, because the password he gets would be Hash("cat", "Phish Industries").

As an added bonus, Internet Explorer doesn't use this scheme, so people would be forced to keep using Firefox if they wanted to access their accounts. Somebody who has taken a class in securitography, please post if this idea is workable/stupid/maybe.

Shadow3333 · Post by **Shadow3333** » July 20th, 2004, 12:48 am

K, i posted in teh bug

Well done rat144, imo a serious security issue.

johnleemk · Post by **johnleemk** » July 20th, 2004, 5:46 am

How badly is remote XUL needed?

big_gie · Post by **big_gie** » July 20th, 2004, 6:01 am

johnleemk wrote:How badly is remote XUL needed?

It isn't, eccept for some power users.

It should be disable by default until a better solution is found, and there could be an option to re-enabling it for power users who still needs it. If enable, we must found a solution for this security flaw...