Domain Theft and the Possibilities for Recovery

Introduction

On October 24th 2012, Diigo, a social bookmarking website allowing signed-up users to bookmark and tag web pages, had its domain, diigo.com, 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 www.hushmail.com 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 sex.com 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 “sex.com” 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 blogtemplate4u.com and dhetemplate.com 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.

Conclusion

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.

Advertisements

Troubleshooting FortiGate 100A Connectivity Issue

Objective:  I goal of this document is meant to outline a few steps that will allow you to troubleshoot the cause behind why users were unable to access the internet while behind a Fortigate 100A device.

Problem: I received a ticket today stating that users in one our computer labs were unable to access the internet.

After arriving onsite I discounted the device and plugged directly into the ISP link and confirmed that they were no issues with the ISP connection. Now is time to open a ticket with support and start the series of troubleshooting to figure out the root cause of the issue.

Step one: Information gathering

After opening the ticket I was told that the issue could have possibly been caused by a bad firmware image, or a corrupted configuration. I needed to log into the device to find out more information and the only way to do so was via the console port.

Connecting to the Fortigate 100A console port:

  • Start your favorite terminal emulator program use the following settings:
    • Baud rate: 9600
    • Data bits: 8
    • Parity: None
    • Stop bit: 1
    • Flow control: None
  • Next, reboot the device and watch the screen for any error message.

 

After rebooting the first time I got the following message, “You must format the boot device”,  I then rebooted a second time and got the following message “The config file may contain errors, Please see details by the command ‘diagnose debug config-error-log read”.  This was somewhat good news because I would have had to RMA the device if the system RAM was corrupted.

At this point I know I had the following options:

  • Backup the current configs
  • Reset the device to it’s default state
  • Reload a new configs

Backing up the device to USB via the console port:

  • Plug a usb device into one of the ports on the back of the device
  • Login to the device, if you are unable to use your admin login you can login with the maintainer account, this account is only valid for 30 sec after the device has been rebooted; so copy the username and password to a text file then cut/paste to the console. Username: maintainer Password: bcpb<input device serial number using uppercase letters>
  • Issue the following command: execute backup configs usb filename<use any name here>
    FG100 # execute backup full-config usb fg100a-10-15-11
    Please wait…
    Copy onfigs fg100a-10-15-11 to USB disk …
    Copy onfigs file to USB disk OK.
    Setting timestamp

Before reloading a new configs its best to run a few diagnostic commands to try and understand what happened:

FG100 #  diag sys top –> Look at CPU load and any processor that running hot

FG100 # diag debug crashlog –> Look for clues as to what service crashed

          Ex Output:

89: 2011-11-14 16:06:42 <04434> application cmdbsvr

 290: 2011-11-14 16:06:42 <04434> *** signal 7 (Bus error) received ***

 291: 2011-11-14 16:06:42 <04434> Register dump:

298: 2011-11-14 16:06:42 <04434> Backtrace:

 299: 2011-11-14 16:06:42 <04434> [0x0893277b] => /bin/cmdbsvr 

 300: 2011-11-14 16:06:42 <04434> [0x08932a96] => /bin/cmdbsvr 

 301: 2011-11-14 16:06:42 <04434> [0x08910473] => /bin/cmdbsvr 

 

Reload new configs via console port:

  • Rename your most recent backup configs file to fgt_system.conf, then place file on the root of your USB drive.
  • Plug the USB into one of USB ports on the back of the unit and reboot the unit and you should see a similar output:

 

Reading boot image 1370111 bytes.
Initializing firewall…
System is started.
Get image from USB disk …Can not get image from USB disk.
Get config file from USB disk OK.
File check OK.

The system is going down NOW !!

 If you are not certain and you leave the drive in after the system reboots you will see the following message indication that the configs file on the disk is the same as the file on the system.

 Get config file from USB disk OK.
Checksum check synced! Don’t need restore config.

 

 Additional Troubleshooting:

After I restored the config file I was still unable to connect out to the internet, so I issued the following command to verify my IP address setting:

FG100A # get system interface  

After discovering that the IP address for my external interface WAN1 had a different subnet than the one I wrote down previously when I connected directly to my ISP modem with my PC. I decided to change the interface type to DHCP.

 

Configuring external interface for DHCP:

FG100A #  configs system interface –> To enter into Interface config mode

FG100A (interface) # edit wan1 –> Choose your external interface in our case it was wan1

FG100A (wan1) # unset ip –>  Removing current static IP entry

FG100A (wan1) # set mode dhcp –> To change mode to DHCP from static

FG100A (wan1) # show –> To confirm that the change was made

config system interface
edit “wan1”
set vdom “root”
set mode dhcp
set allowaccess https ssh fgfm
set type physical
next
end

 FG100A (wan1) # end

 I was now able to access the internet!!

Discovering what happened:

Wrap-up:

Given that the logs were lost due the fact the FortiGate was reset and the unit is storing it’s logs in RAM, I can’t diagnose the exact cause. But we did see in the Crashlog “diag debug crashlog read”, which is written to flash that the cmdbsvr was crashing. We have identified a issue with cmdbsvr on the version of fortios on your fortigate.

Bug #’s : 117281, 144277
Summary : cmdbsvr crash in conserve mode may cause configuration loss

I updated the device to MR3 patch 2, since this version addressed the issue.
Reference Documentation:

http://emea.fortinet.net/fortinet/bht/index.php

http://bit.ly/uRSdYJ

http://docs.fortinet.com/fscan/fortiscan_cli_40.pdf

Allow full mailbox access

We have recently upgraded to Exchange 2010 from 2003 and with that update comes new ways of dealing with old recurring task, I will try to outline over the new few blog posting how to accomplish these task. If you are ask to remove or grant someone access to a user’s mailbox below is the recommended approach.

You can do this two ways first is via the Exchange management console (EMC) or via the PowerShell:

EMC approach:

You need to be assigned permissions before you can perform this procedure. To see what permissions you need, see the “Permissions and delegation” entry in the Mailbox Permissions topic.

  1. In the console tree, navigate to Recipient Configuration > Mailbox.
  2. In the result pane, select the mailbox for which you want to grant Full Access permission.
  3. In the action pane, under the mailbox name, click Manage Full Access Permission. The Manage Full Access Permission wizard opens.
  4. On the Manage Full Access Permission page, click Add.
  5. In Select User or Group, select the user to which you want to grant Full Access permission, and then click OK.
  6. Click Manage.
  7. On the Completion page, the Summary states whether Full Access permission was successfully granted. The summary also displays the Shell command used to grant Full Access permission.
  8. Click Finish.

PowerShell approach:

You need to be assigned permissions before you can perform this procedure. To see what permissions you need, see the “Permissions and delegation” entry in the Mailbox Permissions topic.
First verify who currently has access to the user’s mailbox with the Get-MailboxPremission cmdlet, you will notice several default system accords you are only concern with user accounts.

Get-GmailboxPermission “John Doe”

If you want to remove Jane Doe  from having full access to John’s  mailbox you can do the following:

Remove-MailboxPermission “John Doe” -AccessRights FullAccess -User “Jane Doe”

If  you are ask to  grant the user Marry Full Access permission to Frank’s mailbox do the following:

Add-MailboxPermission “Frank Loew” -User “Mary May” -AccessRights FullAccess

Once you are finish granting access just mount the mailbox via outlook and close and reopen outlook and it should be accessible.

Source:

http://technet.microsoft.com/en-us/library/aa996343.aspx

My Fedora 15 experience

So as most of you might know by now the development team over at Fedora has release a new version of the ever popular Linux distribution; Fedora 15 code name “LoveLock”. This posting is not to get into too much details about the new version or various ways in which you can  install it or anything of the sort for that you can visit Fedora documentation wiki.

The following are major features for Fedora 15:
  • GNOME 3 including the new GNOME 3 shell
  • KDE 4.6 with the improved Plasma workspace, enhanced core applications, and greater memory efficiency.
  • XFCE 4.8 with a new panel, Thunar enhancements and more.
  • Virtualization improvements including Spice support in virt-manager and support for Xen hosts.

Those features listed above are just a few of the great improvements that the new version has to offer, but as with anything new the are some give and take. I took the leaf of faith and installed the new version the day after it was released and I must say it was not what I was expecting at all.

Since I was running Fedora 14 on my Eee PC I figured it was going to be a quick and easy upgrade, so I went over the the wiki and fellowed the below steps:

First install the new fedora 15 gpg key. You may wish to verify this package against https://fedoraproject.org/keys and the fedora ssl certificate.

rpm --import https://fedoraproject.org/static/069C8460.txt

Upgrade all packages with

yum update yum
yum clean all
yum --releasever=15 --disableplugin=presto distro-sync

Problem #1

As simple as the above upgrade looked it didn’t turn out to be so simple for me, the upgrade processes kept failing and when it finally worked and I was prompted to reboot the system would hang at the logo.

If  I hit the ESC key during boot up I would notice that the system was hanging at  “Starting SYSV: Late init script for  live image, Started SYSV: Late init script for live image”.

At this point I know it was time to signup for the mailing list and visit freenode.net #fedora in search of an answer, but since it was a new release everyone else was also asking for help so I had to wait a bit.

I tried a few things but in the ended wiping out my Fedora 14 and installing Fedora 15. At that point I got a potential fix in a reply to my mailing list cry for help, the suggestion was to:

Log into single user mode  and removed all kmod packages, then installed akmod packages through command line.

Once my new install was finish I realized quickly that Gnome 3 was not the way to go on my Eee Netbook, I quickly had the following issues:

  • Screen kept diming eventhough I chaged the power management  and other setting.
  • My wireless connection strength dropped by about 50% even though I was in the same room with the AP, prior to that Fedora 15 I had near perfect signal.
  • The entire windowing experience was too slow, and bulky looking for my Netbook, It was hard to work with two windows side by side.