locks keep lawful people out...    

The Security Skeptic

Dave Piscitello's Security Weblog

Skeptic (sceptic): a person inclined to question or doubt accepted opinions.

Web www.corecom.com The Security Skeptic
Tue, 23 Jun 2009 00:00:00 00, 732
Orphaned Name Servers

When you register a domain name, you typically identify a name server that will host the DNS information for that domain (the zone file).A best common practice recommends that you identify that name server using a name from another domain (also called an out of bailiwick assignment since the name is not in your "bailiwick", e.g., your zone). Let's look at an example.

Imagine that I have registered domains example.NET and example2.INFO, and have identified NS1.example.INFO and NS2.example.INFO as the name servers for example.NET. In the NET zone file we find the name server (NS) and A records (also called glue) for example.NET, as follows:

example.NET NS ns1.example2.NET

example.NET NS ns2.example2.NET

.

.

.

ns1.example2.NET A 10.0.1.53

ns2.example2.NET A 10.0.2.53

Somewhere in the INFO zone file you'll find my name servers for example.NET, e.g.,

example2.NET NS ns1.example2.INFO

Example2.NET NS ns2.example2.INFO

Now, let's suppose example2.INFO is removed from the INFO registry. Assuming I registered example2.INFO, this might occur if I had failed to renew my registration for example2.INFO. It might also occur if the domain was suspended because it had been associated with malicious activity (hold this thought). Irrespective of the reason, the INFO registry operator removes example2.INFO. The NET registry operator, however, won't remove the NS records. Unilaterally removing glue records might interrupt name service for any other domain that also used ns1.example2.INFO or ns2.example2.INFO to host zone files (this is pretty common). In cases like my example, where the domains involved are not in the same top level domain, the registry operators don't know unless they are notified by the registrant(s) involved in the zone change. We now have an orphaned name server, i.e., the name server record exists in NET but the parent domain name no longer exists in INFO. NET will return name server information for example.NET, and the physical host will continue to serve up records from the example.NET zone file.

Let's go back to that thought I asked you to hold. Imagine that a bad actor registers a bunch of phish domains in NET, and hosts them at an orphaned name server in INFO. Now imagine that the parent domain is removed in the same manner as my example, as a result of a suspension action by a registrar. The orphaned name server is now a dark corner from which other phishing domains can operate name service.

The preliminary results of an APWG study of the prevalence of this form of DNS abuse by Internet Identity and Karmasphere indicates that there is a correlation between malicious domains and orphaned name servers. I'll link the report when it's published. Meanwhile, don't orphan your name servers, and if you find an orphan, report it!

N.B. I gave a presentation on this subject at the Sydney ICANN meeting.

Archived at http://www.securityskeptic.com/arc20090601.htm#BlogID732 by Dave Piscitello  


Fri, 22 May 2009 00:00:00 00, 731
I can't read this WHOIS output!

Many Internet applications today support characters from local languages, alphabets or scripts. Visit pages in the dot JP top level domain and you'll eventually find one that uses Kanji characters. Visit domains in the dot AE top level domain (United Arab Emirates) and you'll find domains that display pages in Arabic characters. Support for characters from local languages, alphabets or scripts is growing. This has a positive affect for millions of users for whom characters from the Latin character set are just as unfamiliar as Chinese, Arabic and other characters sets are to English reading individuals.

WHOIS is an internet application. Today, most WHOIS services display contact and DNS configuration information using US-ASCII7 characters. Users (unless they are bad actors) commonly submit contact and DNS configuration information to WHOIS applications using primarily US-ASCII7. The current condition is convenient for English reading WHOIS users, but it is slowly changing and the potential for a WHOIS Babel effect exists. In fact, it exists in a very small way today: the SSAC report illustrates this through examples of what users may encounter today (Hint: the registration data you see and the data you can submit are strongly influenced by the registrar or 3rd party WHOIS service you use).

ICANN's SSAC has just released a document that explores how the use of characters from local scripts affects WHOIS users who want to identify and contact a party who has registered a domain name. This is a quite common practice for folks who investigate phishing, spam, identity theft, and web defacements. It's also common for people who deal in domain names, who might be interested in acquiring the domain or marketing services to the domain registrant.

The issue is simply stated as "no standards or conventions exist" for how anyone who offers WHOIS services is to support local languages and scripts. The Internationalized Domain Name standards and guidelines only apply to domain names. All the other information that is collected when a user registers a domain name is "in play" for both user submission and display. This is unsettling at best. Imagine a law enforcement agent (LEA) who is gathering information regarding an alleged kiddie porn or phishing site. He does a WHOIS lookup on a domain name that appears to be associated with the site. He can't read it, nor can any of his colleagues. This certainly occurs today among non-English reading LEAs but the problem will worsen, especially if the bad actors determine that creating registrations in Klingon helps sustain their attacks.

I've only touched upon a few aspects of a complex issue here. For a more thorough consideration, read SAC037: Display and usage of Internationalized Registration Data: Support for characters from local languages or scripts.

Archived at http://www.securityskeptic.com/arc20090501.htm#BlogID731 by Dave Piscitello  


Mon, 12 Jan 2009 00:00:00 00, 715
The Ask Mr. DNS Podcasts

Colleague Matt Larson and DNS and Bind author Cricket Liu have teamed up to produce podcasts on DNS issues. In Matt's words, the goal of their joint project is "to explain (DNS) and enliven what's usually a dry,technical subject".

The podcast's web site is http://www.ask-mrdns.com. You can subscribe to the podcast through iTunes and RSS channels.

Matt describes the inaugural episodes as follows:

  • Episode #1: Welcome to the inaugural episode of the Ask Mr. DNSPodcast! In this first episode, we introduce ourselves and talk a little about our backgrounds. We also explain who the heck Mr. DNS is and why we've named our podcast after him. Then we actually answer a DNS question and wind up the episode discussing some interesting DNS research we've each done.

  • Episode #2: In our second episode, Matt and Cricket discuss Matt's distaste for handbells and lapse into a discussion of Star Trek (The Original Series) -- oh, and answer an actual listener's question about when DNSSEC deployment will be widespread. Also, Cricket says, "Right, right" many times.

The episodes are very entertaining in a "techies with senses of humor and a wealth of expertise talking technology" manner. Matt and Cricket are extremely knowledgeable in the DNS space (Note: I don't believe for a NY minute that Cricket is only qualified to talk about DNS as he intimates in Episode 1.) Neither Matt nor Cricket have overly inflated egos and both have an engaging, self-deprecating way of imparting knowledge. The banter is genuine and you can easily imagine that you're listening to a conversation in an informal setting, as a welcome (if silent) participant. If this is not enough to convince you to listen in and you need a kicker, try this:

You'll actually learn something.

Archived at http://www.securityskeptic.com/arc20090101.htm#BlogID715 by Dave Piscitello  


Mon, 10 Nov 2008 00:00:00 00, 710
DNS and Fast Flux Attacks: What a difference a year makes

In January, SSAC published an advisory on Fast Flux attacks. A basic fast flux attack employs automated, rapid modification of IP addresses assigned to hosts in the DNS to hide the location of web sites supporting malicious, illegal, or criminal activities. A variant, double flux, not only modifies IP addresses to obfuscate the location of web sites but name servers for the domains used to assign names to those web sites.

Over the past 10 months, researchers and investigators have studied fast flux attacks and today, we are better able to characterize fast flux attacks. For example, not all flux attacks are "fast". Flux attack still change IP addresses, though, and often use hundreds of IP addresses that are often traceable to compromised PCs connected to broadband access networks. Flux attack networks commonly span many autonomous systems. These characteristics and more allow us to accurately identify flux attacks and some outstanding research provides us with a formula that identifies these networks with an accuracy of 99%.

I gave a presentation of how our understanding and appreciation of flux attacks has evolved at the ICANN Cairo Meeting today. Visit again in December for ways we might reduce the threat fast flux networks pose.

Archived at http://www.securityskeptic.com/arc20081101.htm#BlogID710 by Dave Piscitello  


Thu, 30 Oct 2008 00:00:00 00, 707
Protecting High Value Domain portfolios

Following three high profile hijackings (eBay/Paypal, ICANN, and Comcast), ICANN's SSAC began a study to determine whether domain registrars could offer additional protective measures to customers (registrants) who held high-profile, "business critical" domain portfolios. Since August, the committee has interviewed customers and registrars who have been victimized by attackers to better understand the vectors, exploits, and social engineering tactics attackers used to gain administrative control over high value domains. SSAC also interviewed registrars who offer online reputation protection services and organizations who have strong opinions regarding the types of preventative measures they feel are necessary to protect their names from theft and abuse.

I presented an interim report of SSAC's progress at the ICANN Cairo meeting. Download a copy a presentation I will give next wee at the Cairo Meeting.

Archived at http://www.securityskeptic.com/arc20081001.htm#BlogID707 by Dave Piscitello  


Wed, 20 Aug 2008 00:00:00 00, 699
"While the end of the Internet is not near, neither is IPv6"

The title of this post is a quote from Craig Labovitz, who has published a thoughtful and insightful article on the state and future of IPv6 at the Arbor Networks Security Blog. Craig begins his article, The End is Near, but is IPv6?, by reviewing nearly a year's worth of hype and F.U.D. over the exhaustion of the IPv4 address space and the imminent collapse of the Internet to set the stage for investigating how far along IPv6 deployment truly is. Craig asserts that "as an industry we don’t have a good measure on the relative adoption success of IPv6 with respect to Internet traffic", but he extracts a number of anecdotal statistics from an Arbor Networks' technical report that are sufficient to reinforce my hitherto uncorroborated opinion that IPv6 deployment languishes still.

The traffic trends Arbor Networks observed from the impressive data set it accumulated indicate that IPv6 represents less than one hundredth of 1% of Internet traffic. I checked my firewall logs: traffic representing port scans of my network exceed that figure by several orders of magnitude and I'm confident that this is one of those cases where your mileage won't vary. On the positive side, however, inter-domain IPv6 traffic is growing steadily. The China Next Generation Internet is hosting the China Olympics using IPv6 and global interest in this event should dramatically change both these percentages.

Arbor Networks determined that only 0.4% of Alexa Top 500 websites are reachable using IPv6. Now, 0.4% is an admittedly better figure than the figure I reported on September 11, 2007, when I determined that none of Netcraft's 100 most visited sites supported IPv6, so we can claim progress in this case, albeit small.

Craig next discusses factors inhibiting IPv6 deployment and citing lack of support for IPv6 MPLS VPN, SNMP, and IPv6 flow export. He also cites the "only one in three commercial firewalls support IPv6" result from my SSAC IPv6 firewall survey. He closes the article by offering observations why, despite measurements that suggest deployment is mired in muck, IPv6 remains the only viable answer. My favorite is, "No one has the stomach to spend another twenty years replacing IPv6 with something else."

Read the article and read the comments posted at the blog. Some offer additional, useful insights.

Archived at http://www.securityskeptic.com/arc20080801.htm#BlogID699 by Dave Piscitello  


Thu, 26 Jun 2008 00:00:00 00, 696
What name servers support DNSSEC?

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  


Tue, 24 Jun 2008 00:00:00 00, 695
The dark side of name DNS error resolution

Internet services typically have a standard way to signal errors. The DNS protocol uses the Response code field to signal and describe problems it encounters when attempting to respond to a query from a client (resolver). An authoritative name server will return a Name Error, also known as an NXDomain response (for non-existent domain) to indicate that the domain name in the query does not exist. In SSAC's latest report, DNS Response Modification, we explain how an entrusted operator or any J.Random.ISP are modifying DNS response messages intended to signal name errors for profit and how attackers are exploiting these "error resolution services" for their own *fun* and profit.

This (ahem) interesting practice is implemented today; in fact, several companies make a living operating error resolution services for other service providers and registrars. There are two variants. The first involves what we call an entrusted agent: your ISP, registrar, or a company you pay to host your DNS. Commonly you hand your domain's zone file over to such folks and they host it on their name servers. Here's what may happen if the agent you or I choose engages in error resolution, and it may happen without your knowledge and consent.

I'll use securityskeptic.com as the domain for this example. I give my zone to a DNS operator to host. The agent's name server receives a DNS query for a name that I didn't include in my securityskeptic.com zone; e.g., a mistype like ww.securityskeptic.com. I expect that this name server would return a non-existent domain response to this query; hopefully, you'd expect this, too. Ah, but suppose I didn't do my homework and discover - to my dismay! - that the DNS operator I chose resolves DNS errors to enhance the user experience. Huh? What's that mean? Well, before hosting my zone file, this DNS operator has inserted a wildcard record in my zone that says "use this IP address for any name that does not appear in securityskeptic.com's zone file". What's at that IP address? Well, on Port 80/HTTP, you will likely find promotional marketing, paid advertising or a search engine.

Not happy with that scenario? Sorry, there's more. If I learn about this practice, I can demand to opt out of this practice or move my DNS to a provider that doesn't resolve errors in this manner. Problem solved, right? Well, not exactly. Few DNS queries are resolved by asking the authoritative name server for a zone; instead, most are resolved through an iterative process by DNS servers called resolvers. And it turns out that any iterative resolver that's situated between my name server and the user who typed ww.securityskeptic.com can intercept the NXDomain response my name server returns, silently alter my response message, and redirect the client to an IP address of his choice. What's at that IP address? Promotional marketing, paid advertising or a search engine.

It gets worse. It turns out that security wonks like Dan Kaminsky have studied error resolution, visited the web servers where non-existent domains are hosted, and figured out ways to inject scripts into vulnerable input forms on those hosts. Oh no, Mr. Bill! Can you see a phishing attack in your future, on a host you don't control? [Note: Dan's presentation on what he calls provider redirection was a catalyst for the SSAC work. Excellent work, Dan, and thank you.]

Another interesting question to toss into this still unfolding story is, "what's listening on ports other than HTTP/80 on these machines?". No one can say for certain since no one's studied all the redirect hosts. But imagine an error resolution for an incorrectly typed VOIP address/SIP number. Now imagine that an attacker redirects you to an offshore toll number. Fun in the sun...

SSAC's report is a preliminary one. There's much more to study here. Pull on your all weather gear, folks, this issue will undoubtedly cause quite a storm.

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


Wed, 11 Jun 2008 00:00:00 00, 693
What Comcast hijacking means to you

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.

ZIP of an Audio/MP3.

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


Fri, 30 May 2008 00:00:00 00, 692
Comcast.net hijacking - was it phished?

Comcast had its NET domain name hijacked Wednesday May 28th. 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  


Wed, 28 May 2008 00:00:00 00, 691
SSAC Advisory: Registrar Impersonation in Phishing Attacks

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  


Mon, 19 May 2008 00:00:00 00, 688
What's a domain registration worth?

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 US1. 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 per2.

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

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


Mon, 28 Apr 2008 00:00:00 00, 686
Securing the Internet's DNS

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  


Thu, 13 Mar 2008 00:00:00 00, 678
Hype-cycle management

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  


Tue, 11 Mar 2008 00:00:00 00, 675
Intereviewed by darkREADING

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  


Tue, 12 Feb 2008 00:00:00 00, 673
Quad A resource records in the root: if you want the full nine yards...

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  


Thu, 07 Feb 2008 00:00:00 00, 672
IPv6 addresses for the root name servers

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  


Tue, 05 Feb 2008 00:00:00 00, 670
Domain Name Front Running Report

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  


Mon, 28 Jan 2008 00:00:00 00, 669
Fast flux hosting and DNS

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  


Fri, 21 Dec 2007 00:00:00 00, 665
Top Ten Things to Consider When Registering a Domain Name At the request of Consumer Reports WebWatch, ICANN colleague Kieren McCarthy and I wrote a guide to help consumers understand how to register a domain name. Many readers of this blog are familiar with domain name registration, but even seasoned domainers can overlook seemingly small details that can frustrate efforts to find - and keep - an appropriate or desirable domain name. You can download a PDF of the guide from WebWatch.

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


Tue, 27 Nov 2007 00:00:00 00, 661
Chapter on DNS Security in IGF publication

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  


Wed, 21 Nov 2007 00:00:00 00, 660
A nice rebuttal to DNSSEC naysayers

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  


Tue, 30 Oct 2007 00:00:00 00, 657
Domain Name Front Running

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  


Thu, 25 Oct 2007 00:00:00 00, 656
Do spammers harvest email addresses using WHOIS services?

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  


Fri, 05 Oct 2007 00:00:00 00, 651
Survey of IPv6 Support Among Commercial Firewalls

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  


Thu, 04 Oct 2007 00:00:00 00, 652
Are Tasted Domain Names used in Phishing Attacks?

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  


Thu, 27 Sep 2007 00:00:00 00, 650
ICANN hits YouTube

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  


Tue, 11 Sep 2007 00:00:00 00, 645
If you knew where you wanted to go today, could you get there using IPv6?

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, 11th 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  


Sat, 11 Aug 2007 00:00:00 00, 638
Are Domain Names the fruit of the sea?

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  


Tue, 31 Jul 2007 00:00:00 00, 635
Fast Flux Chat on Radio Free Internet

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  


Tue, 24 Jul 2007 00:00:00 00, 632
Interesting paper on fast flux attacks

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  


Fri, 06 Jul 2007 00:00:00 00, 627
Lost and Found, Act II

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


Fri, 29 Jun 2007 00:00:00 00, 625
Is the WHOIS service used as a source for email addresses for spammers?

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  


Thu, 28 Jun 2007 00:00:00 00, 624
Dealing with parking pages when you anticipate HTTP/404

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  


Mon, 26 Mar 2007 00:00:00 00, 603
Adding AAAA RRs of root name servers to hints and root zone files

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  


Mon, 12 Feb 2007 00:00:00 00, 590
Testing Recursive Name Servers for IPv6 and EDNS0 Support

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  


Thu, 01 Feb 2007 00:00:00 00, 588
Version Grabbing

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  


Tue, 30 Jan 2007 00:00:00 00, 587
It’s Time For Enterprises To Take On DNS Security

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  


Fri, 05 Jan 2007 00:00:00 00, 580
Testing Firewalls for IPv6 and EDNS0 Support

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  


Tue, 19 Dec 2006 00:00:00 00, 575
Map of IPv4 address space and current allocation

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  


Fri, 08 Dec 2006 00:00:00 00, 574
Transcript available

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  


Tue, 28 Nov 2006 00:00:00 00, 571
Anatomy of a DNS DDoS Amplification Attack

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  


Mon, 13 Nov 2006 00:00:00 00, 568
Why Top Level Domains Should Not Use Wildcard Resource Records

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  


Wed, 01 Nov 2006 00:00:00 00, 564
Pearls from Vint Cerf's Opening Remarks at Internet Governance Forum

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  


Wed, 18 Oct 2006 00:00:00 00, 559
Information Gathering Using Domain Name Registration Records

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  


Fri, 15 Sep 2006 00:00:00 00, 554
Domain traffic monetization

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 3rd 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/10th 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  


Mon, 03 Jul 2006 00:00:00 00, 539
Worrisome Threat of DNS DDoS Attacks

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  


Thu, 29 Jun 2006 00:00:00 00, 538
Renewal Considerations for Domain Name Registrants

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  


Tue, 27 Jun 2006 00:00:00 00, 537
Why Legitimate Search Engines Should Hate PPC Landing Pages

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  


Mon, 26 Jun 2006 00:00:00 00, 536
SSAC Presentations from Marrakech Meeting

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  


Mon, 22 May 2006 00:00:00 00, 529
The Value of Privacy

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  


Tue, 18 Apr 2006 00:00:00 00, 520
Restricting DNS lookup of isolated names: Sabotage or Self-defense?

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  


Tue, 04 Apr 2006 00:00:00 00, 517
DNS DDoS Amplification Attacks

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  


Fri, 31 Mar 2006 00:00:00 00, 515
Domain Name Census Information?

Dennis Forbes has written and entertaining article describing the current distribution of domain registrations, based on 2nd 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  


Mon, 23 Jan 2006 00:00:00 00, 495
Domain name and IP address tools

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:

who is this domain?

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  


Fri, 06 Jan 2006 00:00:00 00, 489
DNS Pharming: Someone's poisoned the water hole!

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  


Fri, 16 Dec 2005 00:00:00 00, 482
"Multilingual Internet" has many dimensions

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 scripts in my email client or browser (and of course understand these languages). In some countries, many language scripts are used, so I might even need to understand how to read and type scripts of local dialects.

The problem of native and local language character representation has been solved in many operating systems and applications. Email and web, for example, use Multipurpose Internet Mail Extensions (MIME) to provide multilingual support for many languages and scripts. Unfortunately, the Domain Name System cannot easily accommodate national and local character sets for several reasons. Principal among these is that DNS labels must follow composition rules for ARPANET hostnames, and can only contain letters, digits, and hyphens (known as "LDH"). With this restriction, a tilde or umlaut used in certain New Latin scripts cannot be used in domain names, nor can any character or glyph of other known languages. Such languages require that domain names be represented to users in the Unicode Character Set.

Several problems exacerbate the problem. First, most Internet applications present - and expect users to submit - a domain name in the same representation (presentation syntax) as the DNS protocol uses as its "over the wire" (its *transfer* syntax). This is true even in MIME-enabled email: while you may be able to use the Spanish word baño or the Thai character ko kai (ก) in a message body or certain headers, you cannot do so in any host name part of an email address (you can probably confirm this by examining mail headers in certain spam messages you receive). Similarly, while you can place Unicode-encoded national language characters in a web page, you can't use them in a hyperlink.

A partial solution to this problem, generally referred to as Internationalized Domain Names (IDN), currently provides the ability to use national and local characters in all DNS labels other than the Top Level Domain (TLD) label (e.g., com, net, org, biz, info, and the "country code" TLDs). This solution is specified in RFC 3490, Internationalizing Domain Names in Applications (IDNA). IDNA describes how Internet applications can convert labels presented to users in Unicode characters to an "ASCII compatible encoding" that name servers can process (LDH), and how applications can convert a label from an ASCII-compatible-encoding into a native or local character string for presentation to an application user. (Interested readers should also consider two companion standards: RFC 3491, NamePrep and RFC 3492, Punycode).

IDNA is currently available for use in 2nd level labels in domain names registered through IDN-capable registries, under LDH-encoded top level domains. This means that a registrant can register cuartodebaño.com today; more generally, anyone can use any Unicode-encoded national or local character set in a 2nd level label, register that name under a generic TLD (com, biz, net...), have this resolve correctly by the authoritative DNS. ICANN provides guidelines governing the composition of such Internationalized Domain Names here. This document provides general label composition rules for registries, and in particular defines guidelines that try to thwart the deceptive use of visually confusable characters by would-be pharmers (at last, something security-related!). To appreciate this form of deception, consider the two domain names paypal.com and pаypаl.com. Visually, they appear identical; the first however uses the Roman small "a" and the second uses a Cyrillic (Russian) small "a" (Unicode hexidecimal 0430). ICANN's IDN guidelines prohibit the mixing of scripts in labels to prevent misuse by pharmers (Readers seeking a more detailed treatise on such practices should see Unicode Security Considerations).

Currently, ICANN's IDN-capable registries do not support national and local character sets in top level labels. This means that while a party can register cuartodebaño.com, the country of Spain could not use "españ" as friendlier alternative to the two letter country code "es", nor can countries use national and local scripts. This may seem a trivial matter until you consider that LDH glyphs are not universally recognized and not easily typed into certain keyboards, that some scripts are not written left-to-right, and that everyone should have the opportunity to use the Internet to communicate in languages they share, using the characters normally used to write and print those languages (see RFC 4185).

ICANN and the Internet community at large will consider two technical solutions for incorporating national and local characters in TLDs. The first attempts to apply the IDNA standards in the TLD; the second attempts to provide DNAME equivalence mappings for TLD strings.

Variants of the IDNA technique are currently used by "breakaway" root name services and registries to support TLD labels in several national characters and scripts. While these initiatives are providing native language TLDs today for the constituencies that subscribe to them, they have the undesirable effect of fracturing the single authoritative root name service: TLD labels registered in these languages are not resolved by the authoritative root name service but rather the "local root name service" operated by (or on behalf of) a country or constituency.

"Breakaway" root name services solve an immediate and localized need by adopting and deploying IDN technology in advance of international guidelines developed through a consensus-building process. Anyone who's built one of anything will agree that this is a much smaller set of problems to solve than the set facing ICANN and the Internet community at large. We must assure that domain names can be resolved consistently and correctly irrespective of characters used in name composition and geographic location. Breakaway root name services sidestep the challenging problems. To date, they don't attempt to solve multinational multilingual issues but instead spin off multiple root name services instead. The minor matters they choose not to solve include how to maintain cooperation among

  • nations (North and South Korea are .kp and .kr respectively, but who decides what characters are used to globally represent "Korea" at the TLD label, who decides which scripts are used for generic TLDs, and how to handle duplicates?),

  • among constituencies within nations (Sunnis, Shiites and Muslim tribes must agree on language preferences at *some* level), and

  • between nations and private interests (coordinating and preserving intellectual property and protecting branding through registration processes) to establish globally acceptable guidelines.

Some attempt has been made to recognize multiple official languages and scripts, but the "policy" test case for this problem will be a country like India, which has twenty two official languages, 325 local dialects and numerous scripts.

It's somewhat promising that most interested parties attending the IDN workshops prior to and during the Vancouver ICANN meeting appear to be moving past whining and posturing over the injustice of the "IDN.ascii" (the pejorative acronym used to illustrate that TLDs are still restricted to LDH encoding) and appear to be looking for global answers.

While boning up on IDNs, I tried to surf the web using one of the IDN-capable breakaway root name services. (I had to learn some Cyrillic to complete one of my first programming assignments, a Cyrillic keyboard interface to a Burroughs L-series minicomputer). It wasn't long before I became frustrated at how hard it was to surf using unfamiliar languages and scripts. I can imagine how trying my Internet experience would be if this were a 24x7 circumstance. I can see how tempting a quick fix like a breakaway root name service might seem. Hopefully, these are interim solutions that do no permanent harm, and that a globally palatable alternative is identified soon.

Archived at http://www.securityskeptic.com/arc20051201.htm#BlogID482 by Dave Piscitello  


Sat, 10 Dec 2005 00:00:00 00, 480
Examples of Links that Lie

Michael Horowitz put a nice discussion of four of the most popular forms of trickery phishers use to lure victims to a fraudulent site, commonly to steal some identity or financial information. Michael's categorizes avenues of trickery as (1) technical tricks with the link, (2) exploitable browser vulnerabilities (bugs), (3) domain name deception, and (4) DNS poisoning.

Michael's Examples of Links that Lie is a worthwhile read for everyday users and practicing professionals as well. I'll add this to my Phishing and Fraud Prevention resources page shortly.

One method of deception Michael doesn't cover is the use of Unicode encoded characters that are visually similar to common Romance (New Latin) characters in domain names. The classic example of such visual deception is the use of a Cyrillic lower case "a" (unicode hex 0430) for a Roman character "a" in the domain name paypal.com. You can read about this and other visual security issues related to Unicode in Unicode Technical Report #36.

Archived at http://www.securityskeptic.com/arc20051201.htm#BlogID480 by Dave Piscitello  


Wed, 30 Nov 2005 00:00:00 00, 477
DNSsec: the new whipping post

DNSsec is the latest Internet security protocol to encounter resistance to early adoption and deployment. Like WLAN security, remote access VPNs, secure email, multi-factor authentication and, well, *every* security measure introduced in recent memory, reaction from network operators and administrators always begins with the same five sentence mantra:

  • It's too hard (encryption and signing and keys, oh my!)
  • It's too expensive (how will we pay for more hardware, new software, encryption accelerators...?)
  • It hurts performance (our CPUs can barely contend with DOS attacks today, the added load of encryption processing puts us in mortal peril!)
  • No one's asking for it (honest, we asked all our customers and users).
  • It doesn't solve every problem (No confidentiality, no DOS protection)

Sometimes I wonder if there's a "impede security deployment" template available on the web. Download the template, insert the security protocol you don't understand, don't want to learn, and don't want to invest time and resources to implement, and repeat the five sentence mantra loudly and often. With any luck, you'll attract media attention, spread F.U.D., and add a year to the adoption time line.

The (ahem) silver lining in this strategy is that a yearlong delay in adopting a much-needed security measure often results in enough security incidents to attract media attention, spread F.U.D, and create the market demand.

I expressed some of these frustrations today among colleagues between sessions at the ICANN meeting, and several offered a friendly, "Get over it...". I suppose I should, and simply wait. Katrina is an all too recent reminder that it's always easier to find funding for levees after category 4 hurricanes.

Archived at http://www.securityskeptic.com/arc20051101.htm#BlogID477 by Dave Piscitello  


Fri, 09 Sep 2005 00:00:00 00, 452
Recommended reading: The Pharming Guide

Gunter Ollman has compiled a guide to Pharming attacks that is worth a look. The Pharming Guide begins with a thorough consideration of DNS and name (host) resolution services. This chapter sets the table for a thoughtful classification and careful examination of Pharming attack vectors and methods attackers use. Gunter describes a wide range of attacks, including:

  • How rogue DHCP and Web Proxy servers can be used to redirect hosts on LANs and WLANs to an attacker's DNS server.
  • Domain hijacking, similar domain name ("one letter off"), and Botnet name server registration attacks.
  • Attacks against vulnerable DNS server configurations and DNS servers that are not current with critical patches and hot fixes.
  • DNS spoofing attacks, including DNS cache poisoning, DNS ID spoofing, and the Birthday attack.
  • Attacks against autoresolvers and search engines (e.g., page rank escalation).

If you weren't aware that there were so many types of DNS attacks, you should at least look at this chapter.

The paper concludes with a list of countermeasures and defenses IT staff can implement to minimize an organization's exposure to DNS attacks. Gunter's companion paper, Security Best Practice - Host Naming and URL Conventions, offers additional security measures organizations can consider when choosing and adding domain names and when establishing an organization's URL composition strategy.

Enjoy.

Archived at http://www.securityskeptic.com/arc20050901.htm#BlogID452 by Dave Piscitello  


Thu, 25 Aug 2005 00:00:00 00, 447
Why You Need To Add “Protect Domain Name” To The Security Checklist

Domain name hijacking broadly refers to acts where a registered domain name is misused or stolen from the rightful name holder. A domain hijacking is a security risk many organizations overlook when they develop security policy and business continuity plans. While name holders can take measures to protect their domain names against theft and loss, many measures are not generally known. More...

Archived at http://www.securityskeptic.com/arc20050801.htm#BlogID447 by Dave Piscitello  


Wed, 17 Aug 2005 00:00:00 00, 445
Can a simple password stop domain name hijacking?

Tom's Hardware ran an article on the Domain Name Hijacking report SSAC presented to ICANN last month. Colleague Dan Halloran and I were both interviewed. To read the full column, visit http://www.tomshardware.com/hardnews/20050817_141236.html.

Archived at http://www.securityskeptic.com/arc20050801.htm#BlogID445 by Dave Piscitello  


Fri, 15 Jul 2005 00:00:00 00, 431
Alternate Roots?

The Domain Name System is based on the design assumption of a single root. This is one of the fundamental principles you learn in Internet 101. Some people aren't happy with this design assumption. Others are unhappy that they aren't in a position to profit by root server operation. Some want to forego convention and roll out Top Level Domains however they please. Still others object to the US DoC retaining oversight. These constituencies all conclude that the Internet needs alternative roots.

None of these are valid reasons to deploy alternate roots. If you want to experiment with a new name service architecture, fine, but you don't ignore a fundamental design assumption and expect the system to scale and remain stable.

If you think there's a pot of gold in alternate roots and non-standard TLDs, submit your business model to an investment firm. Pray they don't engage a consultant to investigate your technology and service as part of their due diligence. Even if they don't hire a consultant, all they'll need to do is read the tutorial page on using alternate roots at the Simple DNS Plus. (I imagine they added this information to reduce helpdesk calls from administrators who use their software to support non-standard DNS operating environments.) Even the least technical investor group will recognize a pig in a poke when they read:

"Alternate root" domain names are not recognized by ICANN, which means that the majority of Internet users will not have access to any site you host under one of these domain names.

"If you register a domain name with an alternate root operator there is a risk that ICANN will eventually commission the same top level name, and you may have to register the domain again or lose it to someone else."

Whine until you're hoarse about oversight, but not to me: I think there are only a handful of folks who understand all the fine points and issues, and I won't pretend to be one of them.

"Alternate roots" is not merely A Very Bad Idea, but a broken one. If you want more enteraining and insightful perspectives on why, read Paul Vixie CircleID article entitled Putting Multiple Root Nameserver Issue to Rest.

Archived at http://www.securityskeptic.com/arc20050701.htm#BlogID431 by Dave Piscitello  


Wed, 13 Jul 2005 00:00:00 00, 428
More handy Firefox plug-ins

I find I'm using Whois service more frequently in my new position at ICANN. Paul Smith has written a Whois Lookup plug-in for Firefox that displays Whois information for the current URL in a new tab. The only shortcoming of the current version (Whois Lookup .01) is that the author chose a hotkey (W) that Firefox uses to close the current active tab window.

The FraudEliminator Toolbar, freeware version, also displays Whois responses when hover over an icon. I'm investigating the anti-phishing features of this toolbar. This toolbar is also available for IE.

Yes, I shudder when I use the word "toolbar" these days, but FraudEliminator LLC assures visitors they are spyware-free and both the privacy policy and EULA emphasize they do not collect information or popup advertising. The exception to their advertising claim is that they encourage you to purchase the professional version, which is forgivable. I just wish they didn't do it at the top of the whois response pane.

Archived at http://www.securityskeptic.com/arc20050701.htm#BlogID428 by Dave Piscitello  


Tue, 12 Jul 2005 00:00:00 00, 427
Domain Name Hijacking Report

During my first weeks at ICANN, I have been investigating domain hijacking with the Security and Stability Advisory Committee (SSAC). Formally, domain hijacking is the wrongful transfer of a domain name from a rightful name holder ("registrant"), but many incidents involving attacks on DNS configurations and registrant impersonation are labeled domain hijacks as well.

I've prepared a report on behalf of and with the extensive input and support from SSAC and ICANN staff. The Domain Name Hijacking Report was commissioned in response to both highly publicized hijacking events and a number of lesser publicized events. The SSAC found that domain name hijacking incidents are commonly the result of flaws in registration and related processes, failure to comply with the transfer policy and poor administration of domain names. The report recommends ten key actions including implementation of improved auditing and compliance measures, and additional measures to protect registration information from misuse by would-be hijackers, as well as implementation of emergency procedures to assist in the urgent restoration of a domain name.

You can find the report at ICANN at http://www.icann.org/announcements/hijacking-report-12jul05.pdf.

Archived at http://www.securityskeptic.com/arc20050701.htm#BlogID427 by Dave Piscitello