The Hijackers Guide to the Galaxy: Off-path taking over Internet resources

By on 21 Apr 2022

Category: Tech matters

Tags: , , , ,

Blog home

It’s important to note that these measurements began in 2019 and continued until late 2020. APNIC, for example, has since worked to address the few outstanding issues and moved the login system to Okta.

Internet resources provide the fundamental platform for all digital services. Due to their importance, they are supposed to be well protected and managed.

However, in a recent study, we at Fraunhofer SIT in ATHENE, found that under some conditions adversaries can gain access to and maintain control over Internet resources they do not own and perform stealthy manipulations, leading to devastating attacks. The core idea is to take control over the accounts through which the resources are managed. Control over accounts provides direct access to the digital resources associated with the victim. Certainly, taking over accounts associated with digital resources is a lucrative target even for strong state-sponsored attackers. In this project we explore two issues:

  1. How easy it is to take over accounts of popular operators of digital resources.
  2. What can be done once such accounts are compromised.

Our findings are that the resources associated with vulnerable accounts that can be compromised correspond to at least 68% of the assigned IPv4 address space as well as 31% of the top Alexa domains. 

In this post we briefly explain the digital resources we evaluated and the vulnerabilities we found. We provide recommendations for mitigations to prevent such attacks.

Dataset of digital resources and providers

Typically, digital resources are provided and managed through specific online portals. An account at those providers is mandatory to access the control panel. Our study covers four types of digital resources and corresponding providers:

  • IP addresses at Regional Internet Registries (RIR) such as ARIN and APNIC.
  • Domain names at domain registrars such as GoDaddy and Alibaba.
  • Server certificates at Certificate Authorities (CA) such as Sectigo and DigiCert.
  • Cloud machines at cloud providers such as Azure and AWS.

Hijacking accounts

Figure 1 — Off-path hijacking accounts.
Figure 1 — Off-path hijacking accounts.

The first step is to take over the accounts of targets. In order to hijack customer accounts, we attack the password recovery procedure of the victims. We launch off-path DNS cache poisoning attacks, to redirect the password recovery link to the adversarial hosts. This process is shown in Figure 1. We measure three different types of practical off-path DNS cache poisoning attacks:

  • HijackDNS — The adversary can hijack the prefix of the victim to intercept the DNS request or response, thereby crafting a correct spoofed response with a rogue DNS record. In this work, we focus on sub-prefix hijack attacks.
  • SADDNS — A technique that can be used to guess the port on the DNS resolver and use it to execute DNS cache poisoning. 
  • FragDNS — Attack that manipulates the target payload by injecting a spoofed IPv4 fragment. The DNS cache is poisoned by injecting a rogue DNS record.

Our measurement shows that all the tested providers were vulnerable to at least one of the attacks. The majority of the providers we tested were vulnerable to HijackDNS and FragDNS, while only a few providers were vulnerable to SADDNS. Detailed results are shown in Table 1.

Providers HijackDNS SADDNS FragDNS Any Method
RIR 5/5 0/4 3/5 5/5
Registrar 11/11 0/9 11/11 11/11
Cloud 11/14 4/13 14/14 14/14
CA 5/5 0/2 5/5 5/5
Total 27/30 4/24 28/30 30/30

Table 1 — Measurements on provider vulnerabilities.

Vulnerable accounts

For a customer to be vulnerable, two conditions have to be satisfied.

First, to trigger password recovery the adversary needs to know the customer’s login information or account details. 

We found, experimentally, that for most providers the email address is used for logging in. With the help of the whois database, which is publicly available and contains contact information of many of the resources, adversaries can retrieve contact data of certain resources. For our customer dataset, we obtained contact emails for 75% of the Autonomous Systems (ASes) and 11% of the Alexa domains. For accounts that we could not retrieve over whois, we used a dictionary attack to guess the account. For example, some use well-known emails such as admin@company or webmaster@company.

Second, the nameserver configuration of the email domain of the target customer should meet the requirements of one of the DNS cache poisoning methods. We found that around 50% of customers were vulnerable to HijackDNS, around 10% were vulnerable to SADDNS, and around 20% were vulnerable to FragDNS.

Once we have the list of customer accounts that can be hijacked, we map them to the associated digital resources, especially IPv4 addresses and domains. This gives us the fraction of Internet resources that can be manipulated. Even though only around 50% of the tested customers are vulnerable, this corresponds to the 93% of IPv4 addresses and 65% of domains, as shown in Figure 2. 

Figure 2 — Vulnerable resources of tested accounts
Figure 2 — Vulnerable resources of tested accounts.

Manipulation of digital resources via hijacked accounts

Adversaries can perform different exploits over the resources associated with the hijacked accounts. Most of the actions are similar across the providers, even providers of different infrastructure, such as the RIRs and domain registrars. As an example, we explain what actions the adversary can take when controlling a victim Local Internet Registry (LIR) account. For our demonstration, we use an account with the RIR, RIPE NCC. We list the possible manipulation over the digital resources in Table 2.

Additional validation Attack Outcome / attacker use
  Account control Yes Account transfer Permanent control
No Change account details Permanent control
Yes Account closure DoS
No Disable email alerts Remain stealthy
Resource manipulation Yes Resource transfer/sale Permanent control / monetary gain
No Resource return DoS
No Whois DB modifications Facilitates hijacking
No Creation of new ROAs Facilitates hijacking
No Creation of invalid ROAs DoS

Table 2 — Possible manipulation over the digital resources at RIRs.


We propose countermeasures in two categories. First, to make it harder to take over accounts, account details should not be public. The system should be separated for high-privileged and low-privileged accounts. CAPTCHAs and DNSSEC enhance security and make the attacks more difficult to launch. 

The other category is to make it harder to manipulate resources. Multi-factor authentication (MFA) and account notification should always be activated by default. In addition, introducing manual review of requests and authentication over digital transactions will help to make resources more difficult to manipulate.

Conclusions: Protection of digital resources needs to be improved

Each provider maintains a database that defines assignees of an Internet resource and offers tools for them to manage their resources. We showed that these databases are poorly protected — the adversaries can take over the accounts for managing the Internet resources and can manipulate the databases, for example, by creating new or removing existing objects stealthily and causing immediate changes to the resources.

There are existing countermeasures, but most of them are not supported or, by default, not enforced. 

This research is a joint work of Tianxiang Dai, Philipp Jeitner, Professor Haya Shulman and Professor Michael Waidner and was published at the USENIX Security 2021. View the full paper and presentation.

Tianxiang Dai is a research associate in ATHENE Center and Fraunhofer SIT in Germany. His research interests are in network security including DNS security, IP security and firewall security.

Rate this article

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.

Leave a Reply

Your email address will not be published. Required fields are marked *