HOSTS file not working on Win7 64-bit?

[imagoon]

imagoon, can you try actual browsing of the forums.anandtech.com with Firefox 5.0 or Waterfox 5.0, after adding those entries in my first post to the HOSTS file, and see if the browser shows resolving those domain names for several seconds at times, like I see?

I don't quite understand, if they are resolving to 127.0.0.1, then why would I see the browser sit there resolving those domains, for several seconds at a time? Surely, the browser should timeout faster than that. And not all of them for the same duration, some of them pop up only for a split second, some sit there for like 3-4 seconds. If all of the activity was on the local machine, surely there should be consistency in the delays, and there is not.

This is an entirely unloaded quad-core Q9300 @ 3.0Ghz, plenty of CPU time to play with, on a FIOS 25/25 connection.

My earlier testing was on a Zacate 1.6Ghz dual-core, on a Comcast 16Mbit connection.

I don't run firefox 5.0 yet. I typically run with no script / ABP. If I have time tonight during this maint window I'll try it.

 

[Nothinman]

I know that ignoring the file vs caching is different. What I meant is they were doing it for variety of reasons. Malware sends www.microsoft.com to hotnudewomen.com and downloads a "patch" from there? In theory if DNS is botched, the certificate could be faked well enough to make it work. I am not attempting to explain what is going on under the hood there but they might have done something to verify the address like implement an under the covers version of DNSSEC for just their site. I didn't test that hard but it seemed to ignore any non-authoritative replies for example.

NM the non-authoritative thing I manged to get it to use one.

I am not all that interested in trying to tear it apart really.

But just not caching it won't help because you're still doing the resolution via DNS so if DNS is botched you're still f'd. And if you can get a trusted CA to give you a cert for www.microsoft.com, the whole SSL certificate system is broken and untrustworthy.

 

[imagoon]

But just not caching it won't help because you're still doing the resolution via DNS so if DNS is botched you're still f'd. And if you can get a trusted CA to give you a cert for www.microsoft.com, the whole SSL certificate system is broken and untrustworthy.

This actually happened... there was a big thing in the (computer) news about Verisign giving away certs to the wrong people. I'll go digging for my sources when I have time. If you look in your cert store (MS by default, dunno if Linux does it automatically) you will see a large batch of invalidated certs for big websites.

 

[VirtualLarry]

LOL. MS Security Essentials gave me a warning this morning when I woke the PC.

http://www.microsoft.com/security/p...aWin32/PossibleHostsFileHijack&threatid=14994

Apparently, it thought I had a virus, because my HOSTS file was modified. I'm curious as to the heuristic it uses to determine whether the modifications were malicious or not.

I wonder what it will do if I click "disinfect".

Edit: I guess it detected that I had attempted to block several microsoft domain names. When I clicked disinfect, it deleted those microsoft domain names from the list in the hosts file, but left everything else.

 

[Nothinman]

This actually happened... there was a big thing in the (computer) news about Verisign giving away certs to the wrong people. I'll go digging for my sources when I have time. If you look in your cert store (MS by default, dunno if Linux does it automatically) you will see a large batch of invalidated certs for big websites.

I see the revoked certs, but doing what MS has done to "fix" that isn't a fix at all. Ignoring the hosts file has no affect on real DNS lookups or what CAs you should trust, which are where the problems arose. Most of the certs were issued by UTN-USERFirst-Hardware which shouldn't have been in the default trusted CA list anyway. The only other two are for MS and say they were issued by Verisign, so either Verisign got their CA cert and it's private key stolen or someone within their organization did that.

Either their DNS fuckery is intended to workaround a different problem or it was a half-assed attempt that doesn't actually accomplish anything.

 

[imagoon]

I see the revoked certs, but doing what MS has done to "fix" that isn't a fix at all. Ignoring the hosts file has no affect on real DNS lookups or what CAs you should trust, which are where the problems arose. Most of the certs were issued by UTN-USERFirst-Hardware which shouldn't have been in the default trusted CA list anyway. The only other two are for MS and say they were issued by Verisign, so either Verisign got their CA cert and it's private key stolen or someone within their organization did that.

Either their DNS fuckery is intended to workaround a different problem or it was a half-assed attempt that doesn't actually accomplish anything.

It was likely intended to work around the problem of Malware redirecting the site via hosts and preventing things like windows updates from working. This wasn't an uncommon way to keep an exploited machine wide open. Not much different than screwing with DNS (hosts) and redirecting Yum or apt-get to an unauthorized store or simply a dead IP to prevent patching the hole that app was using.

--edit--

Larry's post above yours actually infers that they did it on purpose as well. MSE uses windows updates for example. If they allowed hosts to have the microsoft.com domain it would be an easy way to block updates to it even if the unsigned files wouldn't be loaded.

 

[Nothinman]

It was likely intended to work around the problem of Malware redirecting the site via hosts and preventing things like windows updates from working. This wasn't an uncommon way to keep an exploited machine wide open. Not much different than screwing with DNS (hosts) and redirecting Yum or apt-get to an unauthorized store or simply a dead IP to prevent patching the hole that app was using.

--edit--

Larry's post above yours actually infers that they did it on purpose as well. MSE uses windows updates for example. If they allowed hosts to have the microsoft.com domain it would be an easy way to block updates to it even if the unsigned files wouldn't be loaded.

But unless they hard coded the IPs as well, or forced those specific lookups to use a DNS server they control, they didn't accomplish anything.

 

[imagoon]

But unless they hard coded the IPs as well, or forced those specific lookups to use a DNS server they control, they didn't accomplish anything.

You keep saying that and I am not sure if you believe yourself or not. If they ignore hosts, they are forcing a query out to a system that is likely not infected with malware. I mean if the 'malware guys' own all of the DNS servers, I doubt they could compromise all of them. Maybe if you left your router password "admin" then it could change the DHCP settings. Otherwise I would expect the DNS roots / comcast / ATT / Level3 etc to be clean. Perfect? No. Eliminating 1 issues out of several others? Sure. I certainly don't consider that accomplishing "nothing."

 

[Nothinman]

You keep saying that and I am not sure if you believe yourself or not. If they ignore hosts, they are forcing a query out to a system that is likely not infected with malware. I mean if the 'malware guys' own all of the DNS servers, I doubt they could compromise all of them. Maybe if you left your router password "admin" then it could change the DHCP settings. Otherwise I would expect the DNS roots / comcast / ATT / Level3 etc to be clean. Perfect? No. Eliminating 1 issues out of several others? Sure. I certainly don't consider that accomplishing "nothing."

I think it's just a case of semantics. Forcing a DNS query doesn't fix DNS poisoning because if the DNS server is attacked, the hosts file isn't a problem. They don't have to own all of them, just one or two key ones and their changes will propagate for a while before things can be fixed.

The issue is that I don't consider the hosts file part of DNS, although it is part of the standard resolver libraries. But an easy work around for their hosts file hack is just to include a minimal proxy server, direct all traffic there and do the redirection there. You've already got control of the infected host and installed some ugly, fake A/V so what's 1 more meg of payload? This 'fix' by MS is just retarded duct tape that covers 1, very small, corner case. So sure, they accomplished something, but nothing that actually means anything.

 

[imagoon]

I think I will leave it at this. We are arguing something that I suspect that neither of us have ever bothered to look in to nor will ever bother so we will have never know how far down the rabbit hole goes. There might be more in there but we have no idea nor the time or will to fish it out. Sound good? lol

 

[Modelworks]

Something else to consider is that not all applications use DNS names. I have quite a few that use ip addresses directly . Kind of a bad thing because if the ip changes the program may have problems, but I guess some companies figure they have an assigned address for the next 100 years and don't expect it to change.

 

[Nothinman]

I think I will leave it at this. We are arguing something that I suspect that neither of us have ever bothered to look in to nor will ever bother so we will have never know how far down the rabbit hole goes. There might be more in there but we have no idea nor the time or will to fish it out. Sound good? lol

I don't have time to dig deeper either, but it does bother me that they're messing with something they shouldn't be for such a minute amount of gain which can be easily avoided. Why should MS' domains be special? A forged update from Adobe or Java could be just as damaging and those pop up more frequently so they'd be less obvious.

Something else to consider is that not all applications use DNS names. I have quite a few that use ip addresses directly . Kind of a bad thing because if the ip changes the program may have problems, but I guess some companies figure they have an assigned address for the next 100 years and don't expect it to change.

But in order to fake out AU or something else written by MS you would need to use DNS names. But yes, way too many internal things rely on IPs that should be considered transient. Network and voice guys are the worst offenders IME because they don't want to rely on someone else's infrastructure and possibly add latency by using DNS in their systems. And since they're looking at those IPs every day they don't have any problems remembering them.

 

[VirtualLarry]

I'm having issues now where the forum pages will sit there with the spinning "loading" icon on the tabs, and it shows "pixel.quantserve.com" as the domain. Which is in my HOSTS file.

Why would my browser hang on loading, on that domain, if it's mapped to 127.0.0.1?

 

[ViRGE]

I'm having issues now where the forum pages will sit there with the spinning "loading" icon on the tabs, and it shows "pixel.quantserve.com" as the domain. Which is in my HOSTS file.

Why would my browser hang on loading, on that domain, if it's mapped to 127.0.0.1?

It's timing out waiting for a response. No response is not the same as a "no" response.

 

[Emulex]

a firewall in stealth mode would cause a delayed hang.
no firewall would cause a fast page not found.
running xampp(apache)/IIS on port 80 would try to load a page from your own machine