Bsides Ahmedabad - Dark Side of DeFi

Download as pptx, pdf, or txt
Download as pptx, pdf, or txt
You are on page 1of 46

The Dark Side of DeFi

Who are we

● Smart contract triagers at @immunefi


● Interested in investigating EVM based defi hacks.
● Previously worked as an appsec engineer in web2 space.
● Create educational content.

ArbazKiraak 0xrudrapratap
@immunefi-team/community-challenges

https://immunefi.medium.com
Agenda

● What are smart contracts


● Web2 vs Web3 application architecture flow
● Most common decentralized application(DAPP) vulnerabilities
● Most common smart contract vulnerabilities
● Outro - Get started with smart contract hacking resources
What are smart contracts?
● Immutable program code containing set of instructions to be executed.

● Run on decentralized blockchain network such as Ethereum, Solana,


Polkadot etc

● Extensively written in high level languages like Solidity, Vyper, Rust,


Stacks etc

● Contains set of OPCODES which interacts with the EVM (Ethereum


virtual Machine)
Web2 vs Web3 Architecture
What are these wallets?
● Creates a digital identity on the blockchain.

● Generates a pair of private key and public key


○ Private key(secp256k1) gives access to the wallet
○ Public key represents your address

● Handles the communication between smart contracts and the frontend


○ Read, Write, Execute instruction

● Store digital assets


○ Ethereum or ERC20 tokens like USDT etc
○ ERC721 (NFT) assets.
○ Other many variants.
How does authentication works?
Compared with current web2
Why Signatures?

● Meant to be public in nature.

● Digital signatures are used to verify the


ownership of an account.

● Use case: Signature owner can create a offline


signature, then pass it to other user or contract
that can use the signature to broadcast the
transaction on behalf of the signer while paying
the gas fee on behalf of the signer.
Auth Flow
1. User Initiates login and sends request to
backend to create a random nonce.

2. User signs a message which contains


(message + nonce) with wallet to create a
unique signature.

3. Backend verifies the signature by recovering


the address of signer and generate the auth
token.

4. Backend expires the current nonce, so a


unique nonce is created next time the user login.
Example of Auth Workflow
Authentication Vulnerabilities
1. Missing random nonce
○ Signature Replay

2. Validator accepts arbitrary message.


{sigHash:"0xabc..",userAddr:"[victim address]"}

○ Logged in as victim.
Missing Random Nonce

When a cryptographic signature intended for a single use is permitted to be replayed repeatedly, leads to
signature replay attacks.

Applications that generate signatures but do not use a random nonce to generate the signatures are vulnerable to
replay attacks.

No nonce is used to generate a signature therefore making it vulnerable to signature


replay attacks.
Validator Arbitrary accepts any message

If an application only verifies the user-supplied signature without validating whether the provided message and signature
are the same as those required by the application to generate JWT tokens, an authentication bypass could happen.
Validator Arbitrary accepts any message hash

> We substituted a random signature picked from the


database of Ethereum Verified Signatures for each of the
three parameter
1. Address
2. Signature
3. and message.

> If the application is not verifying that the message signed


by the user is different from what the application asked the
user to sign, an attacker could produce an auth token on the
victim's behalf.
Client Side Injections
● Javascript injections (XSS)
● Substituting the contract addresses.
● Modifying transaction arguments or parameters.

Severity stands critical considering the digital assets at risk.

source: coindesk
Decentralized finance (DeFi)

● Financial ecosystem based on blockchain technology.

● It’s lets users buy and sell assets and perform financial services as a form
of investment or financing without middleman.

● Such as Decentralized Exchange(DEX), Borrow-Lending, Yield farming,


Derivatives, etc.
Common smart contract
vulnerabilities
01 Unsafe external calls

02 Griefing vulnerability

03 Insecure external dependencies


External Calls
Calls to 3rd party address that we do not control

● Calls to untrusted contracts can introduce several


unexpected risks or errors.

● External calls controlled by an attacker may force


your contract to transition into an undefined state.
Types of External Calls

01 STATIC - CALL

02 DELEGATE-CALL
Re-entrancy attack (call method)

● A reentrancy attack occurs when a function makes an external call to


another untrusted contract

● Then the untrusted contract makes a recursive callback to the vulnerable


contract function to steal funds.
But first, Who can be the callers?

1. EOA (Externally Owned Accounts)


2. Smart contracts themselves
Example re-entrancy attack (call method)

How to fix this vulnerability?


Mutex locking

CEI (checks effects interaction) pattern


Comparison with CEI pattern

Reentrancy vulnerable pattern

CEI (checks effects interaction) pattern


Short intro to delegate(call)

● Example of the delegatecall

SLOT Contract - A Contract - B


DELEGATE CALL
setNum(5)

0 5 0
SAVE STATE

CONTRACT-A CONTRACT-B
1 ….. 0
Storage layout

● Execution occurs in contract B while updating the storage in contract A.

● Using this method, contract can preserve the storage state while using the logic of contract.

● Introduced the concept of Proxies.


Delegate(call) and proxies

The proxy contract redirects all the calls it receives to an logic contract, whose address is
stored in its (Contract A’s) storage.

The proxy contract runs Contract B’s code as its own, modifying the storage and balance
of Contract A.
Types of Proxies Patterns
1. Transparent Proxy Pattern (TPP)

● upgrade logic is stored in proxy itself.


● gas-inefficient.

1. Universal Upgradable Proxy Standard (UUPS)

● upgrade logic is stored in logic itself.


● gas-efficient.

By calling the upgrade function, the storage slot on the proxy contract is updated to point to a
new logic contract.
Uninitialized proxy bug
● Lot of developers often leave the contracts uninitialized. This is not an problem in
most cases, but problematic when it leads to some major changes like: granting
ownership to the caller.

● Owner of the contract can upgrade the implementation contract.

● This bug can lead to the self-destruction of the logic contract, which could render
the proxy contracts useless.
CALL DELEGATE CALL
Normal Workflow.

RETURN SAVE STATE


(PROXY) ( LOGIC )
( DATA )

CALL DELEGATE CALL


1. Malicious user deploys Evil contract
SAVE STATE
containing SELFDESTRUCT opcode.
( EVIL ) SELFDESTRUCT
( LOGIC ) 2. Delegate(call) to Evil contract.

CALL
Its storage and code are erased from the
DELEGATE CALL blockchain.

( PROXY)
Proxy contract is bricked.
( DATA )
UUPS pattern uninitialized proxy bug

makes the caller owner

Wormhole bridge protocol : Attacker can held the entire protocol for ransom ($1.8 billion)
$10M Bounty : https://medium.com/immunefi/wormhole-uninitialized-proxy-bugfix-review-90250c41a43a
POC: https://github.com/immunefi-team/wormhole-uninitialized
Push vs Pull Pattern

● Contract with logic with transferring ether to the user.


● Which involves the risk associated with transferring ether to the user as this
external call could fail. If the receiving address is a contract.
○ it could have a fallback function implemented that simply throws an exception, once it gets called.
○ Another reason for failure is running out of gas.
NFT Auction Workflow (Push Pattern)

NFT AUCTION 20
D
BI

0$

0$
10
0$

BI
10

ND

D
FU
RE

(USER-1) (USER-2)

https://github.com/immunefi-team/community-challenges/blob/master/contracts/vulnerable/Auction.sol
Auction Workflow (Push vs Pull)
NFT AUCTION 1. Malicious user deploys Evil contract containing exception
condition to revert any incoming calls.

2. Contract is forced into a Griefing state.

20
UN
D

0$
BI

NFT AUCTION

BI
RE
0$

D
10

CT
JE
RE

(USER)
( EVIL )

20
BI

0$

0$
10
0$
oy

BI
10

D
pl

AI
De

CL
(ATTACKER)
(USER-1) (USER-2)

Push Pattern
Pull Pattern
Spot Price Dependency
Price Oracles

A price oracle is a tool used to view the price


information of a given asset.

On-chain oracles rely on constant-product


AMMs, like UniswapV2 or Balancer.

Users rely on the current ratio of two tokens.


For example, the ETH-DAI ratio gives us the
current price of an ETH.
Onchain Spot Price
Finding the price of WBTC in ETH on Uniswap V2 pair for ETH/WBTC, grab the
reserve balance of ETH and WBTC, then divide the two.

X = 20 WBTC , Y = 100 ETH

P(y) = Y / X

P(y) = 100 / 20 = 5 ETH per WBTC


(Easily impact the price movement by buying and selling)

● Manipulating the large volume with flash loan (considering high liquidity)
● Exploiting on borrowing platform as example. (spot price dependency)
Spot Price Dependency Example
10 ETH,
100k USDT ETH/USDT
Supply 1 ETH querying price of 1 ETH

1 ETH $1000 ORACLE


Borrow 900 USDT
VAULT

10k USDT ETH/USDT

Inflates the price of ETH


10k USDT 8 ETH
ORACLE

ETH/USDT
10 ETH,
100k USDT querying price of 1 ETH
Supply 8 ETH

$10k
8 ETH Borrow 72K USDT ORACLE
VAULT
Hard choices, but better than spot price

● Relying on TWAP (Time Weighted Average Price)


○ Average price between the time intervals.

● M-of-N Reporters
○ Averaging the price between the multiple AMM products like Uniswap,
MakerDAO, Balancer etc , and offchain oracle’s like chainlink.
Who wants to become a Web3 Hacker?
Useful links to get you started

● https://medium.com/immunefi/hacking-the-blockchain-an-ultimate-guide-4
f34b33c6e8b
● https://solidity-by-example.org
● https://github.com/ethereumbook/ethereumbook
● https://github.com/OffcierCia/DeFi-Developer-Road-Map
● https://www.damnvulnerabledefi.xyz
● https://cmichel.io/how-to-become-a-smart-contract-auditor/
● https://ethernaut.openzeppelin.com/
● https://github.com/immunefi-team/community-challenges

You might also like