Earlier this week, on November 1, the domains of crypto lending platform Frax Finance were hijacked, with attackers attempting to seize control and redirect traffic to malicious domains. Fortunately, the project team was able to promptly regain control of these domains, and there were no reported incidents of user funds being compromised.
Zooming out from this incident, attacks like these – known as “DNS attacks” – are becoming a rising threat in the world of cryptocurrencies. Given the industry’s digitized nature and flow of capital, hackers have a lot to gain from exploiting security vulnerabilities. To help ensure the safety of funds, it remains imperative to educate users and project developers on the latest scam methods and risk control measures.
In this article, we provide an overview of the recent Frax Finance attack and what can be learned from this incident, diving deeper into the background of DNS attacks and how to prevent them.
What Is a DNS Server?
First, let’s explore how a domain name system (DNS) server works. DNS servers are one of the fundamental tools that allow people to browse the internet with ease. DNS servers translate domain names into the numeric Internet Protocol (IP) addresses that represent their location on the internet.
Whenever someone types a domain into their web browser, such as “www.binance.com,” their device sends a query to a DNS server asking for the IP address. Typically, this query will go through multiple DNS servers until it finds the corresponding address.
One can think of the internet as a massive, intricate highway system, with each road leading to a different website. On these roads, DNS servers function as traffic officers, guiding cars in the right direction. Navigating the internet without DNS servers would be like driving in a foreign country with no maps, GPS, or street signs — everyone would end up at the wrong destination.
DNS Attacks
DNS servers are built on trust. We trust that the system will bring us to the right website. As such, we enter sensitive material on these websites, including login credentials, personal information, or even bank account details. Now, what if an attacker were to compromise these servers for malicious purposes?
A DNS attack occurs when a malicious actor tries to redirect you from a legitimate website you want to visit to a fake website they control. Similar to our highway metaphor above, it’s like if someone changed the road signs, so instead of getting you to your home, they led you to a robber’s house.
DNS attacks can be conducted in a variety of ways using different methods and techniques, usually to disrupt services or steal sensitive information. Two of the most common techniques in DNS attacks include cache poisoning and domain hijacking. In the former case, attackers provide false information to a DNS server to redirect traffic away from a legitimate website to a malicious website they control. In the latter case, attackers gain control of the domain itself without the legitimate owner’s permission.
The Frax Finance incident
In the case of the recent Frax Finance attack, hackers attempted to seize control of the “frax.com” and “frax.finance” domains. Once they detected the attack, the project team reacted quickly to inform its community on X (formerly Twitter), advising users not to interact with the compromised domains.
Additionally, they were able to contact their DNS provider (Name.com), who promptly regained control of the domains and routed them back to their proper nameservers and configurations. Though the root cause of the incident is still under investigation, no loss of user funds was reported.
SSL Certificate Mismatch
A Secure Sockets Layer (SSL) certificate is like a digital passport for websites and is essential for cybersecurity. Just like a passport confirms your identity when you travel, an SSL certificate confirms the identity of a website to your computer. SSL certificates also ensure that information being sent between a computer and a website is encrypted so that no one else can read it. This is particularly important when dealing with sensitive information, such as login credentials.
When a DNS server is compromised, it will try redirecting users to a different website. An SSL certificate mismatch would then occur, effectively alerting the user that something is wrong. Let’s illustrate this with an example.
Case in point
Assume there is an original domain named “binancedefiapp.com” that is hosted on a server with an IP address of 192.168.0.1. Suppose the DNS server is compromised. A malicious actor changes the DNS entries so that “binancedefiapp.com” is now hosted at the IP address 192.168.2.2, where the attacker has set up their own malicious version of the website. Yet, they still require an SSL certificate to make their website seem secure.
A primary red flag should be raised if the connection is not secure and it returns a plain Hypertext Transfer Protocol (HTTP) address rather than encrypted Hypertext Transfer Protocol Secure (HTTPS) traffic, which is usually recognizable with a green lock in the address bar of the browser interface (or a similar icon).
The attacker is still unable to set the SSL certificate for “binancedefiapp.com,” since a single DNS server is compromised. To generate a valid certificate for a certain domain, they still need to prove ownership of that domain to a third-party issuer, which won’t be possible as the attacker owns just one DNS server. In this case, even if there is a certificate, it will not match the hostname, as the attacker would have to stay with a certificate issued for another domain. When visiting such a website, the user’s browser recognizes if the certificate is issued for the visited domain or not. In the case of a mismatch, it throws up the following error:
If something like this pops up, users should not proceed to that website.
Internal and External DNS Servers
There are multiple DNS servers on the internet, so it is not possible to poison all of them. Internal DNS servers, for example, those residing within a closed internal environment (a company’s corporate network or custom DNS server), may be targeted more easily than public DNS servers, such as open Google resolvers.
While there could be some chance of poisoning Google DNS servers, the probability of this occurring is generally quite low. Even if it does happen, a rapid response and alert are more likely to appear. Compare this to standalone or custom DNS servers, which are usually less monitored and less secure. Generally, it is recommended to resolve IPs using Google’s public DNS resolvers or other reliable, publicly available providers.
How to Stay Safe From DNS Attacks
Generally, there are two main types of DNS-related security risks: end-user devices and DNS servers being compromised by hackers. Prevention tips vary for each type.
End-user device being compromised
This security risk arises when end-user devices are controlled or infected, resulting in DNS cache poisoning or domain hijacking. Preventive measures for end-users include the following:
Avoid clicking suspicious links and installing software or browser plugins from unidentified sources.
Avoid using public WiFi networks with uncertain security credentials.
Periodically clear your DNS cache.
Conduct regular scans for malicious software on your devices.
Unfortunately, most things happen on the client or end-user side, and there are basically no definitive means of disposal for project developers. The project side usually has no idea whether their client’s DNS has been contaminated. Apart from setting up subsequent customer complaint channels, the project side can proactively educate clients about such threats.
DNS server being compromised
In this scenario, hackers exploit security vulnerabilities or employ social engineering tactics to gain control over DNS servers, often leading to alterations in domain records. Preventive measures for end users include the following:
When accessing websites, ensure the domain name is spelled correctly.
Verify that the site uses the HTTPS protocol without any browser security warnings.
Before conducting sensitive operations (e.g., entering passwords or mnemonic phrases), reconfirm the website’s certificate for validity.
Utilize browser security extensions offered by reputable security firms. These extensions detect website anomalies and provide warnings when users make infinite approvals or transfers to high-risk wallets.
Measures for the project developer side include the following:
Opt for reliable domain providers with strong reputations, and employ dedicated personnel to monitor and address domain anomaly alerts promptly.
Implement automated monitoring systems to swiftly detect anomalies or malicious scripts and elements in pages on the domain’s DNS resolution results.
Understanding and addressing the potential vulnerabilities in DNS management is imperative. By adopting the recommended measures, both users and project teams can fortify their defenses against DNS-related security challenges.
Protect Your Servers
DNS attacks are a harsh reality in an emerging industry like crypto and have been a growing concern in the cryptocurrency space as of late. The damage they have the potential to cause can be devastating, leaving user funds vulnerable.
Last year, Curve Finance experienced a DNS attack resulting in over $570K in ETH being stolen from user wallets, though the Binance Investigations team was able to help recover the majority of the stolen funds. More recently, we saw major DNS attacks on the Balancer and Galxe protocols occurring in September and October, respectively.
For the cryptocurrency industry to grow sustainably, we must prioritize building a secure ecosystem. We hope both project developers and users alike can learn from this article and understand the importance of safeguarding against DNS attacks. Together, we can build a safer ecosystem for the future of crypto.