Yet another Re-entrancy attack - What's keeping us from being a better Smart Contract Developer?
Tags: blockchain, security, solidity, ethereum
Published: 2022-10-10 05:34:17

It's been **_6 years, 3months, and 25 days_** since the infamous DAO hack that shook the entire web3 world.

The one where we witnessed more than 3.5 million Ether being stolen away due to a bug in the smart contract.

This hack introduced us to one of the most dangerous attacks, **_The Re-Entrancy attack,_** possible in a smart contract.

Since then there have been enormous improvements and attempts to mitigate the risk of introducing such attack vectors in smart contracts.

Automated testing tools started including warnings about re-entrancy bugs, smart contract auditors became particularly cautious with codes dealing with external calls, and loads of blogs as well as video content were created (_and are still being made_) explaining the re-entrancy attack.

However, if you have observed the exploits in the past few years, along with all other new attack vectors, re-entrancy exploits are still a major concern and can be seen as a considerable bug behind many smart contract exploits.

In fact, the latest re-entrancy exploit that I read about was just a few weeks ago when [Stader’s NearX smart contract was exploited](https://twitter.com/BeosinAlert/status/1559760874184646657) with the exact same very well-known re-entrancy bug & $830,000 were lost.

Well, this isn’t just about re-entrancy bugs in smart contracts and neither is the blog going to explain re-entrancy bugs ( _not again_ ).

Re-entrancy attacks are just one of the many well-known attacks that the smart contract dev community is well aware of but we find traces of such bugs in smart contracts even today, which leads to incredibly massive exploits.

## Now the question is — **WHY?**
==============================

Despite having enormous tools, libraries, and educational content around such common bugs and attack vectors in solidity, why do we still witness such well-known attacks time and again?

This is undoubtedly one of those broad or open-ended questions that might have multiple narratives or answers.

However, after being involved in multiple smart contract security audits now, interacting with quite a few smart contract devs, and being part of some really active smart contract developer communities, I came across 2 extremely simple but imperative reasons behind this.

Most importantly, these reasons revolve around the very basics of how we approach Smart Contract development and learn Solidity, especially in the initial stages.

## **1\. The “_Security-is-NOT-my-job_”** mindset
==============================================

It can unquestionably be stated that the majority of the developers in the web3 space believe contract development and smart contract security to be two different things, which is true, to some extent.

However, completely denying any correlation between these two things is probably a mistake.

The rationale behind this is the fact that, at the very heart of it, the process of smart contract development broadly includes 3 most significant steps:

*   **Design & Development**
*   **Optimizations**
*   **Security Validations of the Contract**

While we are quite well aware of the first two steps, we most often forget, or even worse, do not consider **_Security Validations_** to be part of the contract development procedure at all.

It’s concerning because even if we consider a basic fact about smart contracts, i.e., their immutable nature after on-chain deployment, we can quite clearly see the significance of adding **security checks and validations** as a mandatory step in the smart contract development process.

The fact that you cannot change a line of code in your contract even if you found a major bug just seconds after deployment, is daunting in itself.

> Well, just in case you think you can always upgrade your smart contracts or upgradeable contracts are extremely secure, **let me stop you right there. _🛑_**
> 
> **_Read about the_** [**_Wormhole Proxy Bug_**](https://medium.com/immunefi/wormhole-uninitialized-proxy-bugfix-review-90250c41a43a) and think again.
> 
> **Upgradeable contracts can have bugs too. _🪲_**

### **What should you do?**
-----------------------

In very simpler terms, consider **_security checks & validations_** as an imperative part of any smart contract you develop, and learn at least the basics of smart contract security if you haven’t already.

Once you consider this, you can no more rely on just writing test cases for your smart contracts.

Test scripts are undoubtedly helpful, however, they are more inclined towards ensuring the contract functions execute as intended while the security of a contract is much more than that.

Even as a smart contract developer, you should definitely be good with at least one of the following (_actually more than just 1_) security tools to validate the security of your contract:

*   **_Static analysis tools like_** [**_Slither_**](https://github.com/crytic/slither)**_,_** [**_Mythril_**](https://github.com/ConsenSys/mythril)**_,_** [**_Mythx_**](https://mythx.io/)**_._** These tools effectively help you identify any well-known smart contract bugs that you might have in your contract.
*   **_Fuzz Testing tools like_** [**_Echidna_**](https://github.com/crytic/echidna) **_or_** [**_Harvey_**](https://mariachris.github.io/Pubs/FSE-2020-Harvey.pdf)  help identify potential exploit scenarios or contract execution failures by throwing random & unexpected data into your contract.
*   [**Scribble**](https://github.com/consensys/scribble), which is an amazing runtime verification tool by [ConsenSys](https://medium.com/u/6c7078bf7b01?source=post_page-----4b3decc52b46--------------------------------) that allows you to annotate a solidity smart contract with crucial properties.
*   While auditing complex & bulky smart contracts, the one thing you need the most is a _visualization tool_, and that’s exactly where [**Surya**](https://github.com/ConsenSys/surya) comes in.  
    It provides an incredibly simplified version of all crucial details about a contract’s structure including call graphs, inheritance graphs, etc.
*   [**VS Code visual auditor**](https://marketplace.visualstudio.com/items?itemName=tintinweb.solidity-visual-auditor) extension is an extremely helpful tool that provides security-oriented syntax as well as semantic highlighting and quite a few other tools that make the secure development of contracts easier.

> My favorites → **Slither, Surya, VS Code visual auditor, and Echindna**. _😎_

### **Why should you do it (_If you can get contracts Audited_)?**
--------------------------------------------------------------

Well, to begin with, no one will ever care about the security of your smart contracts more than you (_and your team_). The very first person responsible for the security of your code should be **YOU**.

Secondly, the smart contract audit industry has been (_and still is_) in a “ **_High Demand & Low Supply of good security auditors_ “** phase**.**

This basically means there are just a handful of extremely experienced auditors and relying on just a few of them won’t really be scalable enough for the web3 world to expand its boundaries exponentially.

Additionally, there is a huge line of projects waiting for their contracts to get audited, which is why, when it's your turn you need to be ready with the right set of contracts, adequate test cases, coverage reports, and most importantly, the crucial discussion points you might want to have with your security auditor.

However, you won’t really be capable of having any effectual discussion with smart contract security experts if you yourself don’t understand, at least, the basics of smart contract security.

The inclusion of the **_security validations_** step in your smart contract development journey allows you to filter out all the well-known bugs beforehand with the help of static analysis tools.

This allows security auditors to specifically concentrate on the more important potential threats of the contracts instead of identifying and reporting the ones that could be easily found with the tools mentioned above.

Therefore, performing your own security checks before an audit doesn’t just shorten the lengthy audit durations, it helps achieve an adequate & better result out of the whole procedure.

This is a concept that the [_Secureum community_](https://secureum.substack.com/) brilliantly defines as [CARE (_Comprehensive Audit Readiness Evaluation_)](https://github.com/secureum/CARE) which intends to prepare your contracts before an audit to ensure that the outcome from the security audit is comparatively better and effective.

> It’s important to note that i**_ncluding security as a part of your smart contract development process isn’t a substitution for an audit of your contract, but a preparation for an adequate security audit._**

## 2\. Avoiding Mistakes & Experimentations with Solidity (_and the lessons that come from them_)
==============================================================================================

Alright, while the first point was for developers already familiar with solidity(_and basics of smart contract security_), this part is more inclined towards those starting out with learning solidity or the ones in the very early phases of smart contract development.

_Here is a quick tip for you:_

> Along with learning and developing simple solidity smart contracts, don’t be scared of experimenting and making mistakes while learning solidity.

Since its inception _Solidity_ or smart contract development, in general, has been incredibly interesting but daunting as well as difficult for many developers at the early stage because of some very obvious reasons:

*   _The_ **_immutable nature of Smart Contracts_** _and the idea of getting almost everything right in one single shot before on-chain deployment._
*   _The open-source nature of smart contracts and the fact that every single line of code is_ **_accessible/readable by anyone._**
*   _The whole concept of_ **_programming and storing money within Smart Contracts_** _and the_ **_security risks_** _that come with it._
*   _Solidity still being at a very_ **_nascent stage_** _and the difficulties in keeping up with the rapidly changing/evolving language._


![](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/phgubedtawmuk5n93e5t.jpeg)

Now, the concerns and risks associated with making mistakes while developing a smart contract can’t be overlooked. However, these have an adverse effect on the journey toward learning smart contracts effectively.

With so much at stake, it becomes harder for developers to **_experiment with Solidity or make mistakes on their own._**

The popular idea of “**_Not reinventing the wheel or trying something new, to avoid introducing new bugs in the contract”_** stops developers from exploring different concepts of solidity and thus limits their potential with smart contract development, as a whole.

In fact, it is now considered a lot safer to simply fork an already existing audited contract instead of writing one from scratch. While this definitely does minimize the risk of contracts having bugs in production, it does stop developers from dealing with all the complications one might(_and should_) go through while developing the same. And, therefore, keeps us from deep-diving into solidity concepts more often than not.

While simply following a blockchain development course or consuming online content on smart contracts might help you get started with any specific topic, it won’t let you dive in deep and learn the fundamentals. _Not unless you get your hands dirty with the same._

Most importantly, not experimenting with Solidity smart contracts also keeps us from learning about the various kinds of security vulnerabilities a contract might have and the plethora of ways a contract can be broken.

_For instance, going back to the re-entrancy example:_

> Every smart contract developer might have heard, read, or discussed the reentrancy attack vector, but how many of us actually went ahead and tried to experiment with the same on some dummy contract, just to understand what happens behind the scenes?

This is precisely where smart contract security-based war games or CTFs like [_Ethernaut_](https://ethernaut.openzeppelin.com/) _or_ [_Damn Vulnerable Defi_](https://www.damnvulnerabledefi.xyz/) also play such a significant role in learning smart contract development and security. They allow you to directly interact with a contract directly, make mistakes and eventually figure out the vulnerabilities.

Now, there are definitely some smart contract developers who experiment with Solidity and smart contracts a lot and therefore are becoming the best in the industry (_check the_ [_Underhand Solidity Contest winners_](https://underhanded.soliditylang.org/) _or their_ [_Challange Submissions_](https://github.com/ethereum/solidity-underhanded-contest/tree/master/2022/submissions_2022)_, for instance_).


![Winners of Underhanded Solidity Contest 2022
](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/tk7w3p8mcr6k5zy0rhv0.png)

However, as I previously mentioned, **_for the web3 world to expand its boundaries and scale with utmost security measures, we cannot simply rely on a handful of experts in the space._**

Instead, every smart contract developer should aspire to learn more and dive in deep by not simply learning the basics but experimenting, making mistakes, learning from them, and then sharing them with the community.

> _Because, quite similar to life in general, the best learnings in software development also comes from mistakes._

**_Mistakes or Learning Experiences_** every smart contract dev should have at least once:
------------------------------------------------------------------------------------------

If you are just starting out with Solidity, there are a bunch of mistakes/experiments you can (_and should_) do while learning.

Dropping off some of them from the top of my head.

**Solidity 101 mistakes/learnings:**

1.  Using **_memory_** keyword instead of **_storage_** and then realizing you never really stored the crucial contract states permanently on the contract.
2.  Relying on blog time stamps for random calculation and realizing how they can be manipulated by the miners is therefore a bad practice. _More details are_ [_here_](https://swcregistry.io/docs/SWC-116)_._
3.  Storing secret information on smart contract state variables with a private visibility modifier only to find out that nothing is private on a smart contract.  
    Every state variable value can be seen by anyone. _Read more about this in_ [_SWC-136_](https://swcregistry.io/docs/SWC-136)
4.  You will always believe that a contract with no payable function (_or payable fallback function_) will never receive any ether unless you learn how [**_selfdestruct_** can forcefully fund such a contract with ETH.](https://swcregistry.io/docs/SWC-106)
5.  Failing to provide required _input validation_ in functions & realizing how this can lead to unwanted scenarios any invalid arguments can be passed without proper validation. ( [_SWC-123_](https://swcregistry.io/docs/SWC-123)  )

**Gas Optimization & Security mistakes/learnings :**

5\. Writing expensive for loops only to find out how this could lead to a [**_block gas limit_**](https://swcregistry.io/docs/SWC-128) issue and fail the complete transaction

6\. Violating [**_check effects interaction pattern_**](https://fravoll.github.io/solidity-patterns/checks_effects_interactions.html)s and realizing how this could lead to the classic Rentrancy attack.

7\. Using delegate calls between two contracts with different storage layouts and realizing why storage layouts must be exactly similar for delegate calls to work.  
It's extremely important to ensure storage layout between two contracts involved in a _delegatecall()_ is exactly the same. Otherwise, this leads to storage collisions. Read more about storage collisions [here](https://docs.openzeppelin.com/upgrades-plugins/1.x/proxies#storage-collisions-between-implementation-versions).

8\. Including inadequate access controls for imperative functions of the contract and realizing how this could lead to any bad actor executing transactions without approval. [_SWC-105_](https://swcregistry.io/docs/SWC-105)  covers this topic quite adequately.

9\. Trying to send ether from one contract to another using the **_transfer_** function only to find out that it always sends a hard-coded **_2100_** gas only. This will help you realize the significance of the **_.call.value(…)(“ ”)_** function which allows adjusting the gas to be sent with a transaction. Read more about why [._call() might be better than transfer()_](https://consensys.net/diligence/blog/2019/09/stop-using-soliditys-transfer-now/)_._

10\. Realising how tricky it is to delete mappings values in struct or in general and learning the right way to do it.

11\. Trying to swap _Token A_ with _Token B_ using Uniswap and being vulnerable to sandwich attacks. This might help you realize the dark side of transaction order dependencies and MEVs and the  [_DARK Forest of Ethereum_](https://www.paradigm.xyz/2020/08/ethereum-is-a-dark-forest) _._

Mr. Walter White experimenting with Solidity

While these are just some examples, there are way more interesting topics in smart contract development, from basic solidity to advanced deep dives in EVM Opcodes, that one can learn and experiment with.

## Wrapping it UP 😊
=================

Web3 has come a long way in a very short span of time, however, the security of smart contracts is still a major concern.

The two ideas discussed above aren’t gonna make it all sunshine and rainbows at one go. There is undoubtedly a lot more we need to do to make Web3 a safer place.

However, imagine a whole generation of developers that includes the two ideas mentioned above while learning or developing smart contracts, prioritizes learning the basics of security, experiments with Solidity, learn from their mistakes, and then shares those learnings with the community.

That will, slowly but surely, lead us to a much safer and more secure web3 world than what we have now.

> _**All it takes is some commitment be to consistent, the will to learn more from mistakes and experiments, and the aspiration to be the better version of the smart contract developer that you already are.**_

## About myself
============

Who am I? 🙋🏻‍♂️
-----------------

𝙃𝙞, 𝙄 𝙖𝙢 𝙕𝙖𝙧𝙮𝙖𝙗 👋🏻

*   A Smart Contract Engineer and Dev Team Lead at [Push Protocol](https://medium.com/u/7e1cbe74a9a4?source=post_page-----4b3decc52b46--------------------------------).
*   I work on smart contracts development as well as security audits of smart contracts.

Drop a ‘HI’ and Get in Touch 🤝
-------------------------------

[**_My Socials |Follow my Weekly Newsletter |My Web3 Speech & Presentations_**](https://linktr.ee/zaryab2000)