Akamai Diversity
Home > Web Security > DNS Hijacking: Dangers and Defenses

DNS Hijacking: Dangers and Defenses

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.

We 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 name.

Defensive measures
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:

clientUpdateProhibited

clientTransferProhibited

clientDeleteProhibited

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 server locks.

These locks follow the same format:

serverUpdateProhibited

serverTransferProhibited

serverDeleteProhibited

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.

Luna 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

Two-Factor Authentication

SAML Support

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.

1 Comment

Is it what happened with Malaysia Airlines?

Leave a comment