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  

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  

Comcast had its NET domain name hijacked Wednesday May 28^th. Attackers got their hands on the account credentials for Comcast's domain name management account at Network Solutions and altered DNS entries so that Comcast users landed on a defacement page when they attempted to use web mail and other Comcast services. According to a Network World News report, Network Solutions restored name service around 12:30 a.m., about 90-120 minutes of service interruption to Comcast customers.

This incident is remarkably coincident with ICANN SSAC's publication of a security advisory describing Registrar Impersonation in Phishing Attacks, causing some reporters and readers to immediately link the event with a phishing attack. Network Solutions and Comcast haven't completed their forensic analyses and haven't disclosed know how the attackers obtained Comcast's account credentials. Initially, some news reports speculate that the attackers used a brute-force password guessing attack while others suggest social engineering (which does include phishing). Two attackers now claim to have used a combination of social engineering and an exploit of Network Solutions' domain registration portal to take control of 200+ domain names in Comcast's portfolio, and the pair claim to have warned Comcast of their intent.

Only one security expert I know has called attention to the "data breach" potential of this attack; for example, if the attackers altered or added Mail eXchange records, they could have captured Comcast subscribers' emails. This particular incident appears to have been a malicious and retaliatory prank but if it had been perpetrated by a more motivated attacker, it could have been far worse. What will it take to convince companies that domain names are assets and lax management of these assets is a very large security risk?

Rather than speculate further, I would encourage any individual or organization who has registered a domain name(s) to contact the company you use to register and manage your domain name portfolio. Learn from Comcast's incident. Ask tough questions regarding authentication and registration information security. I'd ask:

• Do you monitor and record failed login attempts to prevent brute force attacks against domain name accounts?
• Do you take measures to assure that your customers use passwords that are difficult to guess?
• Do you enforce {minimum length, complexity criteria, maximum lifetime, re-use,...} policies on passwords customers create?
• Describe your incident response procedure in the event that an account is compromised?
• Do you offer a (premium) service that provides monitoring of registration information changes and actively monitors DNS changes?

Hmmm... that list suggests a rather interesting study to conduct.

Archived at http://www.securityskeptic.com/arc20080501.htm#BlogID692 by Dave Piscitello  

In an earlier blog, I described a form of phishing where the attacker impersonates a registrar, with the goal of gaining access to a domain name management account.

On behalf of ICANN's SSAC and with the assistance of colleagues at the APWG, I've written an Advisory on Registrar Impersonation Phishing Attacks.

Registrar impersonation targets domain name registrants. The phisher impersonates a domain name registrar and sends an expected or anticipated correspondence to a registrar’s customer regarding a domain name related matter. Like many e-businesses, domain registrars use email correspondence to remind customers when it's time to renew a registration, verify the accuracy of your registration (WHOIS) information, etc. The email lures the recipient to an impersonated registrar web site and in particular to a login page for the registrar's customers. The customer logs in and unwittingly discloses his account credentials. The phisher then uses the domain names in this customer's portfolio for other attacks.

In this Advisory, SSAC describes generic forms of this type of attack. We consider types and formats of information included in legitimate email messages that various registrars use when corresponding with customers. We discuss some of the current recommended practices to minimize or prevent phishing attacks employed by common phishing targets such as financial institutions and large corporations. Most importantly, we recommend measures that registrars can take to make their correspondences with registrants less "phishable” and identify ways for registrants to detect and avoid falling victim to this form of phishing.

Archived at http://www.securityskeptic.com/arc20080501.htm#BlogID691 by Dave Piscitello  

While reading a report on phishing, I came across the statement, "On March 2007, the .CN (China) registry operator, CNNIC, significantly reduced the annual cost of .CN domain name registrations to one yuan ($0.13 US). This price helped the .CN grow explosively, from 1.87 million domains in February 2007 to 9 million in December 2007."

The cost to register a domain is commonly quite different from the asset or speculative value of that registration. Visit certain registrars and you will not only find domains that can be registered for under $10 US but *opportunities* to have already registered domain names transferred to you for a fee? What kind of fees?

• You can pay $15-20 for a common mistype or variant of the name you submitted in an availability check.
• You can enter into an auction or search name for sale databases for names that contain a keywords you desire. For example, enter the word "scam" at DomainTools. You'll get a list of domain names containing that word and you can acquire these for as little as $5 US (westnilevirus.com), for $1750 US (scamfreeinternet.com) or even $10,000 (emailscammers.com).
• So called premium names are also available"for distribution using non-traditional allocation models" (search for this phrase and be amused, be very amused).

I find it fascinating that something that is not legally "property", that could cost as little as $.13, and that hasn't been buried for a thousand years could be so classified, don't you?

Asking how much a domain registration is worth is a lot like asking how much the human body is worth. Based on chemical and mineral composition, the average adult body is worth around $4.50 US¹. However, put a living body in the hands of a speculative market in a futuristic society gone wild, and you could sell DNA from that one body for $9.7M US, bone marrow at $23,000 US per gram, or two lungs at $116, 400 US per².

Free market economies. Love 'em and fear 'em.

Archived at http://www.securityskeptic.com/arc20080501.htm#BlogID688 by Dave Piscitello  

Dark Reading's Kelly Jackson Higgins wrote an interesting article following the announcements that three top level domains - arpa, org, and uk - will soon adopt DNSSEC. Kelly interviews me and several colleagues to gauge the significance of these announcements. Find the article here.

Archived at http://www.securityskeptic.com/arc20080401.htm#BlogID686 by Dave Piscitello  

Product life cycle management can be loosely defined as all the activities a vendor engages in to launch, develop, market, mature (or evolve) a product. Some products reach a point at which they can no longer adapt or evolve, and hence vendors end the life of a product. A noteworthy, recent EOL example in the security market is the Cisco PIX.

Users, especially enterprise administrators, contend with product life cycle management in a very meaningful way. They monitor a product's evolution and in many cases, they press vendors to add (or kill) features, improve performance and security, etc. They must stay informed so that they are not caught unprepared should a vendor choose to EOL a product; for example, if an admin ran a Cisco PIX only shop, he ought to have kept informed regarding the future of this firewall and ought to have considered what he would employ "post PIX".

Today, users have a longer life cycle to manage than vendors, one that includes hype cycle management. The hype cycle begins before a product announcement. Hype that sparks the cycle takes many forms: new standards and regulations, demonstrations of prototypes at trade shows, trade pub and street talk. Soon, *THIS NEW THING* is widely heralded as the most disruptive technology since, well, the last most disruptive technology.

Consider this tale of two C*Os and their experiences with the iPhone. The first C*O shows up at a senior management retreat with an iPhone, announcing that "this is so freaking cool". This begets a must-have attitude that trickles down from management, which begets an organization-wide buying frenzy, which begets a business imperative directed at IT to "integrate iPhones with our enterprise mail system and corporate web apps". To accommodate iPhone adoption, a planned 802.1x/network access controls project is dropped from the budget. There's always next year.

This C*O failed to manage the hype cycle and allowed enthusiasm for a consumer grade product to snowball into a mobility issue that resulted in an unplanned network deployment, funded at the expense of an important security initiative.

I know a second COO whose response to exactly this situation serves as a five-star example of hype cycle management. When iPhone was announced, this COO sent an "all hands" email with the subject line "iPhone". He acknowledged the awesome coolness of iPhone and that he desperately wanted one. However, he tempered his enthusiasm when he realized that interoperability issues would prevent him from accessing intranet services that were essential and that an important network and security upgrade would have to be sacrificed to accommodate iPhone adoption. He asked all hands to temper their enthusiasm, be patient while IT investigated iPhone integration, and promised that the organization would do its best to accommodate new mobile technologies. This COO jumped in front of the bus as it was departing and yelled "stop!" but in doing so, he acknowledged the desirability of the new technology rather than dismissing it. He explained why iPhone adoption was problematic, reminding rather than rebuffing staff that the mission and business of the organization takes priority over having a cool handheld. Lastly, he empowered IT by announcing that iPhone adoption would be studied.

If you study these scenarios carefully, I'm pretty certain you can tease out a set of "best practices" for hype cycle management.

Archived at http://www.securityskeptic.com/arc20080301.htm#BlogID678 by Dave Piscitello  

Senior editor Kelly Jackson Higgins interviews me, Rod Rasmussen (Internet Identity) and Joe Nazario (Arbor Networks) on the potential impact ICANN SSAC's Advisory, Fast Flux Hosting and DNS, could have in shaping future countermeasures to fast flux attacks (see Battle Against Fast-Flux Botnets Intensifies). It's a quick and IMO interesting piece that may encourage readers to consider reading the Advisory itself.

Archived at http://www.securityskeptic.com/arc20080301.htm#BlogID675 by Dave Piscitello  

In BlogID 671, I mention that a simple NS query on any root name server will confirm that IANA has included IPv6 addresses of 6 authoritative root name servers in the hints and root zone files. The simple "dig" example I gave will only return as many complete resource records as the root name server can fit into an RFC 1035 compliant, UDP-encapsulated DNS response. If you want to see all the resource records for all the root name servers, you must tell dig to advertise a larger receive buffer size by signaling Extended DNS (EDNS0) support, as follows:

 c:\dig +bufsize=1024  @a.root-servers.net NS
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41
;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 20
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;.				IN	NS
;; ANSWER SECTION:
.			518400	IN	NS	M.ROOT-SERVERS.NET.
.			518400	IN	NS	A.ROOT-SERVERS.NET.
.			518400	IN	NS	B.ROOT-SERVERS.NET.
.			518400	IN	NS	C.ROOT-SERVERS.NET.
.			518400	IN	NS	D.ROOT-SERVERS.NET.
.			518400	IN	NS	E.ROOT-SERVERS.NET.
.			518400	IN	NS	F.ROOT-SERVERS.NET.
.			518400	IN	NS	G.ROOT-SERVERS.NET.
.			518400	IN	NS	H.ROOT-SERVERS.NET.
.			518400	IN	NS	I.ROOT-SERVERS.NET.
.			518400	IN	NS	J.ROOT-SERVERS.NET.
.			518400	IN	NS	K.ROOT-SERVERS.NET.
.			518400	IN	NS	L.ROOT-SERVERS.NET.
;; ADDITIONAL SECTION:
A.ROOT-SERVERS.NET.	3600000	IN	A	198.41.0.4
A.ROOT-SERVERS.NET.	3600000	IN	AAAA	2001:503:ba3e::2:30
B.ROOT-SERVERS.NET.	3600000	IN	A	192.228.79.201
C.ROOT-SERVERS.NET.	3600000	IN	A	192.33.4.12
D.ROOT-SERVERS.NET.	3600000	IN	A	128.8.10.90
E.ROOT-SERVERS.NET.	3600000	IN	A	192.203.230.10
F.ROOT-SERVERS.NET.	3600000	IN	A	192.5.5.241
F.ROOT-SERVERS.NET.	3600000	IN	AAAA	2001:500:2f::f
G.ROOT-SERVERS.NET.	3600000	IN	A	192.112.36.4
H.ROOT-SERVERS.NET.	3600000	IN	A	128.63.2.53
H.ROOT-SERVERS.NET.	3600000	IN	AAAA	2001:500:1::803f:235
I.ROOT-SERVERS.NET.	3600000	IN	A	192.36.148.17
J.ROOT-SERVERS.NET.	3600000	IN	A	192.58.128.30
J.ROOT-SERVERS.NET.	3600000	IN	AAAA	2001:503:c27::2:30
K.ROOT-SERVERS.NET.	3600000	IN	A	193.0.14.129
K.ROOT-SERVERS.NET.	3600000	IN	AAAA	2001:7fd::1
L.ROOT-SERVERS.NET.	3600000	IN	A	199.7.83.42
M.ROOT-SERVERS.NET.	3600000	IN	A	202.12.27.33
M.ROOT-SERVERS.NET.	3600000	IN	AAAA	2001:dc3::35
;; Query time: 78 msec
;; SERVER: 198.41.0.4#53(a.root-servers.net)
;; WHEN: Mon Feb 11 14:57:13 2008
;; MSG SIZE  rcvd: 615

If you don't specify EDNS0, not only will your answer be abbreviated, but it will differ depending on the root name server you query. Root name server operators use several software implementations, each has a preferred configuration, and these variations result in NS response messages being composed slightly differently. No worries, however: you will *always* get at least two AAAA resource records in an NS response.

If you want to see the differences, simply dig DNS to a.root-servers.net and b.root-servers.net - or dig them all!

Archived at http://www.securityskeptic.com/arc20080201.htm#BlogID673 by Dave Piscitello  

IANA has implemented the recommendations of ICANN's Security and Stability Advisory Committee (SAC 018) by adding AAAA records for six the thirteen listed authorities for the root zone.

An updated hints file is available from ftp://ftp.internic.net/domain/named.root.

A simple "dig NS" of one of the root name servers illustrates that IPv6 addresses for root name servers A, F, H, J, K and M will be returned, as follows:

 c:\dig  @a.root-servers.net NS
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 41
;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0, ADDITIONAL: 14
;; QUESTION SECTION:
;.				IN	NS
;; ANSWER SECTION:
.			518400	IN	NS	M.ROOT-SERVERS.NET.
.			518400	IN	NS	A.ROOT-SERVERS.NET.
.			518400	IN	NS	B.ROOT-SERVERS.NET.
.			518400	IN	NS	C.ROOT-SERVERS.NET.
.			518400	IN	NS	D.ROOT-SERVERS.NET.
.			518400	IN	NS	E.ROOT-SERVERS.NET.
.			518400	IN	NS	F.ROOT-SERVERS.NET.
.			518400	IN	NS	G.ROOT-SERVERS.NET.
.			518400	IN	NS	H.ROOT-SERVERS.NET.
.			518400	IN	NS	I.ROOT-SERVERS.NET.
.			518400	IN	NS	J.ROOT-SERVERS.NET.
.			518400	IN	NS	K.ROOT-SERVERS.NET.
.			518400	IN	NS	L.ROOT-SERVERS.NET.
;; ADDITIONAL SECTION:
A.ROOT-SERVERS.NET.	3600000	IN	A	198.41.0.4
A.ROOT-SERVERS.NET.	3600000	IN	AAAA	2001:503:ba3e::2:30
B.ROOT-SERVERS.NET.	3600000	IN	A	192.228.79.201
C.ROOT-SERVERS.NET.	3600000	IN	A	192.33.4.12
D.ROOT-SERVERS.NET.	3600000	IN	A	128.8.10.90
E.ROOT-SERVERS.NET.	3600000	IN	A	192.203.230.10
F.ROOT-SERVERS.NET.	3600000	IN	A	192.5.5.241
F.ROOT-SERVERS.NET.	3600000	IN	AAAA	2001:500:2f::f
G.ROOT-SERVERS.NET.	3600000	IN	A	192.112.36.4
H.ROOT-SERVERS.NET.	3600000	IN	A	128.63.2.53
H.ROOT-SERVERS.NET.	3600000	IN	AAAA	2001:500:1::803f:235
I.ROOT-SERVERS.NET.	3600000	IN	A	192.36.148.17
J.ROOT-SERVERS.NET.	3600000	IN	A	192.58.128.30
J.ROOT-SERVERS.NET.	3600000	IN	AAAA	2001:503:c27::2:30
;; Query time: 78 msec
;; SERVER: 198.41.0.4#53(a.root-servers.net)
;; WHEN: Mon Feb 11 12:07:40 2008
;; MSG SIZE  rcvd: 500

Grats to IANA for providing access to the root servers over IPv6 transport.

Archived at http://www.securityskeptic.com/arc20080201.htm#BlogID672 by Dave Piscitello  

ICANN's SSAC has published the results of its study and analysis of domain name front running. The report (SAC 024) reviews 120 claims submitted by Internet users following an Advisory SSAC issued in October 2007 where the committee defined domain name front running and identified the many ways one could (theoretically) obtain information about an Internet user's interest in a domain name and use that information to preemptively register the domain.

None of the claims provided sufficient information for SSAC to dismiss all other plausible explanations for the claimant's failure to register a desired name and conclude that a claim was indeed a case of domain name front running. While many Internet users may be disappointed by this finding, some may be comforted by the fact that SSAC determined that most of the claims were not acts of front running but rather of domain tasting, monetization, typo-squatting and speculation (resale). Bear in mind that SSAC's findings are based on a small sampling, and the results are important but neither prove nor disprove the existence of front running.

The results also demonstrate that front running is hard distinguish from other domain name market activities, and reveal that the Internet community doesn't fully understand the the complexities of the domain registration process and the domain name marketplace; specifically the report states, "Domain name kiting, front running, hijacking,monetization and tasting are not readily distinguishable to the average Internet user and the conclusion many users draw from the sum of these activities is that the (parties who comprise the) registration process is not trustworthy". SSAC recommends several actions for ICANN, registrars and resellers, principal among these is to help users better understand how the domain name registration process works how monetization and speculator (resale) markets influence domain names, and how the existence of secondary markets affects domain name availability.

Archived at http://www.securityskeptic.com/arc20080201.htm#BlogID670 by Dave Piscitello  

My SSAC committee's Advisory on Fast Flux Hosting and DNS is now available.

Fast flux hosting is an evasion technique used by phishers, identity thieves and other e-criminals to frustrate incident response team and law enforcement agency efforts to track down and take down illegal web sites. The fast flux technique closely resembles a 3 card monte or shell game scam, where a tosser lays three folded playing cards on a table and a victim is lured into betting on his ability to "follow the red queen" (Brits call this scam "Find the Lady"). The tosser moves all three cards at blinding speed while simultaneously distracting the victim with conversation, clever quips, and sleights of hand. Fast flux, however, is a high stakes trick, and has become a worrisome and omnipresent attack technique. In fast flux hosting, the tosser rapidly changes web site *and* DNS name server addresses, so quickly that there is virtually no time for investigators to respond.

The SSAC Advisory describes variations of fast flux hosting, identifies current measures to detect and combat fast flux, and offers additional measures. You can find SAC 025, Fast Flux Hosting and DNS, here.

Archived at http://www.securityskeptic.com/arc20080101.htm#BlogID669 by Dave Piscitello  

Archived at http://www.securityskeptic.com/arc20071201.htm#BlogID665 by Dave Piscitello  

Steve Crocker and I have co-authored a chapter on DNSSEC in an IGF publication, The Power of Ideas: Internet Governance in a Global Multi-STakeholder Environment. The book is available in its entirety in electronic (pdf) format here. The book covers a broad set of topics related to Internet governance: access, openness, diversity, critical Internet resources, emerging issues, and of course security. Our chapter discusses the DNS threat model and presents security measures introduced to mitigate these threats: Transaction Signatures (TSIG) and DNS Security Extensions (DNSSEC). We conclude the chapter with a look at the governance aspects of DNS Security.

If you study the book cover carefully, you'll notice that I am identified as a resident of Los Angeles; for the record, ICANN's offices are in Marina del Rey, California. I live on Hilton Head Island. If the book were a Wiki I'd fix this:-)

Archived at http://www.securityskeptic.com/arc20071101.htm#BlogID661 by Dave Piscitello  

A recent post to a slashdot post, DNSSEC is dead paints the following, bleak picture of DNSSEC:

• Until TLD's start signing zones, DNSSEC won't see the light of day.
• Until registrars figure out how to securely regsister and manage keys, DNSSEC is DoA
• Until zone managers start signing zones, DNSSEC won't achieve critical mass
• Without critical mass, uneven DNSSEC deployment has no value
• Without stub resolver support, DNSSEC is meaningless
• Until all the above happen, there is no business case for DNSSEC and TLD owners won't deploy it.

Colleague, friend, and SSAC chairman Steve Crocker chimed in with the following, insightful response:

I wouldn't choose quite the same language, but I think the specifics are on target. We do indeed need to get the TLDs signed, we do indeed need to have registrars accept keys from registrants -- see below for a bit more -- and we do indeed need for stub (or recursive) resolvers ask for signed responses and make use of them.

Here's a few details that suggest the picture is not so bleak.

1. A few TLDs are signed and more are coming. When the NSEC3 RFC is published, more TLDs will sign their zones.
2. We are beginning to work with registrars. In addition to providing a path for enterprises to convey their keys (or fingerprints), there will also have to be support for those registrants who do not manage their own zones. That is, for the many, many registrants who depend on the registrar to manage their zones, the registrars will also have to provide DNSSEC service. I expect to see successful worked examples in six months, give or take.
3. There is work underway to have DNSSEC implemented in the major end user systems.

Steve

One of the reasons I love working for and with Steve is that he can tease the key points out of "assertions" made by curmudgeons, acknowledge the factual elements of claims made more to posture than to inform, and build a strong counter-argument.

The Internet community is filled with impatient folks who have short memories. No communications system that antedated the Internet - Postal services, Pony Express, Telegraph, Telephone - evolved to the Internet's level of maturity and ubiquity in a little over 3 decades. All of these services experienced growing pains as they developed more secure services. But ubiquity has a price. Perhaps we should relax a moment, take a breath, and acknowledge that creating a more stable and secure name service while meeting the current needs of hundreds of millions of users isn't quite as simple as downloading a hosts file shortly after midnight from ISI was in the 1970s and 80s.

Archived at http://www.securityskeptic.com/arc20071101.htm#BlogID660 by Dave Piscitello  

If you are familiar with the concepts of insider information and "front running" in the stocks and commodities worlds, you may be interested in a recent advisory my SSAC colleagues and I issued concerning alleged cases of a similar activity in the domain name world. Domain Name Front Running refers to any opportunity for a party with some form of insider information to track an Internet user's preference for registering a domain name and preemptively register that name. The "opportunity" is characterized as a monitoring or spying on a domain name availability check using a WHOIS application or service, or a DNS query (which would return an NxDOMAIN error if the domain name is not found in a TLD zone file).

Some disappointed and frustrated would-be registrants believe that front running happens, happens a lot, and it's all the fault of registrars and registries. Without hard data to corroborate a claim, however, concluding that registrars and registries are engaging in front running is premature. What appears to be front running may prove to be coincidence or the unanticipated consequence of an aggressive domain name tasting environment, where millions of names are tasted each day. Or it may be that the free WHOIS query portal or freeware application you downloaded to your PC is spying on your availability checking. DNS operators may be farming NxDOMAIN responses and selling these to name speculators.

When the SSAC first began studying this matter some months ago, we had lots of speculation and little data. Several months have past and we have more allegations but corroborating data remain noticeably absent. We finally concluded that we needed a focused, community effort to study this matter further. SAC 022, Advisory on Domain Name Front Running, begins with a premise that a domain name availability check discloses an interest in or a value ascribed to a domain name and any such lookups should be performed with care. From a security perspective, the lookup exposes a intent to register a domain name to certain risks. SSAC assesses these risks and explores ways that availability checks could be monitored and (mis)used. The Advisory calls for community input: Internet users who perceive they have been a victim of domain name front running are encouraged to contact SSAC.

The advisory can be downloaded here.

Archived at http://www.securityskeptic.com/arc20071001.htm#BlogID657 by Dave Piscitello  

ICANN's Security and Stability Advisory Committee has published its findings and conclusions from a study on whether spammers harvest email addresses using WHOIS services. The study also considers whether protective measures registrars offer to conceal registrant email addresses are effective in reducing the amount of spam delivered.

The report can be found at the SSAC web site. Click here for a PDF.

Archived at http://www.securityskeptic.com/arc20071001.htm#BlogID656 by Dave Piscitello  

After more than a decade of milking the IPv4 address space for all it's worth, Regional Internet Registries reached a point where the addresses available for assignment are insufficient to serve organizations that cannot operate efficiently on non-continuous blocks (e.g., national and large service providers). Representatives from the RIRs are now evangelizing adoption of IPv6 and encouraging allocation of addresses from that space. While attending a conference session on IPv4 address exhaustion and IPv6 adoption, I paused and reflected on how little evidence I'd seen of IPv6 support among the commercial firewalls I've used.

What began as skunk works exercise quickly evolved to a formal activity within the ICANN SSAC. The fruit of this activity is a report, SAC 021: Survey of IPv6 Support Among Commercial Firewalls (5 October 2007).

The report presents the results of an industry-wide survey of commercial firewall appliances (and software commonly used on such appliances). The report attempts to answer the following questions:

1. How broadly is IP version 6 (IPv6) transport supported by commercial firewalls?

2. Is support for IPv6 transport and security services available from commercial firewalls available for all market segments - home and small office (SOHO), small-to-medium business (SMB), large enterprise and service provider networks (LE/SP) - or is availability lagging in certain segments?

3. Among the security services most commonly used at Internet firewalls to enforce an organization's security policy, which are available when IPv6 transport is used?

4. Can an organization that uses IPv6 transport enforce a security policy at a firewall that is commensurate to a policy supported when IPv4 transport is used?

For this survey, commercial firewall vendors were contacted and asked to complete a survey regarding IPv4 and IPv6 networking and security service support in currently available products. The report represents survey responses obtained from vendors of 42 of 60 commercial products SSAC was able to identify.

I will be presenting the results of this survey several times this month, at the

• ARIN XX meeting 19 October 2007

• ICSA Laboratories Firewall Consortium meeting 25 October 2007

• ICANN SSAC Public Forum , 29 October 2007

Archived at http://www.securityskeptic.com/arc20071001.htm#BlogID651 by Dave Piscitello  

The Anti-Phishing Working Group has published a report on the relationship between tasted domain names and phishing attacks. The report summarizes the findings of two studies that sought to determine whether parties who taste domain names also use these names to facilitate phishing attacks. One APWG member began with a set of domain names that had been used in phishing attacks and tried to determine if these names had been cancelled during the Add Grace Period. A second APWG member began with a huge set of domain names that were tasted during a one week period - FYI, the value of "huge" in this case exceeded three million tasted domains - and then attempted to match domain names used in phishing attacks against this list. The results of both studies indicate that "there are very few cases of possible domain name tasting performed by phishers and that the cases that do exist have possible explanations that are not related to tasting".

Perhaps more important than the study results are observations by the APWG members regarding the problems the practice of tasting creates for individuals and organizations who combat phishing. "At two million [plus] domain name registrations per day, tasting has expanded the pool of potential infringers [phish domains] by a factor of 40" in recent years, which makes monitoring extremely difficult for responders, and evasion much simpler for phishers.

The report can be found here. I think this report provides a really useful data point for folks who are trying to understand the implications of domain name tasting.

Archived at http://www.securityskeptic.com/arc20071001.htm#BlogID652 by Dave Piscitello  

I don't often visit YouTube. Much of what I find there has very little meaning or value to me, and it's way too hard to find the very little that I'd find meaningful and valuable at such an overwhelming site.

I am very pleased to see that ICANN's added value to YouTube by publishing a short video on Internationalized Domain Names. ICANN colleague Tina Dam does a "damn fine job" of explaining a very complicated subject in plain speak, in just over 4 minutes.

Watch the video. Encourage your company to make short, educational videos and put them on YouTube.

If enough companies follow ICANN's fine lead, the next thing you may hear from your teenager while she's trawling YouTube is, "ZOMG - YouTube is soooooooo ed you kay shun all!"

Archived at http://www.securityskeptic.com/arc20070901.htm#BlogID650 by Dave Piscitello  

My SSAC committee is studying a number of IP version 6 (IPv6) issues. This is IMO entirely appropriate since changing the network protocol of the Internet architecture has decided security and stability implications. I've been engaged in discussions about accelerated depletion of IPV4 address space, IPv6 address allocation strategies, availability of security products for IPv6, 11^th hour measures to forego IPv6 in favor of a network protocol that doesn't simply replace IPv4 and accommodate larger addresses and have discussed an even longer list of "what if?" scenarios.

Throughout these discussions, folks tell me that people are using IPv6 today.

I got curious. What are they using it for? What web sites they are visiting?

I ran a very informal test - a reality check might better describe my time invested.

First, I visited Netcraft and obtained a list of the 100 most visited web sites (all countries). How many of these are reachable using an IPv6 address?

Using dig aaaa +noall +answer [domain name], I quickly checked which sites returned a AAAA resource record:

www.google.com          NO
*.yahoo.com                 NO
www.google.de               NO^
mail.google.com            NO
www.google.co.uk        NO^
www.google.fr            NO^
news.bbc.co.uk            NO^
www.bbc.co.uk            NO^
www.google.it            NO^
www.google.es            NO^
www.google.nl            NO^
*.microsoft.com            NO
*.ebay.com            NO
www.foxnews.com            NO
en.wikipedia.org        NO
*.foxsports.com            NO
*.hotmail.com            NO
www.symantec.com        NO
www.paypal.com            NO
www.myspace.com            NO
www.bestbuy.com            NO
*.aol.com            NO
www.mapquest.com        NO
www.drudgereport.com        NO
www.circuitcity.com        NO
tgp.pornaccess.com        --
www.clubic.com            --
b.casalmedia.com        --
*.msn.com            NO
www.01net.com            NO
www.ebay.fr            NO^
www.ebay.it            NO^
www.yahoo.co.jp            NO^
www.amazon.com            NO
* denotes WILDCARD
^ denotes CCTLD

Hm.... I must be doing something wrong with my dig...

I tried host -tAAAA [domain name] with similar results.

If my hastily constructed checks are correct, none of the most visited 100 sites (on this given date) support IPv6.

As I sniff around the 'net, I find other forums where folks are talking about the futility of end user adoption of IPv6, see (18 Jul 2007) and (29 Mar 2005).

This wild speculation on my part, but shouldn't we give users destinations before we ask them to use a new method of transport?

Archived at http://www.securityskeptic.com/arc20070901.htm#BlogID645 by Dave Piscitello  

On a bus to boot camp, Forrest Gump meets Bubba. Along the route, Bubba reveals his admiration for low country shrimp,

"Anyway, like I was sayin', shrimp is the fruit of the sea. You can barbecue it, boil it, broil it, bake it, sautee it. Dey's uh, shrimp-kabobs, shrimp creole, shrimp gumbo. Pan fried, deep fried, stir-fried. There's pineapple shrimp, lemon shrimp, coconut shrimp, pepper shrimp, shrimp soup, shrimp stew, shrimp salad, shrimp and potatoes, shrimp burger, shrimp sandwich. That- that's about it."

Along the route to an ICANN meeting, you might overhear any of several conversations that would lead you to conclude that domain names are the fruit of the sea we call the Internet.

"You can taste it, kite it, monetize it, and roll it. Dey's uh, domain hijacking, sniping, domain warehousing, domain cybersquatting and domain typoh-squatting. You can register 'em, auction 'em, put 'em in a portfolio or park 'em. That- that's about it."

Some of these - parking, warehousing, auctioning, and monetization - are (annoying but) acceptable uses. Others are controversial but at this time still acceptable uses of domain names. Take tasting. Folks might argue that test-driving a domain name to see if it's a candidate for monetization is an unanticipated consequence of a 5-day Add Grace Period (AGP) policy that was (ironically) introduced to prevent a different type of unfair domaining practices. On the other hand, some argue that tasting, like secondary marketing, is a an inevitable outcome of a domain market economy. Maybe tasting, like imitation crab, is a fruit of the sea that folks deride in public but turn a blind eye to when they serve it at parties?

ICANN discourages certain abuses of domain names such as sniping and hijacking and has a Redemption Grace Period and a dispute resolution process to assist registrants when a sniper attempts to scoop up a domain name when that was unintentionally allowed to lapse or when some basty nastard up and steals a name. Some (cybersquatting and typosquatting) violate intellectual property and other rights and are illegal in various jurisdictions.

Domain name rolling something worth rolling on the floor laughing over. Rolling is an attempt to keep a name without paying for it, by releasing it before the AGP and quickly registering it again. Smells fishy, but our premise is that domain names are the fruit of the sea, right? All this effort to save a paltry registration fee?

Stupid is as stupid does.

Archived at http://www.securityskeptic.com/arc20070801.htm#BlogID638 by Dave Piscitello  

In the lastest episode of LiveSecurity's monthly podcast, Radio Free Security, host Scott Pinzon and discuss I how operators of illegal web sites use an evasion technique known as Fast Flux to avoid being located and shut down by law enforcement agencies. During the podcast, we share the insights into these attacks obtained through extensive analysis by organizations like Spamhaus and the Honeynets Project, look at some of the countermeasures that are being used to combat fast flux today, and consider future, additional countermeasures that might frustrate fast fluxers as much as they frustrate security practitioners, LEAs, registrars, and end users today.

The entire Radio Free Security podcast is available for download from iTunes.

Archived at http://www.securityskeptic.com/arc20070701.htm#BlogID635 by Dave Piscitello  

The Honeynets Project & Research Alliance has released a paper on fast flux attacks. Fast flux is an evasion technique that is used to thwart attempts to locate and shut down illegal web site operators (folks who host and profit from identity theft, pornography, illegal pharmaceutal sites, etc.). he paper, KYE: Fast-Flux Service Networks explains the complex network architecture supports these malicious activities and offers advice to service provider networks who seek to detect and mitigate these threats.

I've been studying fast flux attacks with colleagues in my SSAC committee and the Spamhaus organization. One flavor of fast flux attack (double-flux) uses DNS server information in domain name registrations to enhance evasion. This creates some very interesting problems that may best be dealt with at the domain name registration level, by the registrar. I hope to have more to say on this soon. Meanwhile, I strongly recommend that you read the Honeynet paper.

Archived at http://www.securityskeptic.com/arc20070701.htm#BlogID632 by Dave Piscitello  

While combing my local archives, I located two additional articles I published at SecurityPipeline:

• Add "Protect Your Domain Name" to your security check list

• Security Freeware: More or Less than you paid for?.

  I'm confident these are the versions originally published.

  Archived at http://www.securityskeptic.com/arc20070701.htm#BlogID627 by Dave Piscitello  

To some, the answer posed in the title of this blog entry is, "Of course!" However, an FTC report written in 2003 claimed otherwise and that report has been cited repeatedly in discussions whenever the subject of uses and abuses of the WHOIS service is raised. My SSAC Colleague Ram Mohan and staff at Afilias conducted a study to answer this very specific question. His experiments demonstrate that email addresses that are made that are only publicly available via the WHOIS (i.e., not published nor used anywhere else on the Internet, for any purpose) and not otherwise protected by a registry or registrar service to prevent abuse or automated collection will likely receive spam.

The preliminary results of this study were presented during the ICANN meeting in San Juan. A PDF of Ram's presentation is available now. I am in the process of finalizing an SSAC report that explores the data collected during Ram's experiments in greater detail. I'll post here when that report is available.

Archived at http://www.securityskeptic.com/arc20070601.htm#BlogID625 by Dave Piscitello  

I wrote about some of the unsettling problems that domain name monetization poses for Internet users and how pages that offer no content except pay per click have re-shaped the PPC market in Blog #554. I'm now wrestling with the problem of detecting and pruning hyperlinks to PPC landing pages that are creeping into my many resources pages.

Before domain name monetization, a small web admin could periodically run a hyperlink checking software to identify, correct, or cull broken links, i.e., those pages that returned HTTP/404 errors. But how does a web admin detect cases where a domain name changes hands from a registrant who's content complements the content of the web admin's site to a landing page (or worse, a page with objectionable or embarrassing content)?

A study case at my site is my Security Library. For some time, I've listed Technotronic.com as an informative site for security practitioners interested in attacks, exploits, vulnerabilites, and forensic tools. In February 2007 this domain changed hands and is now registered to Domain Name Sales Corporation. Unfortunately, my customary hyperlink checks did not catch the change in registrant and I only detected this change by happenstance: I hadn't visited Technotronic for a while and wanted to see what was new. Fortunately, the parking page Domain Name Sales posts at technotronic.com is benign: while there is nothing remotely associated with Internet security at that page, there is fortunately nothing objectionable. (By the time you read this blog I will have removed this reference.)

My problem can't be unique. I have in excess of 2000 external links on my small site. I now need an inexpensive tool or method to not only check for broken links, but to identify links that have changed hands and content. I'd love some input from anyone who's coping with this problem and I'll post them.

Archived at http://www.securityskeptic.com/arc20070601.htm#BlogID624 by Dave Piscitello  

IPv6 addresses are already included for Top Level Domain Name Servers in the root zone file. Several root name server operators have assigned IPv6 addresses to their servers but these are not included in the root hints file and the root zone at this time so IPv6 or "AAAA" address records of root name servers are not returned in responses to DNS queries sent by recursive name servers. In particular, they are not returned during what is known as a "priming exchange".

Little documentation exists regarding hints and priming. Typically, resolvers are pre-configured with the addresses of at least one root name server, and they initially rely on this "hint" information to provide recursive name service. A recursive name server may also perform a process called priming to ensure that it has an up-to-date and accurate list of root name servers. A priming query is sent to one or more of the root name server addresses configured as "hints" and asks for (QNAME=".", QTYPE="NS", QCLASS="IN"). The priming response contains NS records in the authority section and the corresponding A records in the additional section.

Priming messages are exchanged using UDP, and the DNS protocol RFCs specify a 512 byte maximum for UDP-encapsulated DNS messages. If more than two type AAAA records are added to the root hints and root zone files, the DNS priming response will exceed this maximum; in fact, when all 13 root name servers are assigned IPv6 addresses, the priming response will be 811 bytes. This changes the conditions needed to assure that a priming exchange will succeed. Firewalls must be configured to allow DNS messages containing IPv6 addresses and they must be configured to forward UDP-encapsulated DNS response messages that exceed 512 bytes and that may arrive in multiple IP fragments. Resolvers must be able to bootstrap with hints containing AAAA address records (even when IPv4 transport is used for priming) and they must be able to use DNS Extensions to notify root name servers that they are able to process DNS response messages larger than the 512 bytes.

In SAC018, my RSSAC and SSAC colleagues and I examine the problems that might arise if AAAA resource records of root name servers were added to the root hints and root zone file for the DNS. We describe and report the results of testing performed by committee members and the community at large, including recursive name server operators as well as commercial vendors of security systems and DNS name server products, to determine the extent to which these problems are likely to be encountered. T

I had a great deal of fun testing both firewall and name server software for this project, and discussing name server implementation quirks with developers and vendors who willingly participated in reporting results (see SAC016 and SAC016 for results). The test results figure prominently in the recommendations we propose to ICANN and IANA. We conclude with a roadmap the community can follow to assure that the inclusion of AAAA records in the root hints file and DNS priming responses from root name servers has minimum impact and maximum benefit.

Archived at http://www.securityskeptic.com/arc20070301.htm#BlogID603 by Dave Piscitello  

In my Blog #580 I describe an call for community participation by the ICANN Root Server System Advisory and Security and Stability Advisory Committees to test firewalls for IPv6 and EDNS0 Support at the root level of the DNS. Over two dozen test results have been reported (see SAC016), with the majority indicating that, unless configured to specifically block DNS responses containing AAAA RRs or configured to block UDP-encapsulated DNS messages that are fragmented, firewalls will not interfere with a priming exchange if the root zone were to include IPv6 addresses of root name servers.

RSSAC and SSAC are now calling for additional testing to determine whether DNS implementations (software and appliance) used to provide recursive name service will operate correctly when type AAAA resource records are added to the root hints file and root zone.

The complete name server bootstrap process must be tested to verify that changes at the root level of DNS service do not adversely affect production name service. First, the test must verify that an implementation that is configured with a hints file containing type AAAA resource records will bootstrap and operate correctly. Tests must then confirm that a resolver does not fail when it performs the priming exchange over UDP, which involves sending a DNS query for type NS for the root (".") to one or more of the root name servers identified in the test version of the hints file that contains AAAA RRs. Finally, tests must confirm that the resolver can use the information in DNS response message to perform iterative name resolution; simply put, test musts demonstrate that the resolver will operate correctly in a production name service environment.

Several root name server operators have volunteered to operate test name servers for this exercise. These servers have been configured to be authoritative for "test" root and root-servers.net zones that contain both type A and AAAA resource records for the authoritative root name servers. A test root hints file, instructions for performing the desired test, and instructions for reporting results can be found at http://www.icann.org/committees/security/sac017.htm.

Before the committees posted this advisory, I helped verify the test methodology by performing the tests on 5 DNS server implementations in my lab. My results for Windows 2000/2003 DNS server, SimpleDNS, BIND 9.2.3 running on OS X and Posadis are already reported. As I did for firewall testing, I'll contact as many DNS server vendors as I can through support and other contact methods to encourage vendor participation as well.

Tests like these provide a terrific opportunity to step outside your "day job" and learn something new. I've found about three dozen DNS server products, and many free or offer a free trial. I encourage you to install a DNS server, the dig DNS query program, and the trusty Ethereal LAN analyzer on a host and see what you can see.

Archived at http://www.securityskeptic.com/arc20070201.htm#BlogID590 by Dave Piscitello  

Attackers often include "banner grabbing" to identify potential targets. The practice commonly involves scanning for mail, web, and file server listening ports and collecting server type and version information, but as name service become more and more the target for disruption attacks, "version grabbing" will no doubt increase.

Ask any group of security practitioners and some will say that obfuscating banners and versions web and other servers is "security through obscurity". Others will concede the point but add that there's little point in making it easy for an attacker. Still others will add that the less information you reveal, the more a motivated attacker my persist in probing, and this provides a monitoring opportunity and an increased chance to detect and thwart the attack.

By default BIND9 returns the real version number of the server via a query of name version.bind in class CHAOS [1]. To hide your version type and run BIND, you add a version option to your named.conf file. Version hiding is also possible with other DNS server software: SimpleDNS Plus, for example, allows you to specify the string returned when your name server is queried for the version number. Another strategy is to simply refuse to answer to a version query (in BIND 9, specify version none). An even stricter strategy is to refuse to answer queries from an untrusted host about domains you do not trust.

Archived at http://www.securityskeptic.com/arc20070201.htm#BlogID588 by Dave Piscitello  

The Domain Name System is arguably the most critical of all Internet applications. DNS is the network corollary to the automobile ignition system: if DNS isn’t available, users are unable to resolve host names to IP addresses and thus cannot connect to Internet servers.

Our dependence on domain name service makes the DNS a prime target for attackers. For example, many pharming and identity theft attacks poison name server records so that responses to DNS queries direct unsuspecting users to bogus websites. Other attackers try to disrupt name service by launching distributed denial of service (DDoS) attacks against top-level domain and root name servers.

Authentication, confidentiality and integrity protection would make it difficult for attackers to exploit the DNS for pharming and identity theft purposes, but these security measures weren’t among the original DNS design objectives and protocol. For some time, the Internet community has been developing—and deploying—measures to make DNS secure. Let’s look at why these are important and how they can help mitigate several types of attacks.

Read the rest of this article at Business Communications Review.

Archived at http://www.securityskeptic.com/arc20070101.htm#BlogID587 by Dave Piscitello  

My ICANN SSAC committee is collaborating with the DNS Root Server System Advisory Committee (RSSAC) to study the matter of including the IPv6 addresses at the root level of the DNS. This involves adding "AAAA" resource records to what is known as the hints file, a file that is typically preconfigured into systems that act as name servers and resolvers. Resolvers do not rely exclusively on the hints file, since this is static information and may change over time. Instead, most resolvers issue a Type NS DNS query to one or more of the root name servers identified in the hints file to verify the accuracy of their local hints file. This query and the associated response from a root name server is called a priming exchange.

The Problem

Currently, five root name servers have been assigned IPv6 addresses. These addresses are not included in the hints file, nor are they returned in DNS priming responses. If the five IPv6 addresses were added to the priming response, the message would increase from the current length of 436 bytes to 576 bytes. Moreover, when all 13 root name servers are assigned IPv6 addresses, the priming response will increase in size to 800 bytes. This imposes two conditions on firewalls and other security systems that protect resolvers.

The first is that any firewalls that are situated between resolvers and root name servers must be able process DNS messages containing Type AAAA resource records. Some DNS proxies and stateful inspection firewalls may be configured (by default or policy) to block DNS messages that do not strictly conform to "pre-IPv6" DNS specifications. The second condition relates to the increased message size resulting from the inclusion of IPv6 addresses in the priming response. Firewalls must

allow UDP-encapsulated DNS response messages larger than the 512 byte maximum DNS message size specified in RFC 1035 to resolvers that issued the priming request. Some firewalls may not recognized the DNS extensions (EDNS0), while others may have been configured to block suspiciously long UDP messages to thwart DNS DDOS amplification attacks.

Testing Your Firewall

It's relatively easy to test if your firewall satisfies these two conditions. Several top level domains return IPv6 addresses in DNS response messages today, and several of these responses are larger than 512 bytes. A simple "dig" of the HK TLD using the command "dig hk ns +bufsize=4096 @203.119.2.18" will evoke a 747 byte response message containing AAAA records.

My SSAC/RSSAC colleagues and I hope to capitalize on the ease of this testing by inviting *everyone* to try this dig command and tell us their results. Specifically, you can email me following your test and provide the following information:

• Firewall Product Manufacturer
• Firewall Model
• Firewall software/firmware version
• Action when AAAA RR encountered
• (Optional) A copy of the dig input and output (as illustrated above, this can be obtained by directing the output to a file, e.g., "dig hk ns @203.119.2.18 > digAAAA.txt")
• Action when DNS message larger than 512 bytes received
• (Optional) A copy of the dig input and output (as illustrated above, this can be obtained by directing the output to a file, e.g., "dig hk ns +bufsize=4096 @203.119.2.18 > digEDNS0.txt")

You can read more about this initiative - and see the results we've already complied - by visiting the ICANN web site and reading SAC016.

Archived at http://www.securityskeptic.com/arc20070101.htm#BlogID580 by Dave Piscitello  

ICANN colleague Kim Davies shared a hyperlink to xkcd.com , where Randall Munroe hosts a webcomic of romance, sarcasm, math, and language. Randall uses fractal mapping to render an interesting graphical interpretation of the partitioning and assignment of the IP version 4 address space. The unallocated blocks are cleverly depicted as green fields:-) Click on the thumbnail to see the larger image at XKCD. Perhaps the most amusing aspect of the image is the ALT tag, which reads "For the IPv6 map just imagine the XP default desktop picture."

Archived at http://www.securityskeptic.com/arc20061201.htm#BlogID575 by Dave Piscitello  

A copy of the real time captioning of the ICANN SSAC Sao Paolo Open Meeting is now available here. You can grab a copy of my study, SAC014, Information Gathering Using Domain Name Resource Records, read the captioning, and get a deeper appreciation of the study I conducted by reading the transcript while viewing the presentation.

One of the idiosyncrasies of real-time captioning is that every word and verbal pause (um, ah, hmmm) are recorded, which has several unintended and humorous consequences. During the SSAC meeting, we experienced some technical difficulties with projection, and the conversation associated with resolving was duly recorded. While the exchange among the panelists is amusing, it does serve one useful purpose: open the link to the captioning and search for the phrase, "For those of you who will get seasick,"...

Archived at http://www.securityskeptic.com/arc20061201.htm#BlogID574 by Dave Piscitello  

Early in 2006, a series of Distributed Denial of Service (DDoS) attacks victimized DNS root and Top Level Domain (TLD) name server operators. These attacks merit careful analysis because they combine several attack tools and methods to increase their effectiveness. The attacks also call attention to an operational problem that was solved long ago, yet most IT administrators and service providers have not implemented the most effective and appropriate response.

In my article, Anatomy of a DNS DDoS Amplification Attack, I describe the tools attackers use in DNS DDoS amplification attacks, the attack itself, and countermeasures that are generally considered best practices.

Variants of the attack I describe here continue to harass enterprises and service providers. Shortly after my article was published by Watchguard Technologies, I received the following comment from a subscriber:

I was targeted by this particular attack, captured screen shots and the works, and my ISP was worthless in their response - because they didn't see an unusual amount of traffic on THEIR side, but I was completely shutdown at my firewall. Thanks for confirming my assumptions about the attack - very validating!

While it's nice to help folks validate assumptions about attacks, it would be so much more rewarding if service providers would voluntarily adopt countermeasures such as source IP address validation so we can reduce the frequency and amplitude of not only DNS but many forms of DDoS attacks.

Archived at http://www.securityskeptic.com/arc20061101.htm#BlogID571 by Dave Piscitello  

On behalf of ICANN's Security and Stability Advisory Committee, and with the help of my colleague Suzanne Woolf, I prepared a short publication explaining the problems users and applications may experience when Top Level Domain registries make use of synthesized responses for domain names that are non-existent, not registered, or in DNS-speak "uninstantiated".

A name server that receives a query for a non-existent or unregistered name from a client should return a "name error." This error tells the requesting application that the name is not instantiated. When domain authority uses a single A resource record in its zone for all unregistered or non-existent names in its domain, and then returns a *positive* response (yes the name exists, and you can reach the host at this IP address) rather than an error (no, the name doesn't exist), the domain authority is said to have implemented a synthesized response-based or "wildcard" service.

Wildcard services can cause applications to behave in undesirable ways, and create security problems for email and other applications that need to know when a name can't be resolved. In the paper, SSAC explains several of these problems and re-iterates the reasons why TLDs should not use wildcard resource records.

Archived at http://www.securityskeptic.com/arc20061101.htm#BlogID568 by Dave Piscitello  

A transcript of Vint Cerf's Opening Remarks at the IGF is available at ICANN. While reading this speech, I took special note of several comments Vint made:

• "Its [The Internet's] ability to absorb new technologies and to support an increasing variety of applications are indicators of the power of its simple, clear and well-defined technical specifications and openly accessible capabilities at all layers of its architecture."

• "There are only an estimated one billion users on the Internet today. That number might actually be larger if one considers that some of the 2.5 billion mobiles in use are also Internet-enabled... We still have to provide several billion more users with access"

• "[After only 33 years] the Internet is already the largest, distributed collection of historical and current information ever in existence."

• "Steps are needed to assure that the information we accumulate today will be usable not merely decades but centuries and even millennia into the future."

Vint packed more insightful remarks in a 5 minute speech than most politicians manage in an hour. Sometimes I think Socrates was correct in claiming that the world would be best managed by philosopher kings.

Archived at http://www.securityskeptic.com/arc20061101.htm#BlogID564 by Dave Piscitello  

On behalf of ICANN's Security and Stability Advisory Committee, II recently completed a study of approximately 5000 domain name registration records, randomly selected from several million from com, net, and org. The purpose of my study was to approximate the extent to which personal contact information can be extracted from domain name registration information. For this study, I defined personal contact information as "sufficient attributes" to feel confident that the registrant is an individual, or an individual operating a home business. I also wanted to determine if it would be possible, using the information collected, to speak with or visit the individual at his or her residence, e.g., make personal contact.

I applied the same kinds of information gathering techniques one might expect an attacker to use when he attempts to identify a target for an attack. Similar techniques might be used by a private investigator or law enforcement agent. I used a variety of databases and search tools to learn more about the registrant from the information collected by registrars and made available via a Whois query or in bulk::

• A real estate database (trulia.com)
• An Internet telephone directory (whitepages.com offers reverse number lookup)
• Search engines (Google, Yahoo!)
• Aerial photographs of the registrant's address (GoogleEarth)
• E-maps (Map Quest)
• Companies and Industries directory (hoovers.com)
• Web sites hosted at registered domain name
• and my personal familiarity with geographic region I chose (Philadelphia, PA).

I classified registrants based on a set of matching criteria, with the underlying assumption that the more criteria (out of a possible 10) that are matched, the higher my confidence would be that the registrant information identifies an individual (or business).

The findings from my study are now available in presentation format at the ICANN SSAC web pages.

Archived at http://www.securityskeptic.com/arc20061001.htm#BlogID559 by Dave Piscitello  

Who ever imagined that registration of a domain name could provide a means of deriving recurring revenue? Domain traffic monetization does just that. Register a domain name and host a web page. On the page, place advertisements for 3^rd parties that provide referring links to the advertising party. In the referring link, embed an identifier that identifies you to the advertiser, and the advertiser will pay you a fee for each referral. Earn an income while you sip tea on your porch.

You may know domain traffic monetization by another, less opaque, name: pay-per-click. Pay-per-click is easy to remember because each time the visitor clicks on a link on your web page, you are paid for the "click" or referral. Domain traffic monetization is one of many reasons why virtually every domain name that has ever been registered has some value to someone.

I can't help but wonder how the PPC business model can sustain millions of independent PPC sites, where the budget domainers use Google AdSense and Yahoo! Publisher Network. There are only so many web users, and the number of clicks, while not constant, will not grow exponentially. It may not grow at all. In fact, one could argue that interest and *trust* in referral sites will diminish over time. What happens when the number of clicks per minute hits the knee in the curve, and the referral trajectory flattens out? I think the answer is that there's more intense competition to retain and increase clicks at sites. If this is indeed the answer, then won't revenue per site wane? Isn't consolidation the only way to maintain market share and grow revenue?

I see evidence of these phenomena on my site. At its peak, my AdSense revenue was paying for my broadband access, my static IP addresses, and replacement/upgrade hardware. In a year's time, with increased visits and the same content refreshment rate, I'm making about 1/10^th of my peak income. From this and similar anecdotal evidence from colleagues, I'm willing to speculate that (a) large monetizers are already gaming search engines and drawing traffic to their consolidated PPC landing pages, and (b) there's far too little revenue in PPC for the small site operator to bother.

This post marks the beginning of the end of AdSense on my site. My blog pages will no longer carry ads. My static pages will be updated as I find time. It was a nice run while it lasted:-)

Archived at http://www.securityskeptic.com/arc20060901.htm#BlogID554 by Dave Piscitello  

Between December 2005 and March 2006, some DNS (Domain Name System) root and Top Level Domain (TLD) name server operators were subjected to numerous denial of service (DoS) attacks. These attacks seriously disrupt name resolution service by directing an overwhelming amount of traffic at the communications links that name server operators use to provide service.

The targets for such attacks are not limited to root and TLD name servers; major financial and eCommerce name servers may be even more vulnerable, and the consequent disruption to name resolution in such focused attacks have grave economic consequences. Law enforcement agencies and governments worldwide should treat these incidents as serious attacks, deliberately launched against very high profile targets, by parties who may be politically or financially motivated.

Read the rest of this article in the ENISA Quarterly June 2006.

Archived at http://www.securityskeptic.com/arc20060701.htm#BlogID539 by Dave Piscitello  

My SSAC colleagues and I have published an advisory that describes incidents where, by choice or oversight, registrants allowed a domain name registration to expire, anticipating that no harm would come from allowing the registration to lapse. In these and other incidents, a different party registered the domain name, and the activities of the new registrant proved harmful to the interests of the previous registrant.

The purpose of this Advisory is to explain ways in which a domain name may accrue reputational and commercial value. The Advisory uses reported incidents to illustrate that registrants should consider the potential for damage to reputation, material loss, and lost recurring revenue opportunities before allowing a name registration to expire. The Advisory, Renewal Considerations for Domain Name Registrants is available as a PDF download.

Archived at http://www.securityskeptic.com/arc20060601.htm#BlogID538 by Dave Piscitello  

Users expect search engine results to lead them directly to relevant content. PPC landing pages - pages hosted by domain name monetization entrepreneurs that contain only PPC advertising - detract from the anticipated user experience in several ways. First, they introduce a level of indirection: if you submit a search query for "firewalls", you expect content relevant to firewalls and not a page containing only referral links to sites that sell firewall-related products and services. Second, they create opportunities to obfuscate and deceive. Aggressive PPC entrepreneurs are not above "gaming" search relevance and ranking systems, so you can submit a search query for "health and fitness" and be directed to a landing page full of ED advertisements.

I find it difficult to distinguish these forms of search result manipulation, especially the second case, from search engine hijacking. Search engine users are not finding the content they expect, nor able to visit there directly and conveniently. These are conditions that should cause search engine providers to assess whether monetization landing pages pose threats to their businesses. While monetization landing pages generate revenue for search engines, they are increasingly eroding consumer confidence in search engine efficacy and utility.

My first reaction to this growing problem was to consider whether an HTTP proxy or Firefox plug-in might intercept search results, visit and analyze pages, block pages that contained more than a user settable number of PPC advertisements, and add this to a blocked list. This is probably a non-trivial but doable URL filtering script. This is also exactly the kind of wrong-ended security measure I hate. I'd rather see Google, et. al., come to the conclusion that relevant, accurate and impartial responses are the core competencies of search engine providers. IMO, adding logic that relegates pages with little or no content relevant to the query to the bottom of the list of results is a better long term business strategy.

Archived at http://www.securityskeptic.com/arc20060601.htm#BlogID537 by Dave Piscitello  

My presentations from the ICANN Marrakech public SSAC meeting are now posted at the ICANN SSAC web. My first presentation describes incidents where registrants did not renew a domain name registration, anticipating that no harm would come from allowing the registration to lapse. In these and similiar incidents, a different party registered the domain name, and the activities of the new registrant proved harmful to the interests of the previous registrant. How harmful? In several cases, the new registrant used the domain as a referral site for pornography web sites. The presentation offers recommendations to registrants on how to safeguard against accidental non-renewal and ways to determine whether continued registration of a domain name might prove useful or profitable.

The second presentation describes scenarios where a registrant, e.g., Jane Doe, arranges for out-of-bailiwick DNS name service, e.g., from Fred ISP, Fred ISP allows its domain name registration to expire, and Jane Doe's name service is interrupted. I also explained how an attacker can exploit this scenario by registering Fred ISP's domain name, operating a name service with altered DNS information for Jane Doe's domain, and redirecting traffic from Jane Doe's domain for phishing, email and other nasty attacks. The presentation offers measures registrants can take to safeguard against such name service interruption and traffic hijacking incidents.

Pending approval this week by ICANN's board, SSAC will publish Advisories on both these topics.

Archived at http://www.securityskeptic.com/arc20060601.htm#BlogID536 by Dave Piscitello  

One of the topic areas I study as a member of the ICANN SSAC is the administration of the domain name registration record databases by TLD registries. This information is commonly (though incorrectly) called WHOIS data, in deference to the protocol popularly used to access contact information for domain name registrants. Privacy is a very sensitive issue in this study area. Most stake holders in the WHOIS privacy debate appreciate the need for some form of control to prevent misuse of contact information by spammers, domain name hijackers, and other more serious criminal actors. Many stake holders are not willing to concede "unfettered access to WHOIS data" because it might delay or interfere with their abilities to investigate criminal activities and violations of intellectual property rights, to resolve technical problems associated with name service or web presence, and to explore new revenue opportunities.

Bruce Schneier's essay of May 19, The Value of Privacy, ought to be "must reading" for anyone involved in the WHOIS privacy debate. Although Bruce is responding to revelations of NSA surveillance, his observations and conclusions are spot on target for the WHOIS debate as well: instead of arguing "security versus privacy", we should be seeking "security plus privacy".

Archived at http://www.securityskeptic.com/arc20060501.htm#BlogID529 by Dave Piscitello  

A recent thread on bug-traq debates whether Microsoft's DNSAPI DLL deliberately subverts the standard and intended client DNS resolver functionality. The initial post explains that Microsoft embeds certain names from the microsoft.com domain in the DSAPI DLL and that this action not only prevents these excluded names from being resolved by an external name server, but also prevents the user or administrator from using %\Windows\drivers\etc\hosts to alter the name/address binding locally, e.g., to localhost (127.0.0.1).

Is this, as the poster claims, "yet another example of the sheer breathtaking arrogance of Microsoft's belief that they have the right to control your computer and misdirect the normal flow of operations if they believe doing so to be in their own financial advantage?" or is it a measure to prevent malware from altering the host file and hijacking or disrupting services Microsoft offers, including Windows Update? You make the call.

Every so often, someone on this list loses patience with the folks who try to garner credibility and support by bashing Microsoft. In this case, "Thor (Hammer of God)" offered such a deliciously worded reply I can't resist sharing an excerpt:

I think the noted objections are a bit hyperbolic. (Or as Dr. Tom Shinder would say, a "Creative Interpretation.")

Statements like "deliberately sabotaged,"corrupting the resolver," and "intentional dns poisoning" sound like something Steve Gibson would say. It's a local hosts-file entry filter, and is in the API.

In one bold stroke, Thor aptly whacks *two* anti-Microsoft moles. Brilliant! But wait, there's more! On the finishing stroke, he adds value by making the following observations:

Malware hosts-file modification is common-- it makes sense for Microsoft to do this, though again, it would have been nice to see this functionality mentioned in the SP2 documentation. If administrators are really freaked about this, then they can block in their own internal DNS, proxies, firewalls, etc... This boils down to a "home user" issue, and thus, I think the decision to create exceptions was smart.

If one doesn't want auto-updates on, then turn them off.

Thanks, Thor. Wield that Mighty Hammer more often!

Archived at http://www.securityskeptic.com/arc20060401.htm#BlogID520 by Dave Piscitello  

The attack launched against Joker.com last month is a recent example of attacks directed at TLD and registrar name servers for several months. The attacks are very effective and illustrate how vulnerable the Internet remains while we refuse to implement source IP address validation on a large scale.

On behalf of the ICANN SSAC, I gave a presentation on DNS DDoS Amplification attacks at the ICANN meeting in Wellington NZ. The presentation is based on an SSAC Security Advisory I prepared on behalf of the committee. SAC008 describes representative incidents, identifies the impacts, and recommends countermeasures that TLD name server operators can employ for immediate and long-term relief from the harmful effects of these attacks.

My presentation is included in the SSAC Workshop presentation (local copy).

Archived at http://www.securityskeptic.com/arc20060401.htm#BlogID517 by Dave Piscitello  

Dennis Forbes has written and entertaining article describing the current distribution of domain registrations, based on 2^nd level label lengths. Dennis explains how all the 2-, 3-, and 4- letter labels are reserved, registered and hoarded by speculators, and the majority of these are "taken" because they are treasured acronyms. Forbes' web host (yafla.com) is itself a concession to acronym exhaustion and an emerging enthusiasm for longer acronyms: yafla = yet another five letter acronym :-).

The article is informative as well and provides statistics and graphs that offer some insights into how society has evolved as it searches for domain names. See In Search of Domain Names.

Archived at http://www.securityskeptic.com/arc20060301.htm#BlogID515 by Dave Piscitello  

One visit to NirSoft.net and you understand exactly why Nir Sofer is respected as one of the most and prolific developers of useful freeware. Nir's developed dozens of useful password cracking and recovery utilities, and dozens of network and administrative utilities as well.

Two utilities I found to work well are WhoisThisDomain and WhosIP. WhoisThisDomain differs from other domain checking utilities in that it always checks the authoritative Whois for the top level domain under which a name is registered, and it allows you to fill a text box with multiple domains before submitting queries. A sample output window follows:

WhosIP is a DOS command line program that queries IP address registries to identify the organization to whom an IP number or block is assigned. A sample WhosIP output follows:

E:\program files\WhosIP>whosip.exe 65.37.52.11
WHOIS Source: ARIN
IP Address: 65.37.52.11
Country: USA - Washington
Network Name: ELI-3-NETBLK99
Owner Name: Electric Lightwave Inc
From IP: 65.37.0.0
To IP: 65.37.127.255
Allocated: Yes
Contact Name: Electric Lightwave Inc
Address: 4400 NE 77th Ave, Vancouver
Email: support@eli.net
Abuse Email: abuse@support.eli.net
Phone: +1-800-622-4354
Fax:

These are handy tools for firewall, content proxy administrators and generally, anyone who examines log entries containing IP addresses and needs a quick and convenient way to identify blocks where malicious traffic originates. Both are worth a look. While you're looking browse the entire freeware inventory.

Archived at http://www.securityskeptic.com/arc20060101.htm#BlogID495 by Dave Piscitello  

If you have children, you'll probably recall the pull-string figure Wild West Woody from the Pixar movie, Toy Story. Among the handful of fun phrases Woody would say when you pulled his string were, "There's a snake in my boot!" and "Someone's poisoned the water hole!" If Hasbro were to release a "virtual" Woody today, he'd warn us of a similarly serious threat, DNS cache poisoning. The analogy is simple: in the Wild West, a poisoned well spelled disaster; on the Internet, a poisoned DNS cache is no less a calamity. More...

Archived at http://www.securityskeptic.com/arc20060101.htm#BlogID489 by Dave Piscitello  

I received an email from a someone in Paraguay today, inquiring about VLAN support on 3Com switches. He obviously tried very hard to communicate his needs in English, and his effort was no worse than I imagine my frequent efforts in Spanish to be, so I replied in English and Spanish. He immediately thanked me profusely, entirely in Spanish. Perhaps my Spanish isn't as bad as I think.

Fortunately, English and Spanish mostly share a common script. With the exception of the occasional tilde and umlaut mark, the majority of characters (glyphs) of Romance (New Latin) languages can be represented in basic ASCII. However, if I were to have received email in both native language and English from someone in Beijing, Seoul, Bankok, Tel Aviv, or Mosul, I'd need the ability to type and display characters from Chinese, Korean, Thai, Hebrew, or an Arabic language scrip