Domain Theft and the Possibilities for Recovery


On October 24th 2012, Diigo, a social bookmarking website allowing signed-up users to bookmark and tag web pages, had its domain,, stolen by a domain name thief. . As a result, Diigo’s more than 5 million registered users were not able to access the website.

Domain theft, also known as domain name hijacking, is not a new phenomenon. Back in 2005, the ICANN’s Security, Stability and Advisory Committee (SSAC) issued a Domain Hijacking report outlining several incidents of domain theft. The report defines domain name hijacking as “wrongful taking of control of a domain name from the rightful name holder.”

The present contribution describes the types of domain thefts (Section 2) and explains the possibilities for recovery of stolen domain names (Section 3). Finally, a conclusion is drawn (Section 4).

Types of domain theft

The Domain Hijacking report differentiates five basic types of domain theft, namely: impersonation of a domain name registrant in correspondence with a domain name registrar (Subsection 2.1); forgery of a registrant’s account information maintained by a registrar (Subsection 2.2), forgery of a transfer authorization communication from a registrant to a registrar (Subsection 2.3); impersonation or a fraudulent act that leads to the unauthorized transfer of a domain from a rightful name holder to another party (Subsection 2.4), and unauthorized DNS configuration changes that disrupt or damage services operated under a domain name (Subsection 2.5).

Impersonation of a domain name registrant in correspondence with a domain name registrar

This type of domain theft includes using forged fax or postal mail requests to modify registrant information. In some cases, stolen or copied company letterheads may be also used.

The incident is a typical example of impersonation of a domain name registrant. Hushmail was launched in 1999 by Hush Communications. In April 2005, a domain name thief convinced the support staff of Network Solutions, Inc. to modify the administrative email contact information in Hush Communications’ registration record. Then, the attacker used the administrative contact email to submit a password reset request for the Hush Communications account to Network Solutions, Inc. Afterwards, the attacker logged into the Hush Communications account, changed the password, and altered the DNS configuration to point the domain name to his own server. At the end, the thief posted a new home page demonstrating his achievement and embarrassing Hush Communications.

Forgery of a registrant’s account information maintained by a registrar

Domain name thieves may forge the account information associated with a domain name registration to conduct malicious activities, such as reselling the domain. For instance, the forged information may be used by a thief to deceive a buyer that the thief is the actual owner of the domain name.

Forgery of a transfer authorization communication from a registrant to a registrar

This type of domain theft includes acts where the domain name thief submits a fake transfer authorization communication to the registrar. The communication appears to be sent by the registrant, which would allow the thief to take control over the domain name.

For example, in the U.S. case Kremen v Cohen 2001, the California District Court found that the defendant fraudulently obtained the registration of the domain name by sending a forged letter to Network Solutions, Inc., the domain registrar. As a result, the court awarded $65 million for damages resulting from the fraud.
The court justified the award by stating that, in the five years the defendant operated the “” website, he reaped profits amounting to more than 40 million dollars. The damage award also included $25 million in punitive damages.

2.4 Impersonation or a fraudulent act that leads to the unauthorized transfer of a domain name from a rightful name holder to another party

This type of domain name theft includes actions that may or not may lead to changes in the DNS configuration. If the theft does not lead to changes in the DNS configuration, it could remain undetected for a considerable period of time. In this case, the motive of the thief is not to immediately disrupt the domain holder’s operation, but to acquire and resell the domain name.

An example of such a theft is the and incident. Both domain names were previously registered and managed by a U.S. company and registered through Go Daddy Operating Company, LLC. Suddenly, an unidentified and unauthorized person used the name and the password of the company manager to log into his account and transfer the Domain names to another Registrant and Registrar (OnlineNIC, Inc.). In this incident, no changes had been made to the DNS configuration, and the services of the two domain names had not been affected.

The manager of the company submitted a Uniform Domain Name Dispute Resolution Policy (UDRP) claim to the online ADR Center of the Czech Arbitration Court requesting the transfer of the domain names to his company. UDRP is an administrative procedure allowing trademark holders to submit complaints to ICANN-accredited dispute resolution providers for disputes involving domain names that have been registered by an ICANN-accredited registrar. On November 21, 2012, a panelist of the Czech Arbitration Court delivered a decision transferring the domain names to the manager of the company.

Unauthorized DNS configuration changes that disrupt or damage services operated under a domain name

Unauthorized DNS configuration changes can be a result of DNS spoofing attacks (also known as DNS cache poisoning). In this kind of attack, data is introduced into a Domain Name System (DNS) name server’s cache database that results in the domain name server returning an incorrect IP address, diverting traffic to another computer (often the computer of the domain name thief). A typical example of DNS spoofing occurred in 1997 when Eugene Kashpureff redirected users attempting to connect to the InterNIC website to his own website.

Possibilities for recovery of stolen domain names

At present, victims of domain name theft can re-take control of the stolen domain names through dispute resolution procedures (Subsection 3.1). In addition, ICANN also considers the use of an emergency action channel (Subsection 3.2) between registrars that will be used in cases where an urgent response is required.

Dispute Resolution Procedures

The Uniform Domain Name Dispute Resolution Policy (UDRP) and the Transfer Dispute Resolution Policy (TDRP) established by ICANN are designed to impartially assess the factual circumstances of the case with the aim of determining the appropriate outcome of a dispute.

The Uniform Domain Name Dispute Resolution Policy (UDRP)

The Uniform Domain Name Dispute Resolution Policy (UDRP) is an effective means for recovery of stolen domain names. The total cost of UDRP (including attorney’s expenses) may vary between $1,000 and $2,000. The procedure will take at least two months to reach a decision. In order to succeed in a UDRP proceeding, a complainant must establish three elements: (1) the domain name is identical or confusingly similar to a trademark or service mark in which the complainant has rights; (2) the registrant does not have any rights or legitimate interests in the domain name; and (3) the registrant registered the domain name and is using it in “bad faith.”
A party who lost the proceedings may file a lawsuit in a national court against the domain name registrant.

In order to establish whether a domain name has been registered in “bad faith,” the UDRP panel will examine several factors, such as (1) whether the registrant registered the domain name with the aim of selling the domain name registration to the complainant, (2) whether the registrant registered the domain name to prevent the owner of the trademark or service mark from using the mark corresponding to his name, (3) whether the registrant registered the domain name primarily to disrupt the business of a competitor, and (4) whether the registrant tried to attract visitors by creating a likelihood of confusion with the complainant’s mark.

The Transfer Dispute Resolution Policy (TDRP)

The Transfer Dispute Resolution Policy (TDRP) is used for resolving disputes between two registrars engaging in Inter-Registrar domain name transfers. A TDRP dispute can be brought to the registry for a decision, or to a third-party dispute resolution service provider. In case that a registry operator is chosen, the decision of this registry operator may be appealed by the registrars to an independent dispute resolution provider. A decision made by an independent dispute resolution provider may be appealed only before a court.

3.2 Emergency action channel

The emergency action channel will provide 24/ 7 access to registrar technical support staff who are authorized to assess the situation and establish the magnitude and immediacy of harm. They are also entitled to take measures to restore registration records and DNS configuration to “the last working configuration.”

The emergency action channel will be supported by a contact directory of parties who can be reached during non-business hours and weekends and a companion policy. The companion policy will identify evaluation criteria (including circumstances and evidence) that a registrant must provide in order to obtain an immediate recovery of the domain.

The following circumstances will be taken into account when distinguishing when an urgent recovery policy may be a more appropriate action than the TDRP: (1) immediacy of the harm, (2) the magnitude of the harm, and (3) escalating impact.


This article has shown that domain name theft is a serious issue that can lead to the loss of the domain name and the interruption of services operating under it. It has also shown that domain name theft is a broad term that encompasses several acts of wrongful takeover of a domain name. While domain name thefts that interrupt services will probably be immediately noticed by the legitimate domain name holders, those that do not lead to changes in the DNS configuration may remain unnoticed for a long period of time.

At present, the people/organizations whose domains were stolen may rely mainly on the dispute resolution procedures established by ICANN and on the use of litigation. The UDRP and TDRP procedures are relatively quick and cheap (compared to litigation). However, it should be noted that many victims of a domain name theft may not be able to pay the dispute resolution fees. This is especially true for people in developing countries for which a dispute resolution fee of $2,000 could be equal to their annual salary.

In order to prevent thefts of domain names, companies and individuals may take the following four preventive measures. First, they should not use Hotmail, Gmail, or other free email services as the contact email on the domains. Because free email services have many security vulnerabilities, thieves often hack them and authorize a transfer. Second, companies and individuals need to create as secure a password as possible at their registrar. The use of a completely random password containing upper and lower-case letters and numbers is desirable. Third, in order to ensure the best protection of their domain name, companies and individuals are advised to use a trusted registrar. The well-known registrars provide adequate security precautions. Lastly, when selling domain names, it is advisable to use escrow services. Using an escrow service is a good way to prevent fraud schemes.

Daniel Dimov is a security researcher for InfoSec Institute. InfoSec Institute is a security certification company that has trained over 15,000 people including popular CEH and CCNA certification courses.


Notes for Linux Basix Eps019

The below post is just a quick writeup that can be serve as an addition to the show notes for my segment on the Linux Basix podcast.

Discussion Links:

  1. Gmail made you look like a spammer this week –>  Graham Cluley’s blog Over 4 million Gmail users had their email messages being sent multiple times. “At least if your home or business computer was spewing out spam you can pull the cable out of the back of your PC. With web base services like Gmail you dont have that option”
  2. and–> Great blogs for learning the commandline, keep reading and you will be a command line Ninja one day.
  3.–> Tons of interesting plug-ins for you to have fun with.
  4. –> 20 Linux System Monitoring Tools Every SysAdmin Should Know, with over 143 comments a **Must Read**.

Installing OpenSSH 5.6

Now in keeping with my theme of always keeping your software update, I notice that a new version of OpenSSH was released on August 24th. Why update you might as?

List of features that my change your mind:

Changes since OpenSSH 5.5

* Added a ControlPersist option to ssh_config(5) that automatically
starts a background ssh(1) multiplex master when connecting. This
connection can stay alive indefinitely, or can be set to
automatically close after a user-specified duration of inactivity.

* Hostbased authentication may now use certificate host keys. CA keys
must be specified in a known_hosts file using the @cert-authority
marker as described in sshd(8).

* ssh-keygen(1) now supports signing certificate using a CA key that
has been stored in a PKCS#11 token.

* ssh(1) will now log the hostname and address that we connected to at
LogLevel=verbose after authentication is successful to mitigate
“phishing” attacks by servers with trusted keys that accept
authentication silently and automatically before presenting fake
password/passphrase prompts.

Note that, for such an attack to be successful, the user must have
disabled StrictHostKeyChecking (enabled by default) or an attacker
must have access to a trusted host key for the destination server.

* Expand %h to the hostname in ssh_config Hostname options. While this
sounds useless, it is actually handy for working with unqualified

Host *.*
Hostname %h
Host *

* Allow ssh-keygen(1) to import (-i) and export (-e) of PEM and PKCS#8
keys in addition to RFC4716 (SSH.COM) encodings via a new -m option

* sshd(8) will now queue debug messages for bad ownership or
permissions on the user’s keyfiles encountered during authentication
and will send them after authentication has successfully completed.
These messages may be viewed in ssh(1) at LogLevel=debug or higher.

* ssh(1) connection multiplexing now supports remote forwarding with
dynamic port allocation and can report the allocated port back to
the user:

LPORT=`ssh -S muxsocket -R0:localhost:25 -O forward somehost`

* sshd(8) now supports indirection in matching of principal names
listed in certificates. By default, if a certificate has an
embedded principals list then the username on the server must match
one of the names in the list for it to be accepted for

sshd(8) now has a new AuthorizedPrincipalsFile option to specify a
file containing a list of names that may be accepted in place of the
username when authorizing a certificate trusted via the
sshd_config(5) TrustedCAKeys option. Similarly, authentication
using a CA trusted in ~/.ssh/authorized_keys now accepts a
principals=”name1[,name2,…]” to specify a list of permitted names.

If either option is absent, the current behaviour of requiring the
username to appear in principals continues to apply. These options
are useful for role accounts, disjoint account namespaces and
“user@realm”-style naming policies in certificates.

* Additional sshd_config(5) options are now valid inside Match blocks:


* Revised the format of certificate keys. The new format, identified as
ssh-{dss,rsa} includes the following changes:

– Adding a serial number field. This may be specified by the CA at
the time of certificate signing.

– Moving the nonce field to the beginning of the certificate where
it can better protect against chosen-prefix attacks on the
signature hash (currently infeasible against the SHA1 hash used)

– Renaming the “constraints” field to “critical options”

– Addng a new non-critical “extensions” field. The “permit-*”
options are now extensions, rather than critical options to
permit non-OpenSSH implementation of this key format to degrade
gracefully when encountering keys with options they do not

The older format is still supported for authentication and may still
be used when signing certificates (use “ssh-keygen -t v00 …”).
The v00 format, introduced in OpenSSH 5.4, will be supported for at
least one year from this release, after which it will be deprecated
and removed.

Install time…

I am attempting to install this on a headless Ubuntu server the first command I am going to try is:

# sudo apt-get install openssh-server openssh-client

Now since this was a recent release your average apt-get install command wouldn’t work here because it takes some time for the many repository to be populated with the new versions.

Obtaining your copy…

Just do a quick wget



You will need working installations of Zlib and OpenSSL.

Zlib 1.1.4 or or greater (earlier 1.2.x versions have problems):

OpenSSL 0.9.6 or greater:

Building / Installation
To install OpenSSH with default options:

make install

While I was waiting with excitement for my new app to build and install I keep getting the following error “configure: error: *** OpenSSL headers missing – please install first or check config.log ***”

Decided to upgrade to version Ubuntu 10.04

  1. Install update-manager-core if it is not already installed:
    sudo apt-get install update-manager-core
  2. Follow the on-screen instructions.
  3. sudo do-release-upgrade
  4. edit /etc/update-manager/release-upgrades and set Prompt=normal
  5. Launch the upgrade tool:

Only to realize that the fix was to install the libssl-dev package

apt-get install libssl-dev

Other useful commands I used:

uname -a –> Print basic information currently available from the system (Kernel version and so on)

ssh -v –> Shows you ssh version number

cat /etc/issue –> Shows you your Ubuntu build version

openssh version –> Shows you your openssh version number

Lastly you can take a read of my posting on the DLL hijacking issue if you haven’t been following it.


Linux Basix Security Tips Part 1

A while back I hinted to the wonderful guys over at that I would like to appear on the show and do a segment on Linux security, the agreed and below are some of the notes that can be used to follow alone with my segment.

Disclaimer: I am by no means a Linux security expert; I am just trying to bring some visibility to a topic that I believe all new users should think about.

Taken from the Linux basix website, our goal here is to bring together information that will make your introduction to Linux and Open Source Software more enjoyable and productive. As we go along we will be constantly updating this site with our shows and show notes. If you have any questions please post comments to the shows and blog. Feel free to let us know what you think of the show and we will do our best to make it make as much sense as possible. Once the forum is up and running it will be a source to find answers, tips and tricks to make computing more enjoyable.

The goal of my segment is not to touch on anything too advance, for that you can find several Linux hardening guide by CERT, NSA, and many more resources out there. Instead I will be focusing on giving a few tips that anyone new to Linux should keep in mind before connecting their server/workstation to the internet.

I would like to start by sharing a few sentences I found in a blog posting over at computer world;

“You see Windows was designed as a single-user, non-networked operating system. That design is still at the heart of Windows, which is why security must always be an add-on to Windows. Linux, in contrast, was built from the ground up as a multi-user, networked system. Linux, like Unix, which came before it, was constructed to work in a world with hostile users.”

Physical Security ( might seem silly but this should always be considered)

Configure the BIOS to disable booting from CDs/DVDs, external devices, and set a password to protect these settings, you can also go another step by encrypting your entire drive. Next, set a password for the GRUB bootloader.

  • Generate a password hash using the command  /usr/sbin/grub-md5-crypt.
  • Add the hash to the first line of /boot/grub/menu.lst as follows: password –md5 passwordhash

Minimum install as possible

Take a moment to think about your installation, I understand you might not know exactly what you want but don’t install everything at first. Just do the basics and as you learn more you can then install those additional application and do it properly. Also remove unnecessary packages, only keep the ones you need, and lastly remove any accounts that are not needed.

# yum list installed
# yum list packageName
# yum remove packageName


# dpkg –list
# dpkg –info packageName
# apt-get remove packageName

Stay away form clear text protocols

Under no circumstances do you want to use any clear text protocol. Any of the following  protocols or programs   (telnet, rsh, rlogin, FTP, TFTP) can give out your username/password to anyone on your local network with a packet sniffer. If you are hosting a website or providing users with a login portal ensure that you are not using http, but instead https even if you have to generate your own certificate.

Identify all open ports and services

Its important to know what ports you have open and what services are associated to them this way you can decide if you would like to block or filter them with a firewall. This is also important so in the event you notice a new port open you already have a baseline to compare it too.

To do you can use a tool like  Nmap (“Network Mapper”) which is a free and open source (license) utility for network exploration or security auditing. Many systems and network administrators also find it useful for tasks such as network inventory, managing service upgrade schedules, and monitoring host or service uptime.

ex nmap -A -sV

You can also use the following for identifying and turning off unwanted services:

To view all services that are turned on:
# chkconfig --list | grep '3:on'

To disable a service:

# service serviceName stop
# chkconfig serviceName off

Security software

  • Install Antivirus software, I am aware that Linux is not highly prone to viruses like your average Windows PC, but don’t for a moment think that Linux is not being successfully exploited in the wild every day. You want to ensure that you are not the “Low Hanging Fruit” in short don’t be the easy target.
  • Install/configure firewall (SELinux, IP Tables, and AppArmor) and take a moment to read how to configure it.

Keep Your Software Up to Date

  • Configure your system to update via your software repository and apply then automatically. Security updates should be applied as soon as possible.
  • Create the file apt.cron, make it executable, place it in /etc/cron.daily or /etc/cron.weekly, and ensure that it reads as follows:

/usr/bin/apt-get update
Or aptitude –s safe-upgrade

Password policy

  • You want to insure that you have a proper password policy, first identify any user accounts that has an empty password and set on or remove the account.
  • Setup password aging, its important to keep rotating your password a minimum every 60 days.
  • Set up some sort of password lockout policy, if someone attempts a brute force attempt you need to at least slow them down, a standard practice is to lockout an account after 3 failed login attempts.To get password expiration information, enter:
    chage -l userName

    To see failed login attempts, enter:

    To unlock an account after login failures, run:
    faillog -r -u userName

    Note you can use passwd command to lock and unlock accounts:
    # lock account
    passwd -l userName

    # unlock account
    passwd -u userName

    Identify empty passwords type the following command
    # awk -F: ‘($2 == “”) {print}’ /etc/shadow

Make Sure No Non-Root Accounts Have UID Set To 0

Only root account have UID 0 with full permissions to access the system. Type the following command to display all accounts with UID set to 0:

# awk -F: '($3 == "0") {print}' /etc/passwd

You should only see one line as follows:

If you see other lines, delete them or make sure other accounts are authorized by you to use UID 0.

File and file system security

SUID and SGID files on your system are a potential security risk, and should be monitored closely. Because these programs grant special privileges to the user who is executing them, it is necessary to ensure that insecure programs are not installed. A favorite trick of crackers is to exploit SUID-root programs, then leave a SUID program as a back door to get in the next time, even if the original hole is plugged.

  • Find all SUID/SGID programs on your system, and keep track of what they are, so you are aware of any changes which could indicate a potential intruder. Use the following command to find all SUID/SGID programs on your system:

root# find  / -type  f ( -perm -04000 -o -perm -02000 )

World-writable files, particularly system files, can be a security hole if a cracker gains access to your system and modifies them. Additionally, world-writable directories are dangerous, since they allow a cracker to add or delete files as he wishes. (can upload malware to a site and infect visitors)

To locate all world-writable files on your system, use the following command:

find / -xdev -type d ( -perm -0002 -a ! -perm -1000 ) -print

Secure ssh remote access

  • Disable root login via ssh, if someone is going to try and brute force your ssh server the first user name the will try will be root, so ensure that you do not allow ssh login for your root user. You can verify or edit this but changing the config file in:

vi /etc/ssh/sshd_config

Find this section in the file, containing the line with “PermitRootLogin” in it.

#LoginGraceTime 2m
#PermitRootLogin no
#StrictModes yes
#MaxAuthTries 6

Then restart your SSH service with sudo /etc/init.d/sshd restart

Noowner Files

Files not owned by any user or group can pose a security problem. Just find them with the following command which do not belong to a valid user and a valid group.

find /dir -xdev ( -nouser -o -nogroup ) -print

Keeping an eye on your logs:

You should configure logging and auditing so you can keep an eye on any type of  attacks that are launched against your system. You can manually check the following logs or use a tool like logwatch or logcheck or any number of log parsers out there. Logs of interest are :

  • /var/log/syslog
  • /var/log/faillog
  • /var/log/auth
  • /var/log/lastlog
  • /var/log/messages
  • /var/log/apahe2/access.log and error.log

When all else fail, here are some useful Scripts and tools you can use:

Lynis: Lynis is an auditing tool for Unix (specialists). It scans the system and available software, to detect security issues. Beside security related information it will also scan for general system information, installed packages and configuration mistakes.

Security audit tool,is a security tool that can be used both as a security audit as well as a part of an intrusion detection system. It consists of set of tests, library and textual/graphical front-end. Tests are sorted into groups and security levels. Administrators can run selected tests, groups or whole security levels.

The Bastille Hardening program “locks down” an operating system, proactively configuring the system for increased security and decreasing its susceptibility to compromise. Bastille can also assess a system’s current state of hardening, granularity reporting on each of the security settings with which it works. (perl): This second script searches the entire file system, listing SUID, SGID, world-writable, group-writable files. It also lists trust files and their contents. Finally it lists files with weird names (e.g., containing punctuation characters), which might be danger or a sign of penetration. On a large server with 100GB disks, this can take a few hours to run.

Unix-privesc-checker is a script that runs on Unix systems (tested on Solaris 9, HPUX 11, Various Linuxes, FreeBSD 6.2).  It tries to find misconfiguration that could allow local unprivileged users to escalate privileges to other users or to access local apps (e.g. databases).

DenyHosts is a script intended to be run by Linux system administrators to help thwart SSH server attacks (also known as dictionary based attacks and brute force attacks).

OpenVAS stands for Open Vulnerability Assessment System and is a network security scanner with associated tools like a graphical user front-end. The core component is a server with a set of network vulnerability tests (NVTs) to detect security problems in remote systems and applications.