Identity Theft by Registrars

Introduction and Overview

Most likely you use at least one domain name for your business, and may wish to register new ones for new ventures. The companies responsible for managing this, called domain name registrars, have enormous power over the use of domain names. Although their actions are supposed to be controlled by rules from the central body that sets standards for use of domain names, treachery or other unethical behavior by registrars can result in severe breaches in the security of your website and your customers' data.

This is the story of how one such registrar, Name.com, engaged in what amounts to identity theft, and brazenly continues to do so even after having been called out on it. It reveals how any registrar can so easily breach its trust, and how the governing bodies that are supposed to set standards to ensure the system works have failed to address this.

Technical Background

The standard system for securing communications over the web is a set of protocols and technologies called SSL. This provides for encryption between your web browser (on your computer or mobile device) and the server where the web site exists (the web server). Your browser and the web server will create the secret keys necessary for encryption and decryption on the fly, and no one who might be trying to intercept your communications can capture the keys, let alone the information you submit or the web pages you're viewing. When the server sends information on a web page, your device decrypts it and displays it. When you input information into a form and send it to the server, the server decrypts it upon receipt and can then use it (to log you in with your password, process a credit card purchase, etc.).

Another critical aspect of SSL is providing a way for your web browser to confirm that it is communicating with the web server you intended to visit. If your browser establishes an encrypted communications channel with an impostor website, then when you type your password, credit card information, etc., it will be encrypted between your device and the impostor website, but then the owners of the impostor website will have the information. So while the encryption may prevent random eavesdroppers from seeing your data, by itself it won't defend against someone who deliberately set up an impostor website to capture just this data.

To avoid this, your browser confirms the identity of the website you're connecting to before any information is sent or received, using a system called PKI (public key infrastructure), which uses cryptography and a system of trust by which your computer can confirm that you're connected to the actual website you meant to visit, and not an impostor.

The system of trust, however, relies on the virtue of the companies your computer trusts. Who are these companies? The first is the publisher of your operating system software. That means Microsoft if your computer runs Windows, Apple if you use a Mac or iPad/iPhone, or Google if you use an Android-based device. Your operating system has a set of cryptographic security tokens called certificates that are already on your computer or device when you buy it. These are the certificates for companies called certificate authorities (CAs), which must go through a process to prove their worthiness before they will be included by Microsoft, Apple, or Google in their operating systems. To enable SSL on his web site, the manager gets a certificate for his web server issued and cryptographically protected by one of the trusted CAs.

When you visit a web site with such a certificate, your browser confirms with cryptographic algorithms that the certificate it presents was legitimately issued by a CA your computer trusts, using the CA certificates that your computer or device has in its trust list. This is generally what the PKI system entails. There is more to it than this simple explanation. Just understand it is not possible for the owner of a rogue website to forge a certificate as having been issued by a CA and fool your browser. This is due to the presence of secret keys held by the CAs and each web server which are never shared between them, and clever mathematical algorithms that allow a website to prove, and your browser and CAs to confirm, that a web server has the correct secret key without the secret key ever leaving the web server.

Apart from the PKI system of certificates, CAs, and secret keys, the other crucial aspect of confirming the identity of a web server through SSL is the Domain Name System (DNS). This is a world-wide distributed database of domain names (such as jdfoxmicro.com). The billions of computers and servers on the Internet contact each other not by domain name, but using a numerical addressing system called TCP/IP, which includes routing and computer identification information in numerical form. When you type the name of the web site you want into your web browser, it accesses the DNS database to get one of the numbers necessary for your computer to reach that web server, called an IP address.

The certificate presented from the web server shows the DNS name of the server, which must match the DNS name you entered into your browser. If it does not, then even if the certificate is legitimate and trusted by your computer, your browser will give you a warning that you may not be connected to the website you intended to reach. Just as a certificate cannot be verified unless the server sending it has the secret key that identifies the server, a certificate also cannot be forged to show a domain name different than the one specified when it was issued by the CA.

A relatively unsophisticated method by which a criminal might try to steal data is by hijacking DNS lookups to redirect your browser to the criminal's web server. With SSL technologies in place and the trust system working properly, such an attack will not work. That is, if you type the correct DNS name of a website into your browser but somehow your computer gets the IP address for an impostor server set up by a criminal, that web server will not be able to present a certificate that can be validated by your computer, and you will receive a warning and be blocked from visiting the website. And when you do reach the correct website, your computer will connect and establish encryption, and then you can proceed to use the website.

Theoretically, given enough time, someone could take the cryptographic information in a certificate and, by applying tremendous computing power, derive the server's secret key. If that happens, then an impostor website could present this certificate as its own, and apply the secret key in the cryptographic computations performed by your browser and the web server to verify the certificate, and your browser would then think you're on the legitimate website. So, certificates are set to expire before anyone could have time to crack its related secret key. Typically, a certificate for a web server is valid for one year. When a certificate expires, the web server manager generates a new secret key and gets a new certificate.

When you're setting up a new web server, it's not very difficult or expensive to get a certificate issued. The web server manager must simply prove that he has control over the DNS records relating to his domain name. This is done in an automated fashion. When applying for the certificate, the CA's website might provide a code the web server manager than enters into the DNS database for his domain name. The CA's system then does a lookup from its network into the DNS system for this record, and when it gets back the same code, this confirms to the CA that the web server manager applying for a certificate does control the domain name that is to appear on the certificate.

How An Unethical Registrar Can Breach Trust

When you register a new domain name, your domain name registrar inserts the fact that you are the owner of the domain name into the worldwide database of all domain names called the Domain Name Registry. Only certified registrars can update this registry. Crucially, the registry also includes information on which servers hold the DNS information for your domain name. These DNS servers, wherever they are, will be managed and controlled by you, the owner of the domain name. Only the registrar can modify which DNS servers are listed in your registration, but they must insert whatever you request, so that your DNS servers are consulted whenever a potential visitor to the website enters the domain name into his browser.

Many registrars offer DNS hosting services, meaning they run DNS servers that can store a DNS database for domain names, and respond to queries from users looking for your website. Such registrars will usually list their own DNS servers in the registry for your new domain name, without asking. They assume you don't have any DNS servers, and that you can update the registry later if you do, when your website manager sets up your website.

When a registrar sets up DNS for your new domain name on its own DNS servers, it typically assigns an IP address to point the domain name to a website, hosted on the registrar's web server, with advertisements for third-party providers or for their own services. You've likely seen one of these pages, typically called a "placeholder". It stays there until your own web server is ready to go live, and you update DNS to point your domain name to your website, away from the placeholder.

This isn't ordinarily a problem, so long as the placeholder doesn't use SSL. However, there is at least one registrar (Name.com) that automatically does the following when you register a new domain name:

• Sets up a placeholder page, with advertisements, on a server hosted by a partner company in Europe.
• Sets up DNS servers to service your new domain name.
• Inserts the addresses of these DNS servers into the registry for your domain name.
• Adds a DNS record to direct anyone's web browser to this placeholder page.
• Has their partner generate a secret key, to be tied to your domain name, on this web server in Europe.
• Applies for and acquires a certificate, valid for one year, tied to the secret key on the server in Europe. In doing this, they certify to the issuing CA that they own the domain name and are authorized to establish the identity of your website through SSL.

Attentive readers will see the problem with this. Even if you instantly reset the DNS server information in the registry to point to your own DNS servers, and then update the DNS records to point your domain name to the IP address of your own web server, the fact remains there is a certificate, with a secret key, present on a server in Europe that is out of your control, which can be used to run an impostor of your website, and which has a valid certificate that any browser will trust to establish that it is in fact your website. So, until this certificate fraudulently implemented by Name.com expires, your website is at elevated risk for being hijacked, and there is nothing you can do about it. This is because anyone on any network where they have control over DNS lookups can direct any user on his network to the impostor server in Europe when that user types your website name. The impostor server will then certify itself as your website using SSL, and none of this involves your web server, your DNS servers, your real web server's certificate, or any other IT assets you control.

What's so grating about this is it might not even hurt you directly, but could hurt your reputation and cost you money without your even knowing. That is, a new customer intending to visit your website could be directed to the impostor's website, which the user's browser incorrectly confirms is yours by relying on the false certificate. The new customer enters his information into the website to be contacted, which goes to a scammer pretending to be your company, who steals his money by one of the various methods scammers use, made so much easier than a typical cold scam attempt by the fact the victim initiated the transaction and thinks he's talking to your legitimate company.

What should be considered as a total compromise of SSL for your website is a result solely of the irresponsible and unethical behavior of Name.com.

There is a method by which a certificate can be revoked. However, since it is in general rare for certificates to need to be revoked, most web browsers do not bother checking the revocation list, because it could add several seconds to the time it takes to load each website. So, even if you get the issuing CA to revoke the fraudulent certificate, most users' browsers will still certify the impostor as your website.

It gets worse. Name.com not only doesn't tell you during the checkout process that they're doing this, they specially designed their website to hide it. When you log in to your Name.com account and look at the configuration of your registered domain name, there is a section where it supposedly shows the DNS records set up for your domain name through their DNS hosting. However, the record showing the IP address of their web server in Europe is hidden. One of their website developers made a special effort to display false information to its customers.

The only way to mitigate the situation would be for Name.com to delete the secret key in good faith. However, they do not provide visibility to their customers into the secret key on the server, which isn't even their server. Assuming the server is virtualized and there is a data backup system on the servers in Europe run by their partner, there could be multiple copies of the secret key on various storage devices, anywhere in the world.

The core of the treachery on the part of Name.com is in using its privileged position as a domain name registrar to control your DNS to issue itself an identity certificate for its own web server. The fact this is allowed undermines the entire SSL system, which, as described above, is based on trust.

When we at J.D. Fox Micro called them out on it, at first Name.com (and Donuts, Inc., apparently their parent company) denied that it was a problem. They then not only refused to stop the practice, but they added it to their Registration Agreement in a pathetic attempt to address the fact that registrants are not informed of what they do. They refer to their setting up an impostor server with an SSL certificate obtained through misrepresentation as a "free SSL certificate" as if it's of benefit to you. They also added some sentences falsely implying that simply setting up your own DNS servers and your own web server mitigates the existence of an impostor website with a valid certificate, which it does not.

Unfortunately, DigiCert, the CA involved, was uninterested in the fact Name.com is issuing SSL certificates to itself for domain names that are registered and should therefore be under control of the registrant. Their failures also contribute to the undermining of the SSL system.

Conclusions and Recommendations

This incident is one of many situations where companies with unethical leadership and/or incompetent information security officers put the SSL system at risk, and where there is nothing you can do to protect yourself. The best lessons to learn from this are:

• Never stop being vigilant in assessing and auditing the security practices of service providers you use. When you observe breaches or unethical behavior, tell them about it and demand they fix it.
• Develop an information security program so that you may perform proper monitoring of all aspects of your systems, to include systems you don't own or manage which could compromise your customers' or partners' security. As part of this program, have contingency plans that presume eventually a breach that is outside of your control will eventually occur.
• No matter how small your reach may be, call out unethical or insecure practices you observe to raise awareness and force action.

For all of the above, you may need a competent IT service provider, such as J.D. Fox Micro, or a provider of information security and disaster recovery services, such as J.D. Fox Exec. Click the links to learn more.