The Security Skeptic

ICANN's SSAC is conducting a survey of DNS implementations as part of an extensive assessment of the global state of "DNSSEC readiness". The email-based survey asks commercial, open source, proprietary name server software implementations, and hardware DNS appliance vendors to state whether they support DNSSEC or plan to implement any time soon. If DNSSEC is currently supported, additional questions inquire about feature support, interoperability testing, and the availability of administrative tools.

We identified and contacted over 40 name server companies and development project leaders. Our response rate from companies with commercial products and services was very good. The responses for 15 products can be summarized as follows:

• 60% (9 of 15) products support the core DNSSEC standards (RFC 4033-4035) today and two more indicate support is forthcoming this year.

• Three (3) products support NSEC3 (RFC 5155, DNS Security (DNSSEC) Hashed Authenticated Denial of Existence) today. Four (4) anticipate support by Q4 2008 and 3 others intend to implement but did not identify a timeframe.

• Eight product developers reported that they had done interoperability testing (the ninth "inherits" interoperability testing because the company provides a version of its DNS management software that can be run with ISC's BIND, which supports DNSSEC).

• All nine products offer some key management applications and DNSSEC-aware utilities.

These results are very promising. In an industry segment that some would describe as "Where BIND goes, others follow...", many of the players other than BIND have implemented DNSSEC, including InfoWeapons, INS, Nixu, NL NetLabs (NSD and Unbound), Nominum and Secure64. Microsoft and Infoblox acknowledged receipt of the survey but declined to answer.

Our response rate from open source projects was relatively low; in fact, it was negligible. If you are familiar with any Open Source projects that support DNSSEC and can provide a contact to that project, please let me know.

Archived at http://www.securityskeptic.com/arc20080601.htm#BlogID696 by Dave Piscitello  

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  

The APWG has published its Global Phishing Survey: Domain Name Use and Trends in 2007. This report examines many phishing trends. The most interesting may well be the distribution of domains used by phishers according to generic and country code top level domain and the most worrisome may be the increased use of subdomain providers for phishing.

One reason why the APWG phishing survey is interesting is that it arrives at very different conclusions from McAfee's second annual "Map the Malweb" study. McAffee's lists (in order) Hong Kong, the People's Republic of China, Phillipines, Romania and Russia as the "most dangerous domains to surf and search on the web" and (in order) Finland, Japan, Norway, Slovenia, and Colombia as the safest.

Sidebar: I have a hard time wrapping my head around any phrase that includes "Colombia" and "safest" in the context of criminal activites, don't you? My immediate reaction was to Google "Colombia safest". Not surprisingly, I learned that Colombia's murder rate in 2003-2004 was nine times that of the U.S. and that Colombia is the ransom kidnapping capital of the world. Factor in drug trafficking and it's pretty clear few miscreants in that country have the time or patience to do e-crimes.

APWG's study uses an interesting metric - Phishing Domains per 10,000 - to assess whether one TLD has a higher or lower incidence of phishing relative to other TLDs. Applying this metric, APWG's top five are Hong Kong, Thailand, Liechtenstein, Romania and Chile. Among the safest TLDs you'll find European Union, United Kingdom, Germany, Argentina and Sweden.

The most curious result? McAfee ranks the INFO as the most risky generic TLD whereas APWG's metric ranks them as the safest.

Different metrics, data, measurement periods appear to contribute to the disparities in results. However, APWG casts a narrower net, including only domains that were proven to be associated with a phishing incident. McAfee's study web sites that contained adware, spyware, viruses, spam, excessive pop-ups, browser exploits or links to other risky sites in its "dangerous domains". Neither offer a glowing report, but no one I know would believe one if it were published :-O

Archived at http://www.securityskeptic.com/arc20080601.htm#BlogID694 by Dave Piscitello  

Colleague and friend Scott Pinzon read my recent post regarding the Comcast domain hijacking (see BlogID# 692) and invited me to chat with him at Radio Free Security. We spend some time discussing and putting into context the various news and blog reports regarding this hijacking incident but spend more time considering how organizations can learn from Comcast's experience and improve how they manage their domain name portfolios. Many of the take away messages come directly from my blog piece, but I encourage you to listen to the podcast for both the additional insights and the sheer entertainment value as well.

.

Archived at http://www.securityskeptic.com/arc20080601.htm#BlogID693 by Dave Piscitello