We all know how traditional phishing works, where email is sent to users in an attempt to steal login or credit card information. But there is another, less known attack that is becoming more common: striking at the domain name level.
A phisher uses a routine correspondence from domain name registrars in an attempt to gain control over legitimately registered domain names. Phishers (criminals, in general) see a great benefit from using a domain name that is held by a registrant in good standing because of the uncertainty they cause when claims of misuse are registered. Any uncertainty on the part of interveners or registrars may delay efforts to suspend any illegal activities conducted in association with that domain name. A recent example against GoDaddy.com is described here.
A chronology of this phishing attack scenario follows:
The phisher hosts a fraudulent copy of the registrar’s login portal. The login form on the fraudulent page hosts a script that accepts the visitor’s username and password and delivers this to the phisher.
The phisher spams a copy of a routine correspondence that registrars send to customers. Registrars contact customers by email to notify them to renew or update contact information domains, or to inform them when changes have been made to a domain registration or the name server configuration for their domain. These correspondences are familiar to customers, and more importantly, they ask the customer to log into his account. They are perfect bait for a phish.
The registrars’ customer takes the bait, visits the fraudulent login page, and unwittingly discloses his registration account credentials to the phisher.
Only the initial purpose of registrar phishing attacks is to gain control over domain names. A common secondary objective is to exploit the DNS to facilitate other criminal acts. A phisher will first change the name servers for a domain managed through the account to point to a name server also under the phisher’s control. The name servers in a domain name registration record identify the name servers to which top-level domains like .com refer DNS queries for resolution of names delegated from a registered domain name.
For example, the .com name servers refer DNS queries for my domain, securityskeptic.com, to NS25.DOMAINCONTROL.COM or NS26.DOMAINCONTROL.COM. These two name servers host the DNS data for my domain -- e.g., both will return the IP address 220.127.116.11 for my Website, www.securityskeptic.com. If a phisher were to compromise my registration account, he would change the name server information to point to a name server he’s owned, and .com’s name servers would be updated to reflect this change in configuration. The attacker can now control the responses for any DNS query about my domain because he controls the name server and the DNS data it publishes.
This is a very powerful attack platform. Here’s a short list of attacks that he can facilitate, for himself or others who “contract his services” (A fuller list is identified in the ICANN SSAC report on registrar phishing):
Modify IP address records to point to spoofed Web or other servers under the attacker’s control. The attacker can then host whatever content he chooses at the phony site; for example, the attacker might choose to deface the Website and embarrass the registrant.
Modify IP address records to point to spoofed login pages for intranet, wiki, or customer Web portals. Like other forms of phishing, the attacker seeks to dupe unsuspecting employees into disclosing usernames and passwords so he can access and steal sensitive information.
Modify mail exchange (MX) resource records in the domain zone data he controls to point to addresses of mail servers under his control and send spam from mail servers he controls. Altering MX records will in many cases disrupt mail delivery to points of contact for the domain name registration and will keep the organization in the dark regarding the compromise.
Set time to live values (TTLs) and alter DNS records of the domain zone data on the name servers he operates at those addresses to support fast flux or double flux attacks.
Given the advantages we’ve considered, it’s pretty obvious why phishers find registrar phishing “good for business.” It’s worth your while to be as vigilant in protecting your organization from such attacks. In my next blog, I’ll discuss measures to detect and respond to registration account compromise.
Cvargas asked "How do you split your DNS hosting from the registrar?"
A discussion of how to add diversity to your DNS hosting might be a good "part III" but the short answer is that when you purchase a domain registration, your registrar of choice *typically* gives you the opportunity to identify the IP address of your primary and secondary name server. If you don't give one, the registrar typically hosts your DNS on his own name servers. You can change this at any time by logging into your domain registration account to "manage your DNS" through some user interface the registrar provides.
Before you change the name server IP address, you must either arrange to run a DNS server on a public IP address yourself, or make arrangements with some other party than the registrar, such as your ISP, a web hosting company, or a DNS service provider.
Don't click on links in any mail, even from your most trusted friends and family. Type URLs into your browser.
Absolutely spot on. At times I can be lazy and click away at links embedded in an email. To be vigilant I'll need perk up my fingers and start typing URLs directly into the browser. I'm especially wary of emails from financial institutions. I guess I'll need to put emails from registrars at the top of the list.
Unfortunately, until we learn to be more vigilant, these criminals are living large. Don't click on links in any mail, even from your most trusted friends and family. Type URLs into your browser. Phishers depend on people finding this too inconvenient and they depend on people realizing later that it's much more inconvenient and costly to recover a stolen identity.
We are very bad at considering consequences. People who ask "what if..." while they are online are less likely to fall victim to phishing.
The blogs and comments posted on EnterpriseEfficiency.com do not reflect the views of TechWeb, EnterpriseEfficiency.com, or its sponsors. EnterpriseEfficiency.com, TechWeb, and its sponsors do not assume responsibility for any comments, claims, or opinions made by authors and bloggers. They are no substitute for your own research and should not be relied upon for trading or any other purpose.
Enterprise Efficiency is looking for engaged readers to moderate the message boards on this site. Engage in high-IQ conversations with IT industry leaders; earn kudos and perks. Interested? E-mail: email@example.com
Dell's Efficiency Modeling Tool The major problem facing the CIO is how to measure the effectiveness of the IT department. Learn how Dell’s Efficiency Modeling Tool gives the CIO two clear, powerful numbers: Efficiency Quotient and Impact Quotient. These numbers can be transforma¬tive not only to the department, but to the entire enterprise. Read the full report
Now that TGen has broken new ground in genomic research by using Dell's storage, cloud, and high-performance computing solutions, the company discusses what will come next for it and for personalized medicine.
The Translational Genomics Research Institute wanted to save lives, but its efforts were hobbled by immense computing challenges related to collecting, processing, sharing, and storing enormous amounts of data.
Office and personal productivity tools come in a first-class and coach flavor set, but what makes the difference is primarily little things that most users won't encounter. What's the big issue in using something other than Office, and can you get around it?
We really don't want an "Internet of Everything" but even building an Internet of Everythinguseful means setting some ground rules to insure there's value in the process and that costs and risks are minimized.
Google's Chrome OS has a lot of potential value and a lot of recent press, but it still needs something to make it more than a thin client. It needs cloud integration, it needs extended APIs via web services, and it needs to suck it up and support a hard drive.
On a recent African trip I saw examples of the value of the cloud in developing nations, for educational and community development programs. We could build on this, but not only in developing economies, because these same programs are often under-supported even in first-world countries.
VMware's debate with Cisco on SDN might finally create a fusion between an SDN view that's all about software and another that's all about network equipment. That would be good for every enterprise considering the cloud and SDN.
Wearing a bulky, oversized watch is good training for the next phase in wristwatches: the Internet-enabled, connected watch. Why the smartphone-tethered connected watch makes sense, plus Ivan demos an entirely new concept for the "smart watch."
Cloud storage costs are determined primarily by the rate at which files are changed and the possibility of concurrent access/update. If you can structure your storage use to optimize these factors you can cut costs, perhaps to zero.
The Internet has evolved into a machine for drumming up a chorus of "Happy Birthday" messages, from family, friends, friends of friends who you added on Facebook, random people that you circled on G+, and increasingly, automated bots. Enough already.