Mozilla Partially Vulnerable to Internet Explorer URL Spoofing Security FlawThursday December 11th, 2003koody wrote in to tell us that Mozilla is partially vulnerable to the recently announced URL spoofing security hole in Internet Explorer. The latest IE flaw allows an attacker to disguise the true domain of a URL in the browser's Address Bar, allowing a page located at evilscam.net to appear to be from microsoft.com. This exploit can be used to increase the effectiveness of the so-called 'phishing' scams that have recently been used to target customers of PayPal, eBay and several online banks. The Address Bar URL spoofing flaw was originally reported by Sam "Zap The Dingbat" Greenhalgh, who provided details of the exploit and a demonstration. Security company Secunia issued an advisory about the vulnerability, with an update from Chris Hall reporting that the URL shown in the Status Bar while mousing over a link to a spoofed page is also affected. While Mozilla-based browsers such as the Mozilla Application Suite and Mozilla Firebird are immune to the more serious Address Bar spoofing, they appear to be vulnerable to the Status Bar variant. The Secunia Internet Explorer Address Bar Spoofing Test page demonstrates both the full flaw in IE and the Status Bar aspect of it that affects Mozilla. The relevant Bugzilla report is bug 228176, which was filed today and already has a preliminary patch attached (please do not add unnecessary comments to the bug; the developers are already aware of its seriousness). Mozilla users are advised to not rely on the URL displayed in the Status Bar and to check the complete address of the destination page in the Location Bar upon arrival. I don't see anything to indicate that Mozilla is partially vulnerable. My URL bar in 1.6a looks just fine, displaying the whole thing, including the "nonprinting" character. The article indicates that Firebird is affected, but the Mozilla suite seems not to be. Firebird is too buggy for regular browsing duty anyway... In 1.5, I get an odd character after the link in the statusbar, so it's IMO even a partial of a partial vulnerability. That character only appears because they've set up the test incorrectly (from the point of view of testing the Mozilla bug) - all that's needed is a null character %00 in the URL - that has %01%00 and Mozilla tries to display %01 which leads (at least on Linux) to a 'character with no assosiated glyph' symbol. See the test page I set up: http://zeus.jesus.cam.ac.uk/~jg307/test/exploit.html As far as I know, the first case causes problems in both Mozilla and IE, the second only in IE. For the majority of people, this bug only represents something that can't otherwise be acheived via javascript in the case where javascript is not enabled by default (i.e. in mailnews) or in the case where there is a reasonable expectation that the author did not have access to javascript e.g. in weblog comments or other forums. However, in Mozilla, there is an option to prevent javascript from changing the statusbar text - if this is set, this exploit is (as far as I know), the only way to provide a fake address in the status bar. look at *status bar*. Url bar is OK, but not status bar here is next example: www.vivamozilla.civ.pl/rozne/bug.html When U make 'onmouseover' the link you will see microsoft.com in status bar Ok... I didn't read it fully before I replied. Never mind... I see what they mean by "partially vulnerable." The URL in the status bar when hovering over the link said "http://www.microsoft.com" If it were a valid URL Firebird would have said "http://www.microsoft.com/" If you really pay that much attention to what's in your status bar (that you're going to base your navigation on it), you'd probably notice that one character difference. not affected. This problem doesn't appear to affect the current release of K-Meleon. I'm using k-meleon 0.8, and it IS affected When hovered over, the status bar shows the fake URL with a square after it. Once at the destination page, the address bar shows the entire real URL, beginning with the spoofed URL and continuing with @malicious_domain. Unsavvy web surfers could easily mistaken this to be a real page under the official URL when in fact it is not. <i>Unsavvy web surfers could easily mistaken this to be a real page under the official URL when in fact it is not.</i> Yeah, but that's always been true, for all browsers. @-spoofing is something users have to be educated about, of course, but it isn't anything new. What's tricky about this one in IE is, when you go to the destination page, you only see the spoofed URL, not anything after it. With the unprintable character, IE hides the malicious domain. User education is not enough; they would have to check the page source for the link before clicking on a link to be sure it's legit. <i>That's</i> a major problem. <<Yeah, but that's always been true, for all browsers. @-spoofing is something users have to be educated about, of course, but it isn't anything new.>> It isn't, that's true, and that's why Opera warns the user with a little popup that the URL could be spoofed in these cases, which is a clever thing to do IMO. even JavaScript can change the text in status bar, I think people over-reacted. This bug only matters if you turn JavaScript off, or if you're reading an e-mail in Mozilla Mail (and have JavaScript turned off in mail). tested it in opera 7.23 just out of curiousity, and it is not affected. I've just had a silly idea: Should mozilla syntax-highlight the contents of the address field? Nothing too gareish, just a subtle indication of which part is the server name, which part is the path, and which part is the query-string, and so on. Since I am a programmer, I am very used to looking at syntax-highlighted text, and I like it. Then, since it is very rarely used, you could use a really bright colour for the username/password bit, and suddenly phishing wouldn't work any more. Tim. Tim, you might add this your idea as a comment in Bugzilla Bug 184074. The bug is allready about syntax-highlighting in the address bar. Your (not so silly) idea is a valuable contribution to the thinking about this issue. "... just a subtle indication of which part is the server name, which part is the path, and which part is the query-string ..." "... use a really bright colour for the username/password bit, and suddenly phishing wouldn't work any more." #40 Re: Re: Should I file .... syntax-highlight in urlby tobypowell Sunday December 14th, 2003 7:49 AM Gets my vote. That would be the best idea. OR as an alternative, if there is a username and an address, split the address bar into three parts (user, password, URL) so it's blindingly obvious. Then you wouldn't need to muck around with colourising (which strikes me as leading to introduce new bugs / confusion etc. Just my 2p worth Taking the (3) mentioned tests on my (4) browsers, under Windows98, my results are: Opera (7.11): not affected, even gives a security warning pop-up. Amaya (8.1a): not affected. Mozilla (1.5): partially affected (as mentioned above). Internet Explorer (6.0): affected. I thought this @spoofing business had been around for a while? this bug can be just as serious on Mozilla as on IE (even though the URL field is not affected) Look at following scenario: - i view web site "www.misc.com" - I see link to "java.sun.com", hover over link and see that sure.. link leads to java.sun.com - i click on link, and because I am on a fast broadband connection, i dont see the "connecting to www.owned.ru" or whatever because new page loads up very quickly. - when i see url, i see something longer than java.sun.com, but this is happens (redirect), therefore i dont suspect anythign wrong, unless i actually LOOK at the address properly. - click on the download and install Java.XPI - browser asks if i wish to install Java.XPI, and all the crap abotu viruses. - i believe i am in java.sun.com and click ok.. - my computer is 0wned compromised due to false sense of security. Err... First of all, a comment about the link and the status bar: This can be done easily with javascript, at all browsers. And about the fact that the url is redirected, at IE and Mozilla, it is working just like it should be, this is not a bug. If you read the http RFC you will see that you can have ascii letters and some symbols as usernames, so is perfectly legal: anything.written.here@mysite.com The dot is allowed because of names, like: ricardo.mello@mysite.com If this is a type of problem, is a RFC problem. The REAL BUG is the fact of IE hiding the rest of the phrase by the use of the "%01" sequence. []s, gandhi I will be refererring to this: http://vbalex.dyndns.org:8080/linkto.php?url=http://www.microsoft.com/%00@secunia.com/internet_explorer_address_bar_spoofing_test/ This is my home server, so please don't DDoS me. Maybe somebody with a real server could mirror this before I'm completly disabled. IM me at MSN/Y!/AIM: vbAlexDOSMan, Jabber: IReadYourEmail@jabber.org/Home, ICQ: 271781078 for the code. At that URL, notice that it, for one, shows http://microsoft.com/ in the title bar, whereas when you check the source, it's actually the malicious URL. Also, try going into the source view and copying the URL and pasteing it somewhere... It cuts off the malicious part of the URL (not to mention the rest of the line.) Maybe this has something to do with C/C++'s null terminated strings? My friend also says that Opera is vulnerable to the title bar vulnerablility too. I've noticed the title bar vulnerability is non-existant when the 0 character isn't inlined in the code... e.g. %00 doesn't throw it off, but because I'm using PHP to demo this, the %00 is unescaped into the raw 0 character before my code can even touch it. In your example page, the link actually does go to the Microsoft site (at least when I tried it in the Mozilla suite). Because you included the slash after microsoft.com, that ends the hostname portion and the remaining part is simply used as a path to send to that server. Only URLs without the slash right after the "faked" hostname will "work" the way the exploiters wish. Hence, people sufficiently alert to notice the absence of the slash can possibly be clued into something being fishy, though many real site links also leave off the slash because webmasters are lazy about that sort of thing. Sorry, didn't know about that :D URL *with* literal character 0: http://vbalex.dyndns.org:8080/linkto.php?url=http://www.microsoft.com%00@secunia.com/internet_explorer_address_bar_spoofing_test/ And with an escaped character 0: http://vbalex.dyndns.org:8080/linkto.php?url=http://www.microsoft.com%0%30@secunia.com/internet_explorer_address_bar_spoofing_test/ My observation: It only works as advertised if the character 0 is escaped. If the \0 is raw, the link will bring up the actual site displayed (microsoft.com.) I'm tired, and probably sounding stupid. Sorry :) %2f is a slash http://www.microsoft.com%2f%00@www.mozilla.org/ may well display as http://www.microsoft.com/ in a statusbar, though it will not show with the '/' in the address bar The status bar can be changed with javascript, and therefor should not be a trustable source of information on where the link is heading. One can disable Javascript, but the %00/%01 bug/flaw works even when javascript is disabled. Not in Mozilla it doesn't. This is a 100% non-issue as far as I consider. Yes it does. See any of the testcases that are linked here. If I type a URL like http://www.mozilla.org%00@microsoft.com then the status bar displays http://www.mozilla.org This is significant because there are many many situations in which people are free to enter this type of URL but cannot use scripts - for example in email (by default). Since this type of scam is most obviously carried out in an email, the people who are saying "this doesn't matter, since javascript can do this anyway" are totally missing the point. I'm seeing this problem, as jgraham mentions in comment 30. One thing of interest that people haven't expounded on yet: For, I believe, the first time, Mozilla and IE are known to have very similar security violations, both found at the same time. If Microsoft were to come out with a patch before Mozilla can solve the bug, it may support a stand that they can fix bugs faster than the open source community. On the other hand, if Mozilla can fix the bug, wouldn't it be nice to note that we beat MSFT to the punch (again)? Depends when you count the bug as "fixed". Microsoft releases binary patches for users to update with. Mozilla might get the source code fixed quickly, but people who just download a release binary won't get a fix until the next release. And the bug in Mozilla is similar, but not as serious. It only applies to the status bar, which people with script enabled can't trust anyway. I don't think the bugs and products are similar enough that simple comparisons can be made. the website says that the latest release of kmeleon has this bug fixed..! The bug in Mozilla and the bug in IE are NOT of the same severity. The status bar has never been a "trusted source" of information, whether or not you turn javascript off and then believe it to be a trusted source. After you click a link the address bar will tell you the url in Mozilla and that is the source you should trust. This is why it's a huge vulnerability in IE. Also note that if you right click on these "spoofed" url and click properties you get the correct url. So even thought this is a bug and should be fixed. It is not a security threat at all. I found some of the comments a bit arrogant, so I am throwing in a webpage. http://www.xs4all.nl/~beukrode/spoof.html p.s. leave your javascript at home. This comment is probably unfounded (for the average user), but the easiest fix. Use a reliable OS (Linux, etc...) I am running Mozilla 1.x which is vulnerable to the status-bar spoof, but I really don't care as it is running on a Linux box. All of those nice auto-executed and variety of trojan software that M$ is plagued with really isn't a problem (for me). If you want piece of mind to browse and carry on daily computing activities, don't work on an OS that is notorious for being owned due to internal flaws (RPC, etc.). (Sorry to those who don't agree, had to throw my two-cents in for this thread) RPC was long a big flaw in linux before it ever was windows. In windows you can easyly counter this by shutting down the dcom-service without concequence. There is even a button for it in the windows-gui. Most holes in windows can be easely killed by the user. And you can freely use ZA. Mayby I should throw in another webpage? |