Recent incidents have illuminated the profound influence of Web 2.0 vulnerabilities on the Web3 ecosystem, underscoring the intertwined security of these two domains. This report delves into a category of Web 2.0 security incidents that have directly impacted the Web3 industry. Central to our analysis are attacks executed on Domain Name Systems (DNSs), which are a pivotal component of the Internet’s infrastructure. Cyber adversaries employ DNS hijacking attacks for phishing purposes, where they target users' wallet seed phrases, or for creating deceptive webpages that closely resemble legitimate ones.

We will begin by exploring the distinctions between the designs of hierarchical, centralized DNS, and Distributed Ledger Technology (DLTs) based DNS. A comparative analysis of their security features will be presented. Subsequently, we will examine specific incidents involving this attack technique, resulting in financial losses for numerous web3 users. Lastly, we will outline how the utilization of a combination of DLT-based DNS and the Inter-Planetary File System (IPFS) might have thwarted these attacks.

Domain Name Sytem

DNS translates user-inputted domain names into IP addresses, as depicted in Figure 1. This conversion enables browsers to easily access websites and online resources, without having to remember a complicated string of numbers. Each device connected to the internet possesses a unique IP address, serving as its digital identifier. Instead of memorizing a series of numerical IP addresses, individuals can instead input a website's name, and the DNS retrieves the relevant IP.

Figure 1. DNS High Level Request Resolution

The principal functions of a DNS include ensuring the uniqueness of name-value pairings and maintaining a consistent view of the database for all participants.

Bad actors aim to exploit this system, orchestrating DNS attacks to redirect Web3 users to malicious websites. These redirections can lead to phishing attacks, malware downloads, and other harmful activities, all aiming to siphon users' wallets. The integrity of the DNS is paramount, as malicious users should never be allowed to manipulate names or associate them with incorrect values.

Hierarchical and Centralized vs. DLTs-Based DNS

Hierarchical and Centralized DNS

In the early stages of Internet development, to ensure that name-value pairings were unique and that every participant maintained a consistent view of the database, the implementation of a top-down hierarchical and centralized controlled architecture was the only viable solution. This architecture, depicted in Figure 2, resulted in both a hierarchical and centralized structure that paved the way for problems related to censorship and third-party reliance.

Figure 2. Hierarchical and Centralized DNS Architectural Overview

Indeed, those in control of the top levels of a DNS, a critical component of Internet architecture, have the power to modify the web experience for all users. A prominent example of censorship is the 2011 shutdown of wikileaks.org by its US DNS provider. Additionally, centralization, along with reliance on third-party entities, not only raises trust and data integrity concerns but also introduces vulnerabilities. These central control points can become targets for cyberattacks, disrupting the entire domain resolution service and attacking users.

DLT-Based DNS

The controversies stemming from the Wikileaks incident, coupled with vulnerabilities introduced by centralized control, prompted researchers and activists to advocate for a decentralized solution. This advocacy led to a reformulation of the original problem and the emergence of Zooko's triangle properties, including security, user-chosen names, and decentralization. Until 2011, designing a system that encompassed these three properties was deemed impossible. Innovatively, the advent of DLTs allowed for the creation of secure, censorship-resistant domain name systems independent of any single entity's control. Ethereum, through the introduction of smart contracts, laid the groundwork for the first DLT-based DNS with the Ethereum Name Service (ENS), the architectural overview of which is shown in Figure 3.

Figure 3. DLT-Based DNS Architectural Overview (ENS)

Today, the landscape of DLTs-based DNS systems is vast, including projects such as Unstoppable Domains, Kadena, Handshake, Blockstack, among others, all built on different DLT systems. Notably, these systems inherently adhere to Zooko's triangle properties, embodying the Web3 vision and setting the stage for a truly decentralized and trustless Internet infrastructure.

Security Comparison

Hierarchical and centralized DNS resolution operates on a tiered structure, starting from root servers down to authoritative name servers for specific domains, as illustrated in Figure 4.

Figure 4. Hierarchical vs DLT-Based DNS Resolution

This hierarchical and centralized approach ensures consistency and speed in resolving domain names to IP addresses. However, it also presents potential vulnerabilities such as centralized points of failure, susceptibility to censorship, and reliance on a third party. Centralized points of failure facilitate attacker activities, since they need to target only specific choke points to disrupt or manipulate the system. In essence, while the hierarchical DNS system has been foundational for the functioning of the modern Internet, its centralized architecture introduces several vulnerabilities that can be exploited by malicious actors.

In contrast, DLT-based approaches, as exemplified in systems like the ENS depicted in Fig4, distribute data and resolution processes across multiple nodes, enhancing resistance to censorship. Without centralized choke points, it becomes exceedingly challenging for any single entity to suppress or block specific domain information. Moreover, the use of cryptographic methods and smart contracts for domain registration and resolution in DLTs-based systems ensures a higher level of authenticity and trust. Malicious actors can't easily impersonate or manipulate domain data when it's cryptographically secured and verified by multiple peers.

The DLTs-based approach not only enhances resistance to censorship and reduces single points of failure but also avoids the need for reliance on a third-party service. It offers added security benefits but necessitates new methods for domain resolution. To access these DLTs-based domain names, users typically require specific browsers or browser extensions that can interpret and route to these domains. As DLTs mature, solutions to these challenges continue to emerge, making DLTs-based DNS a promising alternative for a more resilient and open internet.

In Table 1, we present a comparison between hierarchical and centralized controlled DNS and DLT-based DNS, delineating their distinct features, advantages, and potential weak points within the domain name system landscape.

Table 1. Comparison of Hierarchical and DLT-Based Solutions

Hierachical and Centralized DNS Hijacking Attacks

In this section, we will explore a series of exploits carried out against hierarchical and centralized DNS systems, which directly impacted Web3 platforms. Firstly, we will describe a DNS hijacking attack. Then we will present two examples of how malicious actors leverage these tactics in attempts to steal users' wallet seed phrases. Finally, we'll illustrate a series of incidents to show how malevolent actors use DNS hijacking to present webpages that closely mimic the genuine ones crafted by project developers.

What is a DNS Hijacking Attack?

DNS hijacking is an attack targeting a core component of Internet infrastructure. In some cases, it could make a public DNS unavailable for use, while in other instances, it can be used to redirect users to a malicious website, as in the case of the previously mentioned incidents. Typically, the attacker tampers with the DNS, replacing the mapping (DomainName, Legitimate IP) with (DomainName, MaliciousServer IP), in order to resolve future users' DNS queries to redirect them to bogus websites without the users' notice, as shown in Figure 5. Users, then, unknowingly access these malicious sites navigating the compromised servers, facing potential phishing attacks and malware downloads that can compromise the user's device.

Figure 5. DNS Hijacking Attack

Seed Phrase Phishing

CreamFinance and PancakeSwap

On the 15th of March 2021, both Cream Finance and Pancake Swap reported DNS hijacking attacks.

Users trying to access the CreamFinance and PancakeSwap frontends were redirected to malicious websites, which were requesting users to insert their seed phrases, resulting in a phishing attack with the aim to drain their wallets.

In the particular case of CreamFinance and PancakeSwap, the public DNS GoDaddy was compromised. The GoDaddy DNS CNAME record had been corrupted and was not pointing to their hosting IP. To quickly resolve the issue, both teams migrated their DNS to Cloudflare.

The root cause of the DNS attack was that the GoDaddy login credentials were compromised. Thus, both projects experienced a security breach due to the vulnerabilities inherent in third-party key management, with the hacker trying to steal users' wallet seed phrases.

Polygon and Fantom Wallet

Onthe 1st of July 2022, two public RPC gateways offered by Ankr for Polygon and Fantom wallets were compromised via a DNS hijacking attack.

As a result of the attack, users accessing the blockchains through Ankr’s endpoints became victims of a phishing attack, with the malicious websites asking them to urgently reset their seed on the PolygonApp with the aim of draining their wallets.

In this particular case, Ankr’s centralized entity Gandi fell victim to a social engineering attack that compromised their key management process. As a result, the third-party service agreed to change the email address for the domain registrar account. Consequently, the third-party DNS provider gave the malicious user access to Polygon and Fantom's domains, allowing the hacker to corrupt the record pointing to their hosting IP, changing it to the malicious website.

Polygon and Fantom stated they had no control over services provided by Ankr. Again, the root cause of the DNS hijacking attack was that Gandi's key management process was compromised. Thus, the project experienced a security breach due to the vulnerabilities inherent in third-party key management, with the hacker trying to steal users' wallet seed phrases.

Website Cloning

In the next series of exploits, while the core of the attack remains the same, the twist lies in the alteration of smart contract addresses stored in the Web3 projects’ frontends' webpages. As a result, users unknowingly interact not with the legitimate contracts but with rogue ones under the control of these adversaries.

MM.Finance

On May 4th, 2022, MM.Finance, a Cronos-based DEX, reported a frontend breach. Later on, the incident was acknowledged to have been the result of a DNS hijack attack.

The attacker was able to modify the MM.Finance frontend webpage, replacing the project router contract with a malicious contract address. As a result, users interacting with the manipulated frontend and calling functions like Swap, Add Liquidity, and Remove Liquidity had the output funds redirected straight into the attacker’s wallet. The malicious webpage remained accessible for approximately three hours before being taken down by the team. The attack resulted in a total loss for users of $2 million in assets that were then bridged over to the Ethereum network and laundered in Tornado Cash. During the exploit, team members on Discord warned users against using the compromised frontend site.

Diving deeper into the specifics of the MM.Finance incident, it emerged that their chosen domain service provider, Namecheap, had been compromised as a result of phished credentials. Thus, the record mapping the MM.Finance frontend domain to the legitimate IP address was corrupted, pointing to the malicious webpage. The code was cloned from the original one and slightly modified to replace the project router contract address with the malicious one.

Curve Finance

On August 9th, 2022, Curve Finance, a major DEX that largely offers stablecoin swaps, reported a DNS hijacking attack affecting their frontend.

The attacker was able to modify the project's frontend webpage with a malicious one. As a result, when users interacted with the manipulated frontend, they believed they were approving transfers through the project's official contracts. In reality, they were unknowingly granting approval for their funds to be directed to the attacker's deployed contract address, which, when approved by the victim, would completely drain the user's wallets. Curve Finance users suffered a loss of approximately $570k.

Once again, the credentials to access the DNS record of the project frontend, maintained by the project's chosen third-party domain service provider (in this case, Iwantmyname), were stolen. As a result, the attacker could replace the record that mapped the project's frontend domain to its legitimate IP address with the IP of malevolent webpages. The webpage's code was subtly altered to change the legitimate address to be approved for swapping operations with the malicious one.

SpiritSwap and QuickSwap

On May 13th, 2022, SpiritSwap, an AMM on Fantom, and on May 14th, 2022, QuickSwap, a DEX on Polygon, reported frontend breaches caused by DNS hijacking attacks.

The attack was similar to the one suffered by CurveFinance, with the attacker slightly modifying both projects' frontends' webpages. Thus, users interacting with these manipulated frontends believed they were approving transfers through the projects' official contracts. However, they were unknowingly granting approval for their funds to be directed to the attacker's address, who later performed the swaps. SpiritSwap reported a total loss for users of $18,000 before discovering the ongoing attack and shutting down their swapping method through their router to prevent the attack from continuing. QuickSwap reported a total loss of $107,600 for its users before being able to migrate their DNS hosting to a different service provider.

Once again, both incidents were linked to the theft of credentials from their chosen domain service provider: GoDaddy. Indeed, a GoDaddy representative was manipulated through social engineering, allowing for the unauthorized takeover of the SpiritSwap and QuickSwap domains.

Convex Finance and Ribbon Finance

On June 24th, 2022, Convex Finance, a yield optimizer platform and liquidity provider on Curve Finance, and Ribbon Finance, a suite of DeFi protocols, reported their frontends to be compromised as a result of DNS hijacking attacks. The attackers replaced familiar-looking UI buttons that communicate with smart contracts in different parts of the site, redirecting users' interaction towards malicious contracts. The deceptive nature of these contracts was enhanced by mimicking the original addresses' first and last four characters, making a quick visual inspection insufficient for detection. Additionally, these nefarious contracts weren't consistently displayed to all users and varied in their placement within web elements. Ribbon Finance reported a loss of 16.5 WBTC, worth around $400K at that time, as a consequence of the attack.

In this case it was a different domain service provider, Namecheap, that suffered the theft of credentials related to the hosted domains. Interestingly, during these breaches, the attacker managed to take control and penetrate the domain service provider account, despite the account being safeguarded by a robust password, 2-factor authentication, and active security alerts. The ConvexFinance team regained access and found both the 2FA and password unchanged. However, the malicious actor had still managed to gain entry, redirected the DNS record to their malicious site, and suppressed the security notifications.

DefiSaver and Allbridge also suffered similar attacks on the same day, involving modifications to DNS records. All of these were registered under Namecheap.

Lessons Learned

The series of incidents related to DNS hijacking has provided the industry with valuable insights and lessons, which can be applied to build more robust and resilient systems:

Recurring Third-Party Vulnerabilities

Problem: These incidents underline the persistent challenge of DNS credential theft and highlight vulnerabilities introduced by third-party domain service providers in web3 projects. The core web3 protocols themselves were not inherently flawed; it was the traditional, centralized domain infrastructure that left them exposed.

Solution: Adopting decentralized solutions and considering new technologies can mitigate these risks.

Human Error and Social Engineering

Problem: The theft of credentials through phishing or social engineering demonstrates that technological defenses are often not enough. Human error or oversight remains a significant weak point.

Solution: Training, awareness, and regular security reviews are crucial components in any cybersecurity strategy. Understanding potential weak points and ensuring ongoing vigilance can make a difference.

Decentralized and DLT-Based Systems as a Solution

Transitioning to decentralized frontends is a practical way to overcome these challenges. This combination prioritizes content-addressed storage over traditional location-based addressing, providing several key benefits:

• Integrity Verification: Ensures that users access the exact website intended by the project owners. The content undergoes a hashing process, and the hash is stored across multiple nodes within an IPFS cluster.

• Resilience and Security: Significantly minimizes the risks associated with centrally controlled DNS systems and compromised servers, offering a more resilient and secure web-browsing experience.

• Redundancy and Independence from Third-Parties: The decentralized nature ensures redundancy, security, and integrity of the data, eliminating the need to rely on third-party service providers.

To address the DNS hijacking vulnerability and significantly decrease the chances of future breaches, CreamFinance took a decisive step following the incident. They transitioned to a decentralized frontend harnessing the combined power of the IPFS and ENS. This combination prioritizes content-addressed storage over traditional location-based addressing.

In essence, it ensures that users access the precise website intended and deployed by the project owners. The website's content, upon deployment, undergoes a hashing process, and its resultant hash is then stored across multiple nodes within an IPFS cluster.

As illustrated in Figure 6, the process begins when a user's web browser makes a request for a webpage. Instead of relying on traditional DNS servers that point to IP addresses, the system consults the ENS for the content hash associated with that domain. With the hash in hand, the browser then queries the IPFS network, which replies with the node location where the hashed content matches and is stored. At this point the browser can contact the IPFS node that holds it and verify the integrity of the received content, contrasting its own hash with the intended one.

Figure 6. IPFS + ENS Content Resolution

This procedure ensures that users always get the exact, unaltered content associated with a given hash, irrespective of which IPFS node serves it. This approach significantly minimizes the risks associated with centralized DNS systems, offering a more resilient and secure web-browsing experience. Additionally, this decentralized approach ensures redundancy, security, and integrity of the data while eliminating the need to rely on a third-party service.

Decentralized systems – like the combination of IPFS and ENS - can act as potent countermeasures against such attacks. Enforcing access to the actual content of webpages by leveraging content-based hashing opposed to traditional location-based methods could have prevented all of the incidents described.

Key Takeaways

Below, we summarize the recommended best practices for both development teams and end-users:

Teams

Recommended best practices for project teams include:

• Deploy Frontends on IPFS: This practice ensures that users access the actual content they are looking for by leveraging content-based hashing instead of traditional location-based methods.

• Leverage ENS or Similar Systems: Connect your IPFS record to an ENS or a comparable system. This approach simplifies access for users (they can use a domain name rather than a lengthy IPFS address) and also provides protection against censorship through DLT-based DNS.

• Prioritize Security: If choosing a conventional domain, follow the best practices set by the Internet Engineering Task Force (IETF) like DNSSEC. Also, integrate DNSLink to map your traditional domain to an IPFS hash, combining the familiarity of conventional web hosting with the robustness of decentralized hosting.

• Audit Your DNS and Hosting Setup: Regular audits can detect potential vulnerabilities or early misconfigurations, minimizing the risk of attacks.

• Continuous Monitoring: Implement tools that monitor and alert your team to any unauthorized changes or suspicious activities within your hosting setup.

Users

Recommended best practices for users include:

• Guard Your Seed Phrase: Never reveal or share it with anyone, as it is the master key to your digital assets.

• Double-Check URLs: Make sure you are visiting the official website, especially before entering sensitive information. Watch out for slight misspellings or unfamiliar domain extensions.

• Navigate the Internet Safely: If you need to access platforms that require sensitive data, like wallet seed phrases, over public Wi-Fi, use a virtual private network (VPN) to encrypt your connection, improving (though not ensuring) your privacy and security.

• Stay Informed: Regularly check the project's official communication channels to stay updated and confirm that there are no ongoing, acknowledged security issues or attacks when sensitive information must be inserted.

Conclusions

The series of incidents described emphasize that projects at the forefront of Web3 innovation are not exempt from vulnerabilities inherent in traditional, centralized Web 2.0 infrastructure.

The conventional architecture of the internet, with its centralized systems, exposes vulnerabilities that are increasingly exploited in the Web3 sphere. As these projects, including DeFi, grow in value and use, they become more attractive targets. Although the technology supporting Web3 is robust, the supplementary systems, especially domain service providers, are becoming weak links. The move towards decentralized infrastructure, along with continuous strengthening of both human and technological defenses, has become essential for the future security of Web3 projects and their users.

Adopting the combination of IPFS and ENS demonstrates the potential of decentralized and DLT-based solutions in mitigating DNS hijacking attacks. These systems emphasize content authenticity, reduce failure points, and significantly lower the risks tied to centralized control and authority. As the digital world moves towards a more decentralized future, it is vital for projects to utilize the strengths of DLTs and related technologies to protect their ecosystems and user interests. These innovative solutions are laying the groundwork for a more secure and decentralized internet infrastructure.