Intro

We all know security is a major concern in Web3 and we’ve witnessed tremendous steps forward due to the billions of dollars that were stolen in the last 4 years. The statement “Don’t Trust, Verify” is being utilized to increase the reliability of protocols by undergoing several audit cycles.

Alas, the security world is more complicated then mere code-vulnerabilities, and trust is still being applied without the right amount of due diligence or counter measures.

In the past months the community suffered from several unique type of incidents. Those incidents, as we’ll outline in this post, could have been avoided with the right counter-measures and with modified trust assumptions

The Problem

You’re an entrepreneur with an idea that is going to revolutionize the financial world with your new DeFi protocol. Obviously, you’d like to deploy as fast as possible and concentrate your efforts on providing the best value for your users as fast as possible. Security is of course a must, but you think it’ll be covered by the auditors.

You’re not an RnD guy yourself, but you’ve hired some top notch web3 contract developers that you found. You’ve also told them that you need it done by yesterday, so they have to re-use as much of publicly available code as possible - meaning forking and libraries usage.

Looking at this process, you can see the problem, this super duper unique protocol is heavily reliant on 3rd party resources. Lets dive into them and give some examples

Libraries

As in any programming ecosystem, smart contract development also rely on 3rd party libraries. The most important of those is of course https://github.com/OpenZeppelin/openzeppelin-contracts. The usage of external libraries accelerates development (where complicated pieces of code are abstracted and continuously re-used).

3rd party library exploitation is a very well known attack vector in Web2, and several security companies try to address this specific issue (the most known of those is Snyk).

In Web3, the external library usage is less excessive, and yet, even the most thoroughly tested libraries are prone to vulnerabilities.

Such a case was in the found thirdweb vulnerability, which resulted from using two different OpenZeppelin contracts together (Multicall & Meta TX, which resulted in the ability for anyone to be treated as the protocol owner). A regular audit wouldn’t have gone into looking for bugs in the library code, let alone a combination of two libraries. This eventually resulted in a critical vulnerability in one of the most widely used contracts in Web3.

Forks

A common practice in Web3 is replicating a protocol and altering it. This is called forking. The benefits are obvious, taking an already developed codebase which has been audited and battle-tested.

But, with great power comes great responsibility.  Since the fork takes a snapshot of the original code at a given time, the fork will not benefit from any security updates being conducted on the original protocol. In any case an exploit is being discovered in the parent contracts, hackers will actively look for forks which share the same vulnerability to exploit.

Such a case was with the the Curve-Vyper hack, in which a critical flaw had been discovered in the curve pool bytecode (resulted from a reentrancy check bug in the vyper compiler). Consequently, protocols using the curve pools code were also breached and funds were stolen from multiple curve-like protocols.

Rouge Devs

Don’t we all love those RnD guys? waking up at noon, working throughout the night, but they do deliver. A capable developer is a crucial point in the success of a protocol.

But, in some cases, the team is not organic. Management are concerned about marketing, sales and strategy, while letting the day-to-day get managed by externally hired subcontractors.

As time goes by, these hired RnD team is gaining more trust and control over the protocol. From deciding on the code architecture and logic to maintaining the management private keys.

In some cases, a proper due-diligence has not been conducted on the personas involved. And the capable developer has a secret agenda. From inserting a code backdoor to deploying an altered version of an already-audited code, everything can happen during an inside job.

Such cases have been outlined in the past.

Solutions

1. Audits

Audits are the first line of defense, but the process contains a lot of pitfalls a protocol owner could fall into.Protocol owners should make sure of the following

• Use a very well known auditing firms with track record - The increasing number of protocols resulted in increased number of auditing firms. Don’t use companies that are known to get hacked (rekt has a hack-auditor DB)
• Insist on auditing third party library integrations - Ask the auditors to test the integration between your contracts and the libraries you’re using. These areas suffer from lack of explicit responsibility and this is exactly what hackers are looking for
• Make sure audited version is the one being deployed - Insist that the auditors will include the final audited commit in their report. Compare the exact commit to the code verified on Etherscan

2. Counter-Measures

• Use other means to test the code - Don’t rely solely on audits for pre-deployment security checks. Include also other means (fuzzing, static analysis and formal verification to name a few)
• Maintain a list of used libraries / protocols you’ve forked from - This will help you keep track of what you should be aware of in terms of library updates
• Keep being informed of major incidents. Specifically those involving contracts you’re using - Once a vulnerability is being discovered, reach out to trusted security groups to check whether your protocol is exploitable.

3. Developers

• Check references of crucial workers - As in any industry, a deep due diligence is a must for those who have access to your most sensitive assets
• Always maintain full control of ownership keys - Do not share the deployment or ownership keys with anyone. A protocol owner should always be in total control of protocol management. If maintenance work needs to be done on the protocol, use multisig contracts to manage it.
• Have a conference call with the developers. Insist on opening cameras (bored apes don’t count) - Those who don’t want to show themselves to their employers often have something to hide.

‍