The Security Skeptic

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

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

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

The advisory can be downloaded here.

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

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

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

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

A recent post to an anti-phishing mailing list identified this clever and evil attack against domain name registrants. The attack exploits domain name renewal notice emails that registrars send to registrants. The attack uses similar social engineering and deception techniques as those used in identity theft and other phishing attacks. From the post...

"Phishing attacks against registrars allow for take-over of legitimate domain management accounts for use in future ROCK attacks - either through control of existing legitimate domains or via registration of new ROCK domains on an account that the registrar "trusts" since it's been used for valid purposes over a long period of time. With a domain take-over, you can reconfigure DNS to still work for the "real" site, while wild-carding all other host names - much the same way the ROCK group already operates, so take-down will be slowed considerably since the domain itself can't be deleted."

If I interpret this post correctly, the attacker (in this case, the notorious ROCK phishing group) proceeds as follows:

1. Use the WHOIS service to obtain the registrant's email contact information *and* the registrar for a domain name(s).

2. Set up a bogus registrar phishing site

3. Compose a renewal email that appears to be from the registrar and send this to the email contacts for the domain name(s).

4. Wait for registrants to fall prey to the deception.

5. When the registrant visits the bogus registrar web site, collect the registrant's account credentials via a bogus login page.

6. Use the collected account credentials to alter the registration record, i.e., to hijack the domain name or name service.

7. Use the domain name for illegal activities.

Once the attacker has control of the domain, he can attempt all sorts of illegal activities. The attacker can launch an attack against the domain itself (he controls the name service!); as colleague Danny McPherson of Arbor Networks points out, he can proxy or create a deception site at that domain name, insert an iframe, incorporate a BHO or other malware download to infect a visitor's PC. Or he can use the hijacked domains to facilitate fast flux attacks.

To conceal the illegal activities, the attacker will add records to the domain's legitimate zone file rather than replace the zone entirely to improve the odds that the hijacking may not be discovered quickly. This form of domain hijacking allows fast flux attackers to conceal the location of their illegal web sites even longer than before, and complicates takedown procedures that first responders and law enforcement might initiate because the domain name is not only used to abet phishing but to support the real business needs of the registrant that fell victim to the phishing attack and is thus not easily deleted from the TLD zone file.

It turns out that several of my domains are up for renewal. You can be certain that I paid close attention to each renewal email from my registrar and followed the widely recommended "safe practices" when opening and reading email. Read my Anti-Phishing page f and visit the Anti-Phishing Working Group or more information

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

Live Chat is all the rage. "Speak" with a customer care representative directly from your PC via a Web application. How cool is that?

Those who know me know I am an infrequent and mostly reluctant phone user, so the notion that I can instant message rather than speak with call center personnel is enormously appealing. Unfortunately, I'm encountering more and more situations where Live Chat is really "live hold". The chat threads proceed as follows:

Hello this is Dorkas. I'm your customer care representative, how can I help you today?

I'd like to add a service to my cellular telephone, please."

...

??????????

...

Are you still there?

(At this point I check to see if I still have network connectivity, if I am still connected to the web site, and if my Java console is complaining... )

H E L L O ?

...

TYVMFWMT

(Thank you very much for wasting my time)

I take comfort that I get to choose the "on hold" music from iTunes. After 20 minutes, I close the popup window and call customer care.

sigh...

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

While reviewing my web logs today, two patterns emerged: the incidence of referrer spam in my logs is increasing and I'm getting a fair number of visitors from the University of California, San Francisco School of Pharmacy. I'm not sure I want to invest a lot of time thwarting lame-ohs from spamming my logs since they'll only be replaced by some other lame-ohs. My curiosity, however, did lead me to track back to the referrer site at UCSF.

The School of Pharmacy devotes several pages to educating users on how to choose a password. This tutorial includes a page that provides examples of bad passwords, and a page I host at The Security Skeptic is linked as an example resource containing a High Probability Password List.

Kudos to UCSF SoP for the effort. I'm always happy to see a resource I post put to good use:-)

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

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

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

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

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

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

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

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

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

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

• ARIN XX meeting 19 October 2007

• ICSA Laboratories Firewall Consortium meeting 25 October 2007

• ICANN SSAC Public Forum , 29 October 2007

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

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

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

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

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