The Domain Name System (DNS) is the system responsible for matching domain names with IP addresses. Essentially, when you type a domain in the address bar of your web browser, the Operating System works under the hood to forward the request to the DNS resolver of the OS, which in turn forwards the request all the way up to a name server that will resolve the name into an IP address.
The issue with these servers is that as with almost anything on the internet, they can be compromised. Usually the administrators of DNS servers will do their best to keep them secure, but occasionally there can be incidents regarding security. These days especially, most websites rely on external DNS services and the admins of the sites don’t operate the DNS servers themselves. So when a compromise attack happens on DNS servers, the websites that rely on the affected services can suffer from major disruptions without the website admins being directly at fault.
Thankfully smart contract security and decentralization take care of securing user funds in the event of such compromise. Meaning that if no deeper level of compromise occurs, funds deposited in smart contracts operated by the legitimate administrators of the affected services are guaranteed to remain secure. That’s because not only are smart contracts immutable, but the blockchain also allows for interacting with the smart contract directly without relying on any DNS system. (There can be edge cases affecting how immutable a specific contract is, especially if a proxy contract is utilized. If you’re interested in studying that, we already have an article on one such case). But given that under a DNS compromise the malicious party could redirect the incoming traffic to anything they want, several tricks could be used to scam users under the guise of the trusted service.
How PancakeSwap and Cream Finance Were Compromised
On the 15th of March, PancakeSwap and Cream Finance, two of the most major DeFi services built on the Binance Smart Chain suffered from a DNS hijacking incident. What this meant for both is that users attempting to visit the respective domains for these services were redirected to a website the attackers had set up.
For instance, anyone visiting “pancakeswap.finance” on that day would see a website that looked very similar to the original, with a major addition being a prompt that was asking users for their wallet seed; which one could say is a rendition of a Phishing attack adapted to DeFi standards. This alone should have been an obvious sign of a compromise taking place. Even from the get-go of entering DeFi, most users learn that their seed phrase and private keys should be stored securely never to be shared with anyone.
Indeed, the hijackers behind the attack on Cream Finance and PancakeSwap didn’t choose to be subtle. Although, it should be noted that the tactics that could have been utilized in an attempt to defraud users of the affected services aren’t limited to something as blatant as asking for private keys or seed phrases. Especially given that the hijackers have access to redirect the site’s domain to anything, they could have changed the site to look and function as they pleased in more ways.
Based on the above, another simpler trick the malicious parties could have played on users would have been to just post an address on the site and solicit payments to it for some given reason like a non-existent IFO for example.
What To Look Out For
All of the above might sound scary and the sad truth is that as an end user, there’s very little one could do to differentiate between a normally functioning website and one that has had its DNS hijacked, especially if the hijackers are sophisticated. However, given that the essence of DeFi is money moving around, if we try to limit the risk of losing funds, there are some good practices that one could follow to be more secure.
Remember the Contracts
First of all, a good security practice is that you should never blindly trust any platform at any given time. The underlying protocols for DeFi have some safelocks so users can maintain basic levels of security against unauthorized usage of their funds and this is what you should be utilizing to stay safe. The most basic security function would be the token spending approvals.
What that means is, in order for a contract to be able to spend your tokens on your behalf, you need to send out a transaction confirming that you’re giving it permission to do that. Usually most DeFi services are programmed to ask a one-time ever-lasting permission for each one of their smart contracts to spend an unlimited amount of one of your tokens. For example, if you want to provide liquidity for the BUSD-USDT trading pair on pancakeswap, it would ask you for a one time permission to spend each respectively and unless you revoke that permission, that wouldn’t need to be done again.
Now, in the event of a compromise, the hijackers could attempt to hook the interface to entirely different and malicious smart contracts. So if you were certain that you had authorized a smart contract but then all of a sudden it asks you for permissions again, then you should look for answers. As the first layer of defense, you can look into the contract address you would be approving. Search for it in a blockchain explorer, perhaps see the code, but most importantly see if you have interacted with it previously. If it looks entirely unfamiliar, you might want to ask for some re-affirmation from the website’s administrators before moving to approve the contract.
If you’re looking to check the contracts in depth yourself here’s what you could follow. When you click a button to approve spending of a certain token on a DeFi website, it will normally bring up a prompt asking you to verify a transaction that looks like the following image:
Pay special attention to the highlighted area. Note that Metamask currently does not allow users to see the full address of the contract they are approving spending to! This would be an important addition for them to make in order to improve security. If you’re especially wary of a DeFi platform asking you for permission to spend your tokens, you could initially confirm this transaction with a 0 spending limit by hitting edit next to the “Permission” section and changing the value manually. Alternatively you could use a different wallet which shows the full address when confirming spending limit transactions. For example, see image below for how it would look in the official Binance Smart Chain Wallet:
Finding Answers and What To Trust
In order to get up to date information about any project, it would be good to have their alternative communication channels stored. In the event of a suspected compromise you could for example visit their Telegram, Twitter and/or blog site to get updates. If the project’s social media accounts say that the main site is compromised then you should definitely avoid it for the time being.
Do note however, that since a DNS compromise can even redirect the platform’s domain to other servers, it could also signal a compromise of their email, which could in turn lead to social accounts being compromised unless they were secured by other means also. For example, Medium has email-based authentication for sign-ins, so if the email is compromised there’s a slight chance for the Medium account also being compromised. This could also happen to Twitter. This is a very remote scenario given that most platforms use 2FA these days, but it’s good to have it in mind. In such edge cases, Telegram groups and channels might be better for relaying information given that phone numbers don’t rely on DNS.
What To Do if You Had Visited the Website During the Compromise
First things first, unless you had sent transactions to the site while it was compromised, then it’s unlikely that you’ll be at risk of losing money. If you had interacted with the site during the incident however, it’s important to flush your previous token spending authorizations. You can do that from BSCScan or Beefy. Additionally, it would be good to delete cookies stored for the affected site and flush your browser’s cache if you had visited the site during the compromise.
Finally, something that could help improve your general security when browsing the internet would be to use a VPN service. That way, even if you happen to come across a website while it’s being compromised, the malicious parties would have no way of finding your local IP address.
When Are Websites That Had Their DNS Compromised Safe To Use Again?
You should monitor the secure communication channels the service in question has, preferably Telegram. However, before you try to interact with the website, be wary of everything that we’ve warned about above. In short: never provide your seed phrase or private keys to anyone for any reason and be wary of contracts you thought you had already approved. This is especially true for the hours and day after the incident because DNS servers can take more time to propagate to certain parts of the world, which could mean that you might still be getting the malicious website when visiting the domain.
For the record, it should also be noted that PancakeSwap and Cream Finance both said that their services had returned back to normal after the DNS hijacking incident. By now it should be safe for anyone to visit and use their respective websites.
One could say that this incident goes to highlight the security that smart contracts bring in finance. Even in this incident where bad actors were able to redirect all users intending to visit PancakeSwap and Cream to web-spaces designed with mal-intent in mind, no locked-in user funds were actually harmed and no vital user info was stolen given that DeFi apps don’t need to store personally identifying information. This is a security feature that comes by design with smart contracts. Funds are protected by transparent and immutable smart contracts backed by cryptography and no user information such as KYC needs to be stored on any server. However, this incident also highlights how some trivial UX improvements in DeFi tools such as wallet extensions could improve ease of use and tighten security for all users even when the fragile security of web-based services is compromised.