(Part3) Over $300M lost to this vulnerability!
Part2
Here's a live smart contract example and learn how it works, even if you're not a dev
Re-entrancy attacks are a common vulnerability in EVM smart contracts, allowing an external contract to hijack the control flow and re-enter, potentially draining the victim's funds.
These attacks are still a significant issue in smart contract development and are taken very seriously by developers.
opular re-entrancy smart contract attacks include:
• The DAO Hack: They lost around $50M worth of ETH.
• Cream Finance: They lost over $30M worth of various assets.
• Siren Protocol: They lost over $30M worth of different assets.
Let's implement this example using Solidity smart contracts.
Don’t worry, we’ll go step by step.
I'll be using @EthereumRemix (X), a development interface where you can write, compile, test, and run code.
We’ll write some code and simulate an attack.
• First, let's create a file named "Bank.sol", which will contain all the code.
• Then, create a mapping to store the balance of each address.
Here, each address will correspond to a person's account.
Next, we’ll create a simple deposit function that allows clients to deposit money into the bank.
The smart contract here represents the bank.
Every time a deposit is made, the mapping is updated by adding the new deposit to the respective address.
We also need a withdraw function that allows depositors to withdraw all or part of their balance.
To simplify, every time the client calls this function, they will withdraw their entire balance, and we set their balance to 0 in the mapping.
Finally, we add a function that doesn't change the mapping but simply lets a client check their balance.
This is called a view function, which doesn't consume any gas because it doesn’t modify on-chain data, it only displays the requested information.
The contract seems pretty simple and, at first glance, looks unbreakable.
Let's attempt a reentrancy attack on it. We’ll build the attacker’s smart contract with a receive function that will keep withdrawing as long as the contract balance is above 1 ETH.
To finish, we’ll add a view function, getBalance, which will return the Ether balance of the Attacker contract.
Now, let's deploy everything and test if our re-entrancy attack will work.
First, we need to deploy the Bank contract:
• Start by compiling both codes.
• Deploy the Bank contract.
• Copy the deployed Bank contract’s address and use it as input to deploy the Attacker contract.
• Then, deposit 10 ETH into the Bank contract.
• Deposit 1 ETH into the Attacker contract.
• Finally, launch the attack using the attack function.
As we can see, the attack worked.
We had deposited 10 ETH with one address and 1 ETH with the attacker’s address.
In the end, the attacker’s address holds 11 ETH.
How this could have been prevented?
It could have been avoided by setting the client’s balance to 0 before sending the funds to them when they call the withdraw function.
All it would have taken is moving a single line of code.
I hope you've found this article helpful.
Follow me @Bluechip for more.
Like/Repost the quote if you can.
#TON #DOGSONBINANCE #CryptoMarketMoves #TelegramCEO #USNonFarmPayrollReport
