Basic Auditing of a Web3 Frontend
Basic Auditing of a Web3 Frontend
Verify the source before you click send on your precious funds
This post is too long for email, please open on the Substack site!
Another significant Web3 hack occurred this week with the ever popular Curve Finance getting their domain records tampered with and a false frontend put it up to steal user funds. This resulted in around half a million dollars being siphoned from users sending funds to an unexpected address that the hacker replaced their own wallet address with. Instead of adding liquidity to a pool your funds were now suddenly gone, whisked away through services such as Fixed Float to hide the attacker. While some of the money was recovered or frozen, it sill does not take the sting away from being cheated. In this article we will talk about methods to protect yourself from these attacks.
What is a DNS attack?
First things first, you need to understand what a DNS is, then understand how to look out for one. DNS stands for Domain Name Services, and it is the primary way on the internet to navigate to web sites. When you type www.google.com into the browser your browser and computer don’t actually know where to physically navigate to in order to load the web page. It is just a friendly name for end users to remember rather than an ugly string of numbers to blindly remember. DNS servers exist on the web in order help figure out where the current IP address is mapped to a site name, and then you use that to actually load a web site. There are far deeper explanations on DNS, but lets keep it basic for now.
If you open the shell on any linux distro you can do this yourself and discover the DNS records of any website through the querying interface. Using the dig command, we can query any DNS server (in this case 1.1.1.1 is Cloudflare) we like and determine the IP address of the site, shown below with: dig @1.1.1.1 curve.fi
As you can see in the result above there are two results in the answer section. What is important to note here is the A Record, which is the record type that maps a domain name, eg curve.fi, to an IP address. In this case there are two IP addresses for Curve, 172.67.220.40 and 104.21.94.56. Imagine what would happen if these A records were tampered with? If someone managed to update these records with a different address, they would hijack the way to navigate to a website and the end user would have no idea. This is step 1 of how the hack happened, the really nasty business starts next.
What can be done with a hacked DNS record?
Remember that a DNS A record only tells the mapping of a website name to an IP Address. When this record is taken over the hacker can then point the site name to a server they control, and now they can start to violate your privacy and work on stealing your funds. They can see your IP address, can trick you to sending sensitive info, and they will have you download malicious software via the browser and execute it. From that point almost any browser exploit is fair game for the attacker since you are loading arbitrary data via JavaScript.
This hacker was far more subtle and instead created a clone web site to siphon funds silently. To end users there would be no perceptible changes in this instance, as the attacker cloned the source code of the site and made minor changes. The only major difference the user saw was a new token approval request from their wallet provider, which might not ring any bells depending on the action the user was taking. This token approval would be for a brand new contract that the hacker completely controlled and could drain the funds out of.
What changed on the cloned site?
If you navigate to Curve’s GitHub repo you can see their entire list of contract Addresses and their purposes: https://github.com/curvefi/curve-js/blob/master/src/constants/pools/ethereum.ts
This is the list of addresses their web site uses when your wallet interacts with the blockchain. What the hacker did here was clone the site’s source code, modify the addresses in the above list to now point to smart contracts that they had full control over, and then deploy the source to the malicious site from the DNS hack. They kept all other code the same so the user interface would not look different. Unless you paid sharp attention to the address being used, or you remember already approving the token contract before, nothing would seem different to the user when using your wallet provider.
How to protect yourself from the hack
Use Social Media to your advantage
Thankfully the word spread very fast that the DNS records were compromised and many high profile users on Twitter were fast to react, with many discord’s also making announcements to users to not use Curve for the time being.
This is your first of many defensive techniques against hackers on the internet. High profile stakeholders, power developers, and security experts like @zachxbt, and the official Protocol’s Twitter and Discord will be the first to sound the alarm if something is off. I highly recommend following the major Devs of any protocol you use as that will be the main medium to alert users to anything bad. This is an easy and quick way to check for hacks before any transaction.
Always use a VPN
Further techniques are much more involved and we will go over them. As a baseline, you should always be running a VPN to ensure your personal address or location does not get tied to your wallet. A great guide comes from @BowTiedIguana on the BowTiedBull Substack:
Always have HTTPS and TLS valid and working
Often when a site’s DNS records are hijacked the hacker wants to do as much damage as possible before the word gets out. This means basic security checks may not be satisfied in order to attack as fast as possible. When visiting a site that uses your wallet, always ensure you have HTTPS and TLS working and that there is a valid certificate. TLS ensures that the connection to the site you are using is encrypted all the way to the server. This prohibits snooping on your information as it is transmitted across the web. While this would not protect you from DNS hijacks specifically, the hijacker may not care about issuing a new certificate in time for the hack, giving you an easy decision to stop using the site. Never connect your wallet to a site that does not have working TLS/HTTPS.
This can be verified easily through the lock icon in any Chrome based browser.
Again, this is only used as a quick check for using any site that transmits personal information. If the end server is compromised, this wouldn’t make a difference. We have more techniques to deal with that situation.
Basic audit the addresses your wallet wishes to approve
This above all is one of the best ways to safely secure your funds. You should never approve a contract for funds without examining the contents of the contract first. This is the main benefit of the Blockchain as all contracts are on chain and can be verified by the end user. Any protocol worth even pennies publicly lists all their smart contract addresses to the end user and provide the uncompiled source code such that anyone can audit it. The techniques for a basic auditing of a contract approval are as follows:
Verify that the smart contract address corresponds to the listed address on official documents, ideally the source code or a third party clearing house.
In the case of a DNS hijack, Curve’s listed addresses could also be modified, which is why you can’t trust their site itself at times.
Use the Source Code and check the commit history to ensure no recent unannounced tampering has occurred.
Ensure the GitHub user is verified and a frequent/known committer to the repository.
Any unverified committer to a major Web3 Project should be taken with extreme skepticism!
Verify the Address on Etherscan has the decompiled smart contract and has been verified by the service. Examine the contract also if you technically skilled to do so.
Notice the “Contract Source Code Verified” for this address
Notice the Contract Source Code Verified (Exact Match) Note: The hacker can still upload a verified contract also, but they may be too lazy to do so. This is an easy check for the end user however.
Look at the address of whoever deployed this contract and ensure they have ties to the corresponding project. Curve lists many of their deployment addresses here, but this site seems to be a little out of date. Note: Etherscan tags/names are not a source of truth!
Notice the Curve.fi: Deployer 2 name tag
Use Etherscan to check for any warnings or other strange behavior as seen on the malicious contract.
If the contract was recently deployed, start looking for more information if this was intentional or not.
Looks for any warnings or public tags on addresses that seem off.
Notice the “Curve DNS Hijacker” name tag. 
Notice the warning banner. Note: Etherscan can be incorrect with these warnings or published name tags, so use them as additional information in your analysis, not the end all be all, especially when events are occurring in real time.
Conclusion
These are the quickest ways to thwart any would be attacker. There are more advanced techniques that are far more technical that will be covered in a subsequent article, but here is a sneak peak from my Twitter:
Note that Curve itself was not hacked, its smart contract remains functional and their actual web site remained working, but not navigable by traditional means. The only thing that was hacked was their DNS record from their hosting provider.
A far more technical description of the hack can be seen at Certik.
If this article was helpful, please subscribe and ensure your funds are safu!