Skip to content

To learn common smart contract vulnerabilities using Foundry!

Notifications You must be signed in to change notification settings

akioniace/DeFiVulnLabs

 
 

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

DeFiVulnLabs

This was an internal Web3 solidity security training in XREX. I want to share these materials with everyone interested in Web3 security and how to find vulnerabilities in code and exploit them. Every vulnerability testing uses Foundry. Faster and easier!

A collection of vulnerable code snippets taken from Solidity by Example, SWC Registry and Blockchain CTF, etc.

Education only! Please do not use it in production.

Getting Started

  • Follow the instructions to install Foundry.
  • Clone and install dependencies:git submodule update --init --recursive
  • Test vulnerability: forge test --contracts ./src/test/Reentrancy.sol -vvvv

List of vulnerabilities

  • Integer Overflow 1 | Integer Overflow 2 :
    • In previous versions of Solidity (prior Solidity 0.8.x) an integer would automatically roll-over to a lower or higher number.
    • Without SafeMath (prior Solidity 0.8.x)
  • Selfdestruct 1 | Selfdestruct 2 :
    • Due to missing or insufficient access controls, malicious parties can self-destruct the contract.
    • The selfdestruct(address) function removes all bytecode from the contract address and sends all ether stored to the specified address.
  • Unsafe Delegatecall :
    • This allows a smart contract to dynamically load code from a different address at runtime.
  • Reentrancy :
    • One of the major dangers of calling external contracts is that they can take over the control flow.
    • Not following checks-effects-interactions pattern and no ReentrancyGuard.
  • Read Only Reentrancy :
    • An external call from a secure smart contract "A" invokes the fallback() function in the attacker's contract. The attacker executes the code in the fallback() function to run against a target contract "B", which some how indirectly related to contract "A".
    • In the given example, Contract "B" derives the price of the LP token from Contract "A"
  • ERC777 callbacks and reentrancy :
  • Unchecked external call - call injection :
    • Use of low level "call" should be avoided whenever possible. If the call data is controllable, it is easy to cause arbitrary function execution.
  • Private data :
    • Private data ≠ Secure. It's readable from slots of the contract.
    • Because the storage of each smart contract is public and transparent, and the content can be read through the corresponding slot in the specified contract address. Sensitive information is not recommended to be placed in smart contract programs.
  • Unprotected callback - NFT over mint :
    • _safeMint is secure? Attacker can reenter the mint function inside the onERC721Received callback.
  • Backdoor assembly :
    • An attacker can manipulate smart contracts as a backdoor by writing inline assembly. Any sensitive parameters can be changed at any time.
  • Bypass iscontract :
    • The attacker only needs to write the code in the constructor of the smart contract to bypass the detection mechanism of whether it is a smart contract.
  • DOS :
    • External calls can fail accidentally or deliberately, which can cause a DoS condition in the contract. For example, contracts that receive Ether do not contain fallback or receive functions. (DoS with unexpected revert)
    • Real case : Charged Particles
  • Randomness :
    • Use of global variables like block hash, block number, block timestamp and other fields is insecure, miner and attacker can control it.
  • Visibility :
  • txorigin - phishing :
    • tx.origin is a global variable in Solidity; using this variable for authentication in a smart contract makes the contract vulnerable to phishing attacks.
  • Uninitialized state variables :
    • Uninitialized local storage variables may contain the value of other storage variables in the contract; this fact can cause unintentional vulnerabilities, or be exploited deliberately.
  • Storage collision 1 | Storage collision 2 (Audius) :
    • If variable’s storage location is fixed and it happens that there is another variable that has the same index/offset of the storage location in the implementation contract, then there will be a storage collision. REF
  • Approval scam :
    • Most current scams use approve or setApprovalForAll to defraud your transfer rights. Be especially careful with this part.
  • Signature replay 1 | Signature replay 2 (NBA):
    • Missing protection against signature replay attacks, Same signature can be used multiple times to execute a function. REF1, REF2, REF3, REF4, REF5
  • Data location - storage vs memory :
    • Incorrect use of storage slot and memory to save variable state can easily cause contracts to use values not updated for calculations. REF1, REF2
  • DirtyBytes :
    • Copying bytes arrays from memory or calldata to storage may result in dirty storage values.
  • Invariants :
    • Assert is used to check invariants. Those are states our contract or variables should never reach, ever. For example, if we decrease a value then it should never get bigger, only smaller.
  • NFT Mint via Exposed Metadata :
    • The contract is vulnerable to CVE-2022-38217, this could lead to the early disclosure of metadata of all NFTs in the project. As a result, attacker can find out valuable NFTs and then target mint of specific NFTs by monitoring mempool and sell the NFTs for a profit in secondary market
    • The issue is the metadata should be visible after the minting is completed
  • Divide before multiply :
    • Performing multiplication before division is generally better to avoid loss of precision because Solidity integer division might truncate.
  • Unchecked return value :
    • Some tokens (like USDT) don't correctly implement the EIP20 standard and their transfer/ transferFrom function return void instead of a success boolean. Calling these functions with the correct EIP20 function signatures will always revert.
  • No Revert on Failure :
    • Some tokens do not revert on failure but instead return false, for example, ZRX.
  • Incompatibility with deflationary / fee-on-transfer tokens :
    • The actual deposited amount might be lower than the specified depositAmount of the function parameter. REF1 ,REF2, REF3
  • Phantom function - Permit Function :
    • Accepts any call to a function that it doesn't actually define, without reverting. For example: WETH. REF
    • Attack Vector
      • Token that does not support EIP-2612 permit.
      • Token has a fallback function.
  • First deposit bug :
    • First depositor can break minting of shares: The attack vector and impact is the same as TOB-YEARN-003, where users may not receive shares in exchange for their deposits if the total asset amount has been manipulated through a large “donation”. REF1, REF2

Bug Reproduce

20220714 Sherlock Yield Strategy Bug - Cross-protocol Reentrancy

Bounty: $250K POC | Reference

20220623 Sense Finance - Access control

Missing access control in onSwap()

Bounty: $50,000

Testing

forge test --contracts ./src/test/SenseFinance_exp.sol -vv 

Link reference

https://medium.com/immunefi/sense-finance-access-control-issue-bugfix-review-32e0c806b1a0

Spotthebugchallenge

Link reference

About

To learn common smart contract vulnerabilities using Foundry!

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published

Languages

  • Solidity 100.0%