By Patrick Laverty, Clark Shishido, Dave Lewis, Mike Kun, Larry Cashdollar and Bill Brenner
We're always concerned about where the next attack is coming from. We worry about DDoS, SQL injection, defacements and a host of other attack techniques. One attack in particular can bypass even the best security protections and give attackers the keys to the kingdom.
That attack is called DNS Hijacking. This happens when attackers gain access to a domain registrar account and change the DNS resource recordsto point to server(s) under the attacker's control.
Nature of the threat
Domain registration compromises expose a threat which has high repercussions for a relatively small number of targets. The targets of spear-phishing attemepts include IT, Finance and HR staff who have access to domain registration accounts. Very often, this access is gained by phishing email credentials from a site's domain administrator. Once they have the credentials, the attacker can perform a password reset on the registrar's site.
With the new password and administrative acess, the attacker will log in to the registrar and make changes to DNS records such as NS records which provide resource records for web servers and mail servers. When under the control of attackers, all requests to websites and email can be under the control of the attack which includes all email and web traffic for a given domain.
When the NS records
are under the attacker's control web and email traffic can be
redirected to any IP address controlled by the attackers. Often the NS
records have a long TTL (24-48 hours) so that the effects of a compromised registrar attack can have effects up to the TTL of the NS records.
have seen instances where the attackers modified the entire zone file,
including MX (mail exchange) records, providing the attackers access to
any mail sent to the target of the attack. In addition to information
leakage via email, the attackers can also use this access to trigger
password resets on other services and compromise them as well. With the
ability to intercept password reset attempts the attackers will attempt
to maintain control over all administrative acounts for a given domain
To protect against phishing, companies need a good awareness program. Wherever possible, please enable two-factor authentication on hosted email services.
Our advice to better protect against DNS hijacking is to employ the registrar locks available for domains. The first type of lock is a client lock. A domain should have at least the client locks in place as these will prevent unauthenticated changes to a DNS record.
The client locks include:
Most registrars offer these locks for free. Some registrars even turn
them on by default. You can check to see if these locks are in place
for a domain by running a 'whois' command at a terminal prompt.
If an attacker successfully obtains credentials to a registrar account, client locks will not prevent changes to the DNS records.
The attacker can log in to the registrar and turn these locks off to
make the changes. For a higher level of protection, registrars offer
These locks follow the same format:
The difference with these locks is they offer a type of two-factor
authentication. If these locks are in place and someone tries to make DNS changes,
even valid changes, the registrar will check with a previously agreed
upon contact. The only drawback is the registrar may take up to a few
days to turn these locks off. If rush changes need to be made, you will
need to plan ahead to account for the time needed.
accounts are at risk to password reuse attacks where previously
compromised credentials are used to check for accounts which reuse the
same password for different SaaS providers. Akamai has introduced
two-factor authentication and other restrictions for logging in to the
portal site for making configuration changes. Some of the options that
can be enabled include:
IP Restricted Login
User Management APIs
In addition, practice safe password handling for all users who have
access to external Internet infrastructure accounts such as domain
registrars and Akamai portal administration.
Do not use the same password for multiple sites and store passwords for critical infrastructure offline in a secured location.
We have more information about these here, or Akamai customers can contact CCare or their account team for more information.