molly.com
Saturday 16 February 2008
One Very Phishy Reason to Love IE7?
I’ve been in a wonderful hotel here in Wellington, New Zealand alas, with the crappiest connectivity ever. Then, something rather suspicious began to happen.
Note the URLs – they are the same in each case. Note that the sites are in fact, not the same.
Curious, I thought I’d put a few browsers to the test. Here you see Camino (seemingly) rerouted to someone’s phishy site. Firefox, Opera, Safari and Shiira all FAILed.
Here’s IE7, on Vista, in parallels on my MBP.
Well, that’s just very strangely impressive indeed.
Filed under: browsers, ie7, microsoft, software, standards, web design and development
Posted by: Molly | 05:37 | Comments (28)
It’s possible this may have more to do with Vista via Parallels than IE7 – an alternative theory might be that Windows Vista has cached the site (pages or dns) from a previous visit…
Ian: no cache. I don’t use IE7 for browsing, only for running tests! I’ve never browsed to my own site ’til this little test within this install of Vista or IE7!!!
From what I have read, Microsoft’s phish database was having some connectivity problems that, was in essence, defeating its purpose and intent. Haven’t run into that issue over the last 6 months, perhaps 9, or so.
It is, also, a prudent reason why consumers should upgrade to IE7 and possibly, among other things, why developers should help push IE7 through distribution.
Have always believed that it was and is foolish, on many grounds, that a centralized phish database doesn’t exist and that implementation is and has not been standardized across browsers. Sort of sounds like a job well suited for the W3C, perhaps.
But hey, everyone wants to worry about things like box models and how pretty their sites look and the consistency of that across browsers and platforms. Priorities. Go figure.
Hi Molly, I guess what I’m saying is that saying it’s down to IE7 is possible but perhaps a step too far given there’s a different OS and a virtual machine involved. Do you have Firefox and/or Safari installed in Vista too? Would be worth checking those to rule out the os/vm.
Ian: FF in Vista: FAIL.
Don’t have Safari for win installed.
So why on earth is Camino (and the rest) showing some ad-link site?
Consequences could be scary with all the passwords going in the ether unprotected …
I guess that a rogue DNS server was reached by the MBP and that Vista bypassed this and used a prerecorded IP? Or is it something else? Strange that a prerecorded IP in Vista wouldn’t be one of the first targets to be rerouted to a rogue server by mr/mrs bad guy/girl, so I maybe completely wrong. Do you use always the same DNS servers wherever you could be in the world or is there some form of DHCP involved? Guess you should disable it!
Which site is reached when the anti-phishing feature is disabled? After all, there are other reasons than the anti-phishing feature to explain why IE7 wasn’t affected. But perhaps the test is useless now that an IP has been cached by the OS, and a Vista reinstallation is quite an overkill for the purpose of a test!)
Yeah, it surely is a curiosity! I didn’t think to disable the fishing feature, and it would appear that whatever was going on has been repaired because all is working well now.
VERY WEIRD!
What you experienced is not a true phish issue, I believe. Having run across the same thing you experienced, it may be a DNS resolution issue that defaults to an ISP or hosting company default search page. In my experience, a page refresh will resolve the issue.
That is my uneducated guess.
Maybe a DNS problem. Who knows, really, but one thing is certain – as soon as the problem cleared, the broadband returned to excellent performance after being absolute shite. So if not something phishy, there was definitely something fishy going on.
Oh, and Thacker, refresh didn’t help. What’s more, why would a default search page explicitly say “molly.com” and the URL be identical in each case?
Molly–
Honestly, I don’t know. I have seen that page in question before along with others of similar format .. whether it was explicitly your site, I can’t recall. But I have experienced this same issue on occasions and across a wide array of browsers. This includes AOL wherein at times when a known site address is inputted, an AOL search page will appear.
If your connection was slow, that might point to a DNS resolution problem perhaps? Hell, again, I simply do not know. Someone will come along and provide an answer, I am sure.
Definitely a DNS issue. Hard to figure out exactly what the deal was without having been there myself and testing some things. But the site appears to be a generic domain parking site. I dug around and found http://blogmusic.com/. Look familiar? I imagine there are many more like it. It builds the page based on the host that it’s requested as, hence it had a “molly.com” header when you saw it. (you can confirm this by adding an /etc/hosts entry that points whateveryouwant.com at 75.126.144.222, then load whateveryouwant.com in your browser). blogmusic.com is hosted on server1.instealthmode.com. Going directly to server1.instealthmode.com, you get “This domain has just been registered for one of our customers!” so it really looks like some sort of generic domain parking service.
So my best guess at what happened was that your ISP there (or the hotel, or whatever), through misconfiguration or evil intentions (probably the former), screwed something up with DNS so molly.com was resolving as 75.126.144.222. At some point in the recent past some other windows app on your machine had made a DNS request for molly.com and windows cached the (correct) info. IE is really aggressive about using any kind of cached anything that it can to make things faster and, being tied in so closely with the rest of windows, found the cached records and used those. FF on windows wouldn’t simply because it’s not as aggressive about caching.
Molly-
You know what I think it is?
I think Microsoft commandeered your site for a brief instance in time. They took hold of it and made sure that no other browser could find it. THEY TOOK YOUR SITE HOSTAGE MOLLY!
What would posses Microsoft to do this, I have no idea. But I think it is safe to assume that something is indeed fishy. Watch your back Molly. We can’t afford to lose you!
Definitely agree with anders that this is DNS-related. I’ve seen the same domain parking sites as well, and once spent 15 minutes on the phone trying to explain how it worked to a client who had let his domain name lapse.
As for what might be causing the bad DNS info, is this a wired or wireless network? If wireless, it’s possible someone could have brought their own access point, set it up to use the same info as the hotel network, and put bad DNS in it.
Or for a more mundane explanation, perhaps the hotel’s ISP was having intermittent DNS problems, and lookup failures are set to return the IP address of a parking server instead of saying the domain was not found.
DNS issue, will be the hotel DNS, these are also under attack and frankly you should avoid using the default and used a trusted external.
Mind you some hotel force you to use theirs via the proxy etc. Bottom line when using hotel connections expect to be attacked ensure you have a secured connections for everything.
Clearly a DNS issue, though Mac OS X Leopard will take a while to notice the change. You need to run “dscacheutil -flushcache” from a Terminal to make it forget the cached IP.
(Windows also suffers from this, the equivalent voodoo is to restart the “DNS Client” service); in this case, it’s unclear whether it’s the Vista VM using different DNS servers, or the phishing filter doing something clever to avoid poisoned DNS.
I concur that this must be an DNS issue. I have sometimes as a prank edited the C:\Windows}system32\drivers\hosts file (/etc/hosts on *nix, but people who use that OS seem to know about theese issues…) to achieve similar effects.
Now, Molly, I would thoroughly investigate this issue as it might be a vulnerability in some DNS-related setting. I would have checked HTTP-headers, name servers, etc. It’s time to dig, nslookup and checkout whois!
I’ve seen that site before, it is a generic parked domain site.
Maybe the Hotel’s ISP is the owner of the parked domein site and shows that page for everything it can’t resolve something.
The hick up in the connectivity might have been at the ISP’s (including nameserver), not the Hotel.
Did you actually try Opera with the anti-phishing feature turned on? :p
As have been mentioned by several others, this is a generic parked domain page. Title of the page addapts to the domain name, contextual ads are loaded based on the domain name (and/or inbound links, directory listsings etc). If you’d clicked any of the links on the page you’d travelled further down the rabbit hole and been presented with a page with paid search results (possibly from information.com).
Ads on parked and/or expired domain names is a billion dollar “industry”. Can’t remember the provider with the layout you found, though its quite common (possibly it’s domainsponsor.com).
Looks like you’ve received bad/spoofed DNS info, resulting in molly.com resolving to the wrong IP and loading such a parked page. As have been mentioned earlier by others, IE probably used a cached value or simply got the correct results when querying the DNS server (nothing to do with IE doing a better job though).
Although these parked pages often are questionable, annoying, missleading etc, a phishing filter should not filter such sites/domains.
Word of warning – verizon has started trapping and re-routing unhandled 400 and 500 series error codes to their own search engine page – so if you have a server-time out due to load while accessing a website via verizon broadband here in the states, you get verizon search instead of the error code… and you have to flush your cache manually to get the page you wanted.
This redirect you hit could be something similar.
thanks
thanks
thanks for sharing.
thanks
thank you tube
That is my uneducated guess.