Comcast the Latest ISP To Try DNS Hijacking 352
Posted
by
timothy
from the c'mon-fellas dept.
from the c'mon-fellas dept.
A semi-anonymous reader writes "In the latest blow to DNS neutrality, Comcast is starting to redirect users to an ad-laden holding page when they try to connect to nonexistent domains. I have just received an email from them to that effect, tried it, and lo and behold, indeed there is the ugly DNS hijack page. The good news is that the opt-out is a more sensible registration based on cable modem MAC, rather than the deplorable 'cookie method' we just saw from Bell Canada. All you Comcast customers and friends of Comcast customers who want to get out of this, go here to opt out. Is there anything that can be done to stop (and reverse) this DNS breakage trend that the ISPs seem to be latching onto lately? Maybe the latest net neutrality bill will help." Update: 08/05 20:03 GMT by T : Here's a page from Comcast with (scant) details on the web-jacking program, which says that yesterday marked the national rollout.
Treewalk or OpenDNS (Score:1, Informative)
Re:Serious question (Score:5, Informative)
You're IT for a business. You have employees who check their e-mail from home, accessing your stuff via a split tunnel VPN.
The computer tries to resolve internalmail.company.com, and normally this should fail, causing the computer to try the VPN's DNS server.
Instead, your employee's computer gets Comcast's search page server. Their mail client times out.
You get inundated with tech support calls.
Re:Serious question (Score:2, Informative)
All sorts of stuff. There's many systems that assume a certain behavior - that when a domain doesn't exist, you get an NXDOMAIN response rather than some other record.
For example, many VPN setups use this to decide which interface to chuck data down. When you try to access 'google.com' that gets a resopnse on the first try, so do that on the public side. When you try 'machine.company' that fails, so go try internal DNS and do it on the internal side.
I'm sure others can come up with more examples.
Re:Serious question (Score:3, Informative)
It's not being redirected to some search page that's the major problem. DNS is a lower-level function that the Web. Really what it's doing is replacing DNS responses indicating that a host or domain doesn't exist with a DNS response indicating that the host/domain is located at X IP address (the address of the search page). It doesn't know when it sends this response what the response will be used for. If it's for the web, you get the search page. Non-web applications will instead behave incorrectly or, at least, produce an incorrect error message.
Re:Serious question (Score:3, Informative)
Now, say your im program is set to try several different dns addresses to connect. If one has been decommissioned (but the client not updated) and your IM will try to connect, possibly passing the username and password to the server that is returned by dns for "login2.whatever.com".
Even with the web, say you have a login for a store/bank/whatever, but the latest version of there page some web developer made a typo and instead of "placeyouwanttogo.com they put "placeyouwantogo.com" (notice the number of t's). Instead of giving you a "site not found" message, you've been redirected to an ISP page that gets all of the information you were trying to pass.
Now in my example, it's possible they could push you to a typo domain as well, but the point is dns is supposed to return "Hey this doesn't exist" to your client, which then should display an error message, determined by the application doing the dns request. If it's not http, it will look like you're trying to connect to a host and it will either be A) "Connection refused" B) Answer and confuse whatever application you are running or C) appear like a black hole and never connect.
fucking idiots.....at least I have BIND (Score:5, Informative)
I've always used a linux box as my firewall /router box at home, and I've been running BIND as a caching DNS server. Fortunately this won't affect me, as I totally bypass spamcast's bullshit.
Re:Treewalk or OpenDNS (Score:2, Informative)
Re:Serious question (Score:5, Informative)
My ISP does this. They also have an 'opt-out' option, but you know what that does? It still doesn't send an NXDOMAIN response like it should. Instead it redirects me to a site that is serving the standard windows site-not-found page. A horrifying experience for this mac/linux user.
So I set up my own DNS server, which fixed the problem and sped up my internet connection since the ISP's DNS server was really slow.
Re:Treewalk or OpenDNS (Score:3, Informative)
They do the same thing.... unless you register an account. Why do people always leave that part out?
Re:Serious question (Score:5, Informative)
It's a split tunnel VPN...
That means first it tries to use the internet, then it tries the VPN. If I lookup foo.bar, and foo.bar doesn't resolve, it then tries on the VPN's DNS. That helps keep external traffic off the VPN. Internal traffic is still safe.
Of course, if foo.bar instead of not resolving--points to comcast--then I never do the lookup...and the VPN ...is broken.
Re:Serious question (Score:5, Informative)
The name of the box is, of course, irrelevant. But you still have it wrong: Comcast's DNS server isn't affecting the company's internal DNS server, it is affecting their customer's box, who is your employee, making it so that they never query your internal DNS server.
This happens precisely because they don't know anything about the internal network, and yet they are telling your employee they do.
Re:Serious question (Score:5, Informative)
I fail to see, using your scenario, why Comcast's DNS server would effect the company's internal DNS server, thus creating the conflict you alluded to. Since I'm not sure why Comcast would know anything about the company's internal network...
That's because you didn't pay attention to the scenario. We're talking about a split tunnel VPN. DNS resolution uses the following rules:
1) try the usual (external) DNS server first. If it resolves, use that IP address for the communication.
2) try the internal DNS (via the VPN) if step 1 returned NXDOMAIN, and if that resolves, use that IP address for the communication.
3) otherwise, return NXDOMAIN.
So if Comcast's external server returns a valid IP for the internal server, instead of NXDOMAIN, then your internal mail server will never be accessible to anyone using your company's VPN from a Comcast connection.
Re:I noticed this yesterday (Score:1, Informative)
Likely the opt out is based on resetting the modem, which they don't like to do unless they have too. push a different profile to it is my guess.
comcast sponsors standards work on this topic (Score:4, Informative)
http://tools.ietf.org/html/draft-livingood-dns-redirect-00
note where author works.
Re:Serious question (Score:2, Informative)
OK, here's an example:
vpn client>> resolve internal.company.com
correct DNS server<< NXDOMAIN
vpn client routes VPN connection>> resolve internal.company.com
company's DNS service<< 10.1.99.12
result: VPN client knows to use the VPN connection for this route.
vpn client>> resolve internal.company.com
ass-backwards DNS server<< address of trojan-ridden.adserve.com
result: VPN client didn't receive NXDOMAIN, so it won't use the VPN tunnel for this route.
result 2: any connections attempted to this server will timeout, or (worse) will result in your company's documents scattered to a random server on the Internet
result 3: corporate helpdesk gets blamed
result 4: liability lawsuits
your example about webmail.company.com is exactly the wrong way around; you aren't trying to access a public service offered by company.com, you are trying to access an internal server. Asking this to any public, standards-conforming dns server, should result in a respone that says I don't know. Anything else will break the Internet.
Your point is correct, your example is flawed. (Score:3, Informative)
Your example fails because internalmail.company.com will resolve through company.com, not dnsshill.comcast.com. That is "company.com" is authoritative for "internalmail.company.com" in the hierarchical name service system. The questions of what happens in this case is questionable. Especially since in your split tunnel you probably have prepended company.com's internal DNS resolvers in the name search space so that the VPN user sees the internal sites in preference to the external ones.
Your point is correct, your example is flawed.
IMHO, of course 8-)
Re:Opt-out page down already? (Score:3, Informative)
I guessing that when you opt-out, you give them your MAC so that they can assign you to a different IP address pool. Then they just decide if you get hijacked or not based on the source IP address.
Intentional and Malicious Obfuscation (Score:2, Informative)
Optimum Online in NY also started recently (Score:3, Informative)
They've got about 3 million subscribers in the NY metro area (CT, NJ and NY excluding Manhattan). They just started doing this a couple of months ago. I noticed it when my DNS queries started failing completely. Seems I had changed my DNS servers to ones not owned by Optimum (aka Cablevision) because of speed issues, and with their most recent change they're also blocking DNS queries directed to servers other than their own.
Don't look for the latest net neutrality bill to fix this. All that is is the ISPs making the bag of bribes bigger until the greed of Congress can no longer resist.
Re:Serious question (Score:2, Informative)
You did notice that the page at http://networkmanagement.comcast.net/DomainHelperLogic.htm says it must be preceded by "www." right? That would seem to invalidate your example...
Re:Treewalk or OpenDNS (Score:5, Informative)
HOLY FUCKING SHIT
STOP SUGGESTING OPENDNS, THEY DO THIS SHIT TOO.
Excuse my while I go blow a bloodvessel. Every single time a story like this comes up some idiot suggests OpenDNS and idiot mods initially mod them up.
I'd link where this happened last time but for the life of me I can't figure out how to view more than my several dozen posts.
Re:Serious question (Score:3, Informative)
Arguably this is less of a problem for an organisation like yours that [ostensibly] has some sort of deployment mechanism. You can probably easily configure your employees' laptops to use RFC-compliant DNS servers, whether yours or "public" ones.
That certainly doesn't make it any less evil on Comcast's part, though.
Comcast's version is orders of magitude better... (Score:5, Informative)
Comcast's version is an order of magnitude better than everybody else's.
a: There is a REAL opt-out, that puts your DHCP lease to point to a DNS resolver that doesn't do this. I'll have to do this when I get home. Compare this with, eg, Verizon's pitiful opt-out instructions involving manually changing DNS settings [verizon.net].
b: IF you had manually set your DNS resolver to a Comcast server, you are unaffected (they added new resolver addresses to do this), per previous discussions by the Comcast folks over at Broadband Reports.
c: It does NOT get *.whatever, only www.*.(TLD), thus even when you don't opt out, it is at least limited to web-related typos. This is actually a big deal, as I think Comcast is the first one NOT to do it for everything.
I don't like NXDOMAIN wildcarding (it was one of the motivations behind building the ICSI Netalyzr), but if an ISP is going to do it, Comcast's is actually well constructed to both limit collateral damage (it only gets www.*) and be able to be bypassed with a real opt-out.
Re:It still takes 2 days to opt-out. (Score:4, Informative)
The latency comes from two factors.
The biggest is because Comcast gives very long DHCP leases, and the change doesn't propagate to your system until your access device gets a new DHCP lease.
The second is they probably batch updates to the DHCP server to say who's opted-out.
If you want to have it go faster, after going to the opt-out site, reset your cable modem and your NAT box and it will probably take effect right away. If that doesn't work, wait an hour and try again.
Re:The flip side of net neutrality (Score:4, Informative)
No new legislation is needed. Just get the courts involved.
Exactly. This act is already illegal. It is called typo-squatting.
http://thomas.loc.gov/cgi-bin/query/z?c106:S.1255.IS:= [loc.gov]
Specifically, see section 3, (2)(a), and probably (2)(b) as well.
Now we just need as many people as we can get, whom have a domain name which is trademarked, to press charges against comcast under this law for your own domain.
`(i) an award of statutory damages in the amount of--
`(I) not less than $1,000 or more than $100,000 per trademark per identifier, as the court considers just; or
`(II) if the court finds that the registration or use of the registered trademark as an identifier was willful, not less than $3,000 or more than $300,000 per trademark per identifier, as the court considers just; and
`(ii) full costs and reasonable attorney's fees.
Chances are since the main purpose of this change is for ad revenue, and not a willful infringement, only line (I) will apply.
Additionally, you probably can't get the 'bad faith' additions applied, unless you can somehow prove the ads served on their 'page not found' fake-page happen to be ads for your competition.
But a minimum of $1000 plus attorney fee's is pretty decent if you have nothing better to do...
Re:Method? (Score:3, Informative)
Re:Repeat? (Score:3, Informative)
Re:Err just which of the cablemodem MACs do they w (Score:3, Informative)
I just looked at my cablemodem and it has 4 MAC addresses associated with it:
HFC MAC Address
Ethernet MAC Address (probably not?!)
CM USB MAC Address
CPE USB MAC Address
I suspect that it is the first?
No sense entering it until I know if it makes a difference or just allows the scam to go on.
Thanks!
HFC is the one associated in DOCSIS, so 99% sure it's that one. And you're welcome.
Re:Opt-out page down already? (Score:3, Informative)
They know which MAC address currently has the lease for which IP address, and they know which customer owns which MAC address. They also know which IP addresses belong to them, so they can separate "people opting out from home" from "people trying to opt out from work".
Therefore, it could (in theory) be automated.
Re:Serious question (Score:2, Informative)
Re:Serious question (Score:3, Informative)
I believe that Firefox (and your browser may do this as well) tries www.domainname.com if domainname.com doesn't exist.
This would explain why the invaliddomain135.net redirected to that page.
Re:Serious question (Score:4, Informative)
A hard-coded IP address in the hosts file is often a bad idea. A simple example: when I'm on-site, company.com resolves to the internal (10.x.x.x) address, but when I'm off-site, company.com resolves to the public address. When employees are on-site, you want traffic to stay on the network, and using the external IP could cause your internal traffic to be routed out of your network and right back in.
Re:Serious question (Score:4, Informative)
Any reasonable split tunnel VPN program does exactly the opposite - prioritises the VPN DNS settings over the internet.
Not saying the setup Comcast has is good, just saying.
Re:Serious question (Score:3, Informative)
According to comcast's own pages, their "service" only applies to www.INVALID.tld, and possibly in the future www.INVALID.tdl and www.INVALID - meaning that in all cases it requires www. at the start, only accepts valid tlds at the end at present, and may also intercept invalid or blank tlds at some point in the future.
To be honest, given that they're doing it anyway, they seem to have chosen a fairly inobtrusive way of doing it.
Re:Comcast's version is orders of magitude better. (Score:4, Informative)
Yes, but it's poor practice to advertise anything but a webserver through a www.* IP name. If the host is doing something else, it should have another IP name for people accessing that function. Among other things, it makes it much easier to move that function off that machine without touching the webserver. www.* could affect things other than webservers, but it shouldn't, and mostly, it won't. That doesn't make what Comcast is doing *right*, but it does make it slightly less horribly awful. Slightly.
dnsmasq bogus-nxdomain fix (Score:2, Informative)
Dnsmasq has an option to "fix" this kind of dns redirection called bogus-nxdomain. The bogus ip address to block is 208.68.139.38. I wonder if comcast uses multiple addresses or will ever change it...
Maybe I'll just switch to using 4.2.2.[1-6] as many other people have mentioned.
Re:Very Simple Answer (Score:2, Informative)
Re:Very Simple Answer (Score:4, Informative)
The page you get from Comcast (or whoever) is the same as getting the busy signal/number not found.
A busy signal doesn't try to sell you ads, so it makes sense. Also, we already have something that is the same as a busy signal -- it's called NXDOMAIN.
They're also irrelevant for mail delivery, as last time I checked, mail wasn't sent via HTTP.
Which is one of the main points here -- if it's HTTP, especially if it's HTML over HTTP to a web browser, then getting Comcast's page probably wouldn't bother you any more than getting Firefox's "not found" page. It might use slightly more bandwidth, but it wouldn't really be an issue.
The problem comes when you start doing things like mail delivery, or any number of other applications, which expect nonexistent domains to be, well, nonexistent. Many of them will never fire an HTTP request, and so could not even theoretically figure out WTF is going on -- they get a "connection refused", at best, and maybe they have to wait for a timeout, instead of an immediate domain-not-found error.
It's especially harmful for various applications which depend on actual domain-not-found results, such as various VPN setups. This is more or less exactly like the analogy given -- the payphone giving you your dime back depends on getting an actual, real busy signal and/or "not in service" result. Anything else, and it assumes you were successful, and does the wrong thing -- in this case, it eats your dime.
DNS is for IP Layer, not Browser Layer (Score:3, Informative)
The misappropriation is technically bad because it's done at the wrong protocol layer, and even when it works it's bad because it'll cause your browser to do something you didn't want.
Here's how DNS is supposed to work when it works, and how it's supposed to work when the lookup fails.
Now look at what happens if your DNS server lies to your application by giving it some other IP address instead of the correct failure message, like 68.87.60.144.
Re:Comcast's version is orders of magitude better. (Score:3, Informative)
Here are my tests:
www.blahblahblahblahblah.com
Bogus redirect page.
www.blahblahblahblahblah
NX
blahblahblahblahblah.com
NX
www.blahblahblahblahblah.ner
NX
Eventually all failed non-existant domains that are queried through Comcast's servers, where the query begins with www., will get redirected. They just haven't phased that in, yet: DomainHelperLogic [comcast.net]:
We will eventually phase in the following pattern matches to enhance this service in the future:
(1) www.SOME-INVALID-NAME.cmm or
(2) www.SOME-INVALID-NAME
- The entry must include "www" followed by a dot ("www.")
...
Re:Serious question (Score:5, Informative)
We're talking about the DNS search, not actual routing. First you check the internet and then you search the VPN DNS. This is so that if $work is doing the same type of redirection (which is fine - it's their resources that they're serving, so if they don't want you going to playboy.com, that's their business) you can still reach the external network without using $work's resources. There's no reason why your employer's computer-use policies should interact with your home use, even when connected to the office over VPN.
This requires that your DNS is resolved via the internet before VPN. And requires that the internet DNS behaves properly.
Re:Very Simple Answer (Score:3, Informative)
My email example never mentioned, nor does it pivot on, HTTP.
Comcast doesn't "send you an http page" they send you a FALSE ADDRESS RESOLUTION RECORD where your browser then goes to retrieve the bogus page via HTTP. See how the DNS protocol is completely different than the HTTP protocol?
SPAM Filters check to make sure that senders exist (among other things), one of the ways they do this is to look up the domain name to make sure that the sender domain ACTUALLY EXISTS as a first tier check. This is why you don't see successful spam from arbitrarily complex senders any more. That is, while the subject lines will extol you to enlarge your penis, the emails are no longer from "great_deals@my.giant.penis.com" any more (unless someone actually registers at least the top level domain.
It's not the only filter of course, but it is near the top of the list because it does a heck of a lot of heavy lifting quite cheaply.
And as another element you clearly missed. Here you are confusing HTTP and DNS and you are at least well educated enough to know that HTTP is what runs the web. Yet your education fails you when you don't _get_ that this is a poisoning of DNS not "the web" simply because that poison is designed to primarily dupe web users. Your response is a one-person proof of why this is so dangerous. The total number of people using protocols they don't fully understand is legion. When anybody starts mucking around with the underlying assumptions that make the "the web" and indeed the entire internet work, they are trampling barefoot through a sea of broken glass and dragging us all behind them through the unintended consequences.
When those who know how all this stuff works tell you that you are breaking something, perhaps you should at least study the declaration before airing dissent.
(not to be all grumpy 8-)