paint-brush
Web3, Good Hygiene, and the Need for End to End Securityby@ronghuigu
1,369 reads
1,369 reads

Web3, Good Hygiene, and the Need for End to End Security

by Ronghui GuJune 13th, 2022
Read on Terminal Reader
Read this story w/o Javascript

Too Long; Didn't Read

New blockchain projects treat their security checks as something to get out of the way before their launch, never to be thought of again. Projects that do this seem to think that audits are more for marketing purposes than actual security. The FEG (Feed Every Gorilla) meme token was recently hit by two flash loan attacks which collectively drained $3.2 million USD in funds from the protocol over the course of two days. A good smart contract audit should provide a comprehensive evaluation of a project’s underlying code, but it cannot evaluate any changes or updates that occur after the audit has occurred.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - Web3, Good Hygiene, and the Need for End to End Security
Ronghui Gu HackerNoon profile picture


Having a smart contract audit is a lot like washing your hands– do it only once, and be prepared for the consequences.


As the conversation around crypto security gets heated in response to a devastating year of losses to cybercrime – CertiK’s recent report notes that “2022 is set to be the most expensive year for web3 on record”– it is vital to review some security best practices. Chief among them is the importance of thorough, and regular smart contract audits.


All too often, new blockchain projects treat their security checks as something to get out of the way before their launch, never to be thought of again. This haphazard attitude is seen clearest in projects that have only had a single smart contract audit. Projects that do this seem to think that audits are more for marketing purposes than actual security. While it is true that investors and users alike should steer clear of projects that haven’t had any kind of smart contract audit, they should also make sure that the projects they invest in are taking an active, end-to-end approach to their security.


You may be wondering ‘why should a project need regular audits at all? Shouldn’t one cover the project in its entirety?’. This is a common (and expensive) misconception. While any good smart contract audit should provide a comprehensive evaluation of a project’s underlying code, it cannot evaluate any changes or updates that occur after the audit has occurred, especially any time that a change is made to the underlying code.


Of course, any tech project that never updates will soon become redundant, and this is especially true in the fast-moving world of web3. Any good tech investor or user knows to avoid a project that refuses to update and develop, yet they regularly put their money in projects that never (or rarely) update their security. To return to the cleanliness metaphor, this is like shaking hands with someone after they say they haven’t washed their hands in a year.


Take the Deus Finance exploit as an example, which saw an attacker drain close to $16 million USD in funds. While Deus did have their smart contracts audited, an attacker was able to target a new unaudited smart contract with a sophisticated flashloan attack. Throughout the attack, the hacker was able to change the price of Deus' DEI tokens and reap the benefits of this predictable price action. They did so by manipulating a lending pool that was used by the oracle - a node of code that interprets data - that dictated the price of the token.


Now, any smart contract worth its coin would warn you of the dangers of using an oracle that determines a price by using a trading pair as these can be easily manipulated. However, since the vulnerable smart contract was outside the scope of the initial audit, auditors were not given a chance to highlight the problem.


Deus should serve as a clear warning to projects that they must treat smart contract audits as an ongoing feature in their security framework and have them audited every time a significant change is made to the project. Yet, not all audits are equal. Time and again we see well-planned projects suffer from the flaws of bad auditing.


Take the recent FEG exploits as an example. The FEG (Feed Every Gorilla) hyper-deflationary governance meme token was recently hit by two flash loan attacks which collectively drained $3.2 million USD in funds from the protocol over the course of two days.


In each attack, the hacker (or hackers) targeted the same vulnerability in FEG’s smart contract. CertiK’s analysis of the exploit discovered that this was due to a flaw in the token’s [[Swap-To-Swap function](https://docs.fegtoken.com/fegex/smartswap#:~:text=Swap%2DTo%2DSwap%20(S2S,found%20in%20the%20next%20section), which directly takes user input “path” as a trusted party without any sanitation. In simple terms, this flaw allowed the hacker to repeatedly call functions that allowed them to gain unlimited allowances and drain the contract of its assets.


Perhaps most frustratingly for FEG, is the fact that this flaw should have been detected by a smart contract audit. Even though FEG did have their smart contracts audited, the auditors should have noticed that FEG’s untrusted “path” parameter passed to the protocol and approved for spending assets of the contract. Any good audit would then flag this as a major severity and advise the project to act and edit accordingly.


There is a lesson to be learned here for the crypto-security industry– that, as hackers continue to find new and ingenious ways to exploit projects, it is no longer enough for auditors to just update their checks in response to new attacks. Instead, they must constantly be updating their technology so that when a new attack happens they are prepared for it.


Both of these exploits highlight not only the need for rigorous and regular smart contract audits but also the need for a proactive, consistent, end-to-end approach to web3 security.  This amounts to a shift towards viewing security as something to be built and maintained rather than just a label to be bought and sold. This applies to the teams who need to be updating their project’s security in tandem with their technology, and also to auditing companies who need to be anticipating attacks, rather than just responding to them.