Summary of the Paper “Zombie Awakening: Stealthy Hijacking of Active Domains through DNS Hosting Referral”

The zombie awakening (Zaw) attack is a type of DNS attack where the attacker claims outdated NS records within a DNS hosting service to hijack a domain. They do this by taking ownership of the domain and configuring its resource records (RRs), so the A record points to the IP address of the attacker’s server. Then, by repeatedly querying the DNS resolver for the domain’s A record, eventually, the resolver will return the attacker’s IP address, thus directing the traffic to the attacker’s server through the cache poisoning. This attack method is stealthier and less noticeable since the stale NS records at SLD do not often affect the resolution of a domain.

A standard DNS hierarchy

A visualization of the Zaw Attack

The attack consists of the following steps:

1. The attacker sets up an account to claim the vulnerable domain under the same DNS hosting provider.
2. The attacker sets the A record pointing to the attacker’s IP address.
3. Then will query the DNS resolver for the vulnerable domain’s nameserver.
4. If nothing is found in the resolver’s cache, it will go through the standard procedure by first querying the Top-Level-Domain (TLD) zone and storing the information retrieved into the cache.
5. The nameserver will be further contacted for the nameserver resource records in the second-level domain(SLD) zone.
6. Thus all the records associated with the target domain “example.com” will be stored in the cache
7. The information from the SLD zone will replace the information from the TLD zone.
8. The reason is that the authoritative response from the SLD zone has a higher trust level than a referral to the TLD zone.
9. Once the attacker’s IP address in stored in the cache, one can then repetitively query the DNS resolver for the vulnerable domain’s A record.
10. Eventually, the resolver will return the A record of the attacker.
11. Once it’s done, the entire attack path is activated.
12. The attacker’s IP address will be stored in the cache until the TTL expires.
13. Therefore, for any request to resolve the domain by any user, the resolver will return the attacker’s IP address as a response.
14. Thus all the network traffic is directed to the attacker.

The attack is realistic and can cause severe consequences. The researchers used ZreFinder, a semi-automated method for finding stale NS records over domains vulnerable to the Zaw attack. The result has shown that over Alexa’s top-1M domains and 20K government and education domains from Farsight’s DNSDB, there are 4,914 potentially vulnerable domains (PVDs). Among the PVDs are 628 domains confirmed to be hijackable, including government agencies and large companies. It is worth noting that not all PVDs are exploitable. As a result, the researchers found that most host service providers have exploitable PVDs due to allowing a domain to be active under more than one account with different NS records, which implies potential risks to the Zaw attack.

Aside from PVDs, the resolver is another essential part of the Zaw attack. Such an attack will only be successful if the resolver points to the attacker’s IP address and stores it in the cache. To study further, researchers mimic the resolver caching the DNS records in the actual scenario. The result shows one or more affected resolvers among 10 out of 12 resolvers, and an attack only needs up to 28 tries, with an average of 6.5 attempts to poison the resolver’s cache.

There are suggestions to prevent such an attack from happening. Firstly, companies should know about and take this attack seriously. The study shows that 565 of the 628 domains are considered vulnerable for more than 30 days, with 65% remaining vulnerable throughout the research period. It will grant attackers a longer window of time to exploit with a longer time of vulnerable domains. For the DNS service providers who randomly assign their nameservers, it is suggested to check for any stale NS records at SLD nameservers constantly; if any are found, they should give their customers a completely different set of NS records. On the other hand, if service providers use a fixed set of nameservers, they can require the client to add a randomly generated NS record at the TLD level for ownership verification. A domain will not be activated if the random record is not found in the domain’s resolution path, thus adding a layer of security at the provider level.

Improving the caching rules to protect one from DNS cache poisoning is also essential. For example, the bailiwick rule should be adjusted to include authoritative data from the TLD level, and the credibility rule should assign a higher trust level for data passed down from the TLD level instead of from the SLD zone. It is also worth noting that the Domain Name System Security Extensions (DNSSEC)-signed domains are protected from DNS caching attacks if DNSSEC-validating resolvers are used. Although it is not yet broadly deployed, the security will be further improved towards DNS caching attacks by initiating such procedures.