The dark side of name DNS error resolution
Internet services typically have a standard way to signal errors. The DNS protocol uses the Response code field to signal and describe problems it encounters when attempting to respond to a query from a client (resolver). An authoritative name server will return a Name Error, also known as an NXDomain response (for non-existent domain) to indicate that the domain name in the query does not exist. In SSAC's latest report, DNS Response Modification, we explain how an entrusted operator or any J.Random.ISP are modifying DNS response messages intended to signal name errors for profit and how attackers are exploiting these "error resolution services" for their own *fun* and profit.
This (ahem) interesting practice is implemented today; in fact, several companies make a living operating error resolution services for other service providers and registrars. There are two variants. The first involves what we call an entrusted agent: your ISP, registrar, or a company you pay to host your DNS. Commonly you hand your domain's zone file over to such folks and they host it on their name servers. Here's what may happen if the agent you or I choose engages in error resolution, and it may happen without your knowledge and consent.
I'll use securityskeptic.com as the domain for this example. I give my zone to a DNS operator to host. The agent's name server receives a DNS query for a name that I didn't include in my securityskeptic.com zone; e.g., a mistype like ww.securityskeptic.com. I expect that this name server would return a non-existent domain response to this query; hopefully, you'd expect this, too. Ah, but suppose I didn't do my homework and discover - to my dismay! - that the DNS operator I chose resolves DNS errors to enhance the user experience. Huh? What's that mean? Well, before hosting my zone file, this DNS operator has inserted a wildcard record in my zone that says "use this IP address for any name that does not appear in securityskeptic.com's zone file". What's at that IP address? Well, on Port 80/HTTP, you will likely find promotional marketing, paid advertising or a search engine.
Not happy with that scenario? Sorry, there's more. If I learn about this practice, I can demand to opt out of this practice or move my DNS to a provider that doesn't resolve errors in this manner. Problem solved, right? Well, not exactly. Few DNS queries are resolved by asking the authoritative name server for a zone; instead, most are resolved through an iterative process by DNS servers called resolvers. And it turns out that any iterative resolver that's situated between my name server and the user who typed ww.securityskeptic.com can intercept the NXDomain response my name server returns, silently alter my response message, and redirect the client to an IP address of his choice. What's at that IP address? Promotional marketing, paid advertising or a search engine.
It gets worse. It turns out that security wonks like Dan Kaminsky have studied error resolution, visited the web servers where non-existent domains are hosted, and figured out ways to inject scripts into vulnerable input forms on those hosts. Oh no, Mr. Bill! Can you see a phishing attack in your future, on a host you don't control? [Note: Dan's presentation on what he calls provider redirection was a catalyst for the SSAC work. Excellent work, Dan, and thank you.]
Another interesting question to toss into this still unfolding story is, "what's listening on ports other than HTTP/80 on these machines?". No one can say for certain since no one's studied all the redirect hosts. But imagine an error resolution for an incorrectly typed VOIP address/SIP number. Now imagine that an attacker redirects you to an offshore toll number. Fun in the sun...
SSAC's report is a preliminary one. There's much more to study here. Pull on your all weather gear, folks, this issue will undoubtedly cause quite a storm.
Archived at http://www.securityskeptic.com/arc20080601.htm#BlogID695
by Dave Piscitello
