README.md

Vulnerabilies

(WIP)

This is the therory behind the vulnerabilities, if you are interested in learning the real world examples check: BugFix Reviews.

• Vulnerabilies
• Logic
  • - Bad Arithmetics
  • - Integer underflow/overflow
• Re-entrancy
• Uninitialized
  • - Contracts
  • - Proxies
• Code injection via delegatecall [WIP]
• Access Control
  • - Unprotected functions
  • - Signature Verification
  • - Authentication with tx.origin
  • - Reusing msg.value
• Wrong implementation of standards
• Flashloans
• Oracle manipulation
• Unchecked call return value
• Transaction reorganization (MEV)
• Bad Randomness
• Use of components with known vulnerabilities
• Blockchain Bridges
• Research Papers
• Resources:

Logic

- Bad Arithmetics

• Assumptions using external functions

This can have a lot of variations, this case of calling an external function is very interesting: ValueDeFi Incident

• Decimal assuptions

For example, ERC20 decimals errors, the common value used for decimals is 18, but tokens like USDT and USDC have only 6.

- Integer underflow/overflow

This happens when you go below the minimum value (underflow) or exceed the maximum value (overflow) and the value will be considered 0.

Solidity has different value types, for integers you can use int (negative and positive values) and uint (just positive ones) and their size variations in steps of 8 for example: int8 2**8 different values,int16, int24... int256 2**256 values

Since version 0.8.0 Solidity automatically reverts on integer overflow and underflow instead of circling the value back to zero.

Resources: Consensys Insecure Arithmetic, Solidity Docs Integers

Re-entrancy

Reentrancy is when a program’s execution can be interrupted and re-run from a particular point, a vulnerability made famous in the DAO hack. One way this vulnerability could manifest is if a bank’s wire system only checked an account’s balance at the beginning of the wire, as opposed to also checking the balance when the wire is about to be sent, in order to ensure sufficient funds. This could lead to a reentrancy attack that calls the send function multiple times to send more funds than are available in the account.

In other words, this is an issue of temporality where a send function can be called before a check balance function is called.

In smart contracts, a function will make an external call, which if not done just correctly will allow an untrusted called contract to perform a re-entrancy attack on the original contract.

Resources: Consensys, SecuRing, Historical Collection of Reentrancy Attacks

Uninitialized

- Contracts

- Proxies

Code injection via delegatecall [WIP]

First of all, you need to understand what is delegatecall this function is a variant of message call but SolidityDocs delegatecall

Access Control

- Unprotected functions

• Default Visibility One of this common examples

- Signature Verification

- Authentication with tx.origin

Never use tx.origin for authorization.

If for example you create a contract wallet with that authorization system, someone can trick you into sending Ether to an attack contract and that contract can call your unsafe wallet and drain all the funds because is checking the tx.origin instead of the msg.sender. Check the code of this example here

- Reusing msg.value

The particularity with msg.value is that his value remains fixed during the whole function call. Do not use msg.value inside a loop.

Resources: TrustChain, TrailOfBits

Wrong implementation of standards

Information about standards: Ethereum docs, OpenZeppelin docs

Let's say that these standards are almost bulletproof, however, the most insignificant change can lead to critical vulnerabilities.

As an example, I'm going back to the spring of 2021 when a lot of projects decided to add a "transfer fee" to their tokens, this can be seen as an insignificant change but, most of the contracts weren't ready to handle these tokens. The common issue here was that someone could drain the pool staking and unstaking several times leading to miscalculations. This article Watchpug SafeDollar postmortem provides an example.

Flashloans

Oracle manipulation

Unchecked call return value

Transaction reorganization (MEV)

Bad Randomness

Use of components with known vulnerabilities

• Smart contracts may have been created using an obsolete compiler with known flaws
• Libraries with known vulnerabilities have been imported
• Code reuse: for their apps, many programmers reuse code. To put it another way, if the copied code has flaws, so does the smart contract it was pasted into.

Blockchain Bridges:

• The Dark Side of DeFi Cross-chain Bridge Hacks

Research Papers:

• SoK: Not Quite Water Under the Bridge: Review of Cross-Chain Bridge Hacks
• A Review on Cryptocurrencies Security

Resources:

• Consensys Smart Contract Best Practices Attacks
• Consensys Smart Contract Best Practices Development Recommendations
• SWC Registry, Smart Contract Weakness Classification and Test Cases
• List of Security Vulnerabilities
• Secureum Audit Findings 101
• Secureum Audit Findings 201
• DeFiVulnLabs - Collection of Vulnerable Code Snippets