Web3’s red pill: Smashing Web3 transaction simulations for fun and profit

2023
Tal Be’ery
Roi Vazan
Web3’s red pill: Smashing Web3 transaction
simulations for fun and profit

👋 Hi, I’m Tal Be’ery
● Co-Founder, CTO @ ZenGo
● 20 years of cyber security experience
● Former EIR Innov8 VC, VP Research Aorato
(acquired by Microsoft)
● @talbeerysec

👋 Hi, I’m Roi Vazan
● Researcher @ ZenGo
● 10 years of cyber security experience

Agenda
● Intro on blockchain evolution
○ Bitcoin → Ethereum
○ Ethereum apps
● Ethereum apps power the Web3 revolution
○ The Web3 triangle: user, web3 interface, smart contract
○ Security in the Web3 triangle: The visibility challenge
● Transaction simulation
○ Solving Web3’s visibility problems
● Attacking transaction simulation
○ False visibility is worse than no visibility: Red pills and TOCTOU exploits
○ Vulns, bounties, grants!

Blockchains: Bitcoin → Ethereum

Blockchain: In a nutshell
● “Just” a distributed database
○ Reaching a consensus on conflicts is not trivial!
● Messages are authenticated
○ User address corresponds to a public key
○ User signs messages with a private key
○ Private key stored in a wallet
● Very useful for value transfer = digital money!
● Bitcoin (2009) is doing that:
○ “1 built-in program”: “Send(source,dest,amount)”
■ Check authenticity by verifying the user’s signature on the transaction
■ Add amount to dest, subtract amount from source
■ Results are saved in the blockchain

Blockchain: beyond sending money
● Ethereum, co-founded by Vitalik (2015)
○ Has a similar “1 built-in program” for money transfer
○ But also, allows users to upload custom code (smart contract) and interact with it
■ Smart contracts are uploaded into addresses
■ Smart contracts expose callable methods
■ Very similar to a dynamic library (“.dll”, “.so”)
○ When interacting with a contract
■ Destination address is the contract
■ Function name and call parameters are passed as part of the transaction
■ Network fee (“gas”) depends on the complexity of the execution

Ethereum Apps: Tokens (ERC20)
● Before:
○ if you wanted your own coin, you needed to create your own blockchain
● After:
○ You just need to implement a smart contract that supports 6 methods (and 2 events)

Software eats world: DeFi “Money Lego”
● ERC20 is a standard, so dev developed standard services
○ Exchange in smart contract: DEX
○ Deposits / Loans
○ Derivatives
● Composability
○ Everything is just a function call
○ You can make an app to “mix and match”
■ Example “swap + deposit” app
● Finds the best interest rate for coin
● Switches user coin to it and deposits

Ethereum Apps: NFTs
● Current leading use case “Funny JPEGs”
● In future, also more serious use cases: registries, fractional ownership
● All you need to do is to implement 9 functions (and 3 events)

NFT in the wild
● The user owns NFTs
○ Ownership is public on blockchain
○ User can transfer via wallet
● Multiple marketplaces
○ For example: Opensea, rarible

Classic Blockchain: “Bitcoin”

How can user consume apps?
● (Most) Users cannot interact directly with smart contracts
○ We need to provide UI for this new system
○ We need to tell the wallet what to sign
● We already solved similar problems with Web
● Let’s repurpose Web2 to work with blockchain!

Web3 Echosphere: Web + Blockchain

The Web3 Triangle
1. Web2 app interface:
App UX, suggests transactions to the user
2. Wallet
key management, transaction signing and blockchain interaction
3. Blockchain smart contracts (“contracts”)
implements the app’s logic.

Web3: Moving apps to the blockchain

ZenGo 💕 Ethereum and Web3
● Ethereum supported since day 1
○ Polygon added
● ClearSign:
○ Web3 first firewall integrated into the wallet
● Native tokens support
○ ERC20
○ NFTs gallery
● Ethereum Foundation grant
● Security research
○ Including this talk! :)

Rumor has it that Microsoft 💕 Ethereum too…

Ethereum: The most(?) secure execution env!
● Trusted execution is a hard problem
○ Integrity of data and code
○ Consider malware, HW supply chain, Operating system supply chain
● Usually “solved” in hardware: SGX, TEE, etc.
● Ethereum
○ Code and inputs are on chain
○ Execution is independently validated by multiple validators
● In Ethereum an attacker will need to compromise the majority of validators
to compromise a computation!
● Implicit bug bounty of $200B
● More on this: zengo.com/wagmi-web3-will-be-more-secure-than-web2/

If it’s so good, how come it’s so bad?
● If Web3 is so secure, how come there are so many hacks and money loss
cases?

Answer: because humans make mistakes
● The program (code + input) is executed perfectly, but either code or input (or
both) is malicious!

Attack scenario #1: Malicious user
● The program (code + input) is executed perfectly, but
○ The smart contract’s code has vulns
○ Malicious user send maliciously crafted inputs to exploit
● Not going to discuss that today

Attack #2: Malicious web2 interface
● The program (code + input) is executed perfectly, but:
○ The input is bad for the user
■ Input is suggested by a malicious dapp
● Definitely going to discuss that today

Attack #3: Malicious code
● The program (code + input) is executed perfectly, but:
○ The code is malicious
● Definitely going to discuss that today

Malicious interfaces in the wild: BadgerDAO
● “Bringing Bitcoin to DeFi” : Earn interest on your BTC
○ via ERC20

BadgerDAO hack: injected code to web interface
● BadgerDao web interface infected with injected code
○ [Nov 2021] first version injected
○ Captured by web.archive.org
○ De-obfuscated by ZenGo
● Code Diff (The injected website is in red on left)

BadgerDAO Who is $50M fish?
● According to press
○ Celsius
○ Using MetaMask

BadgerDAO: IncreaseAllowance vs. Approve
● Usually ERC20 funds access request
with Approve()
● Attackers used a lesser known
method IncreaseAllowance()
● MM did not recognize
IncreaseAllowance()
○ No humanly understandable explanation
○ Not showing user that they are
interacting with an ERC20 contract

Malicious Smart Contracts in the wild
● The truth is this danger is fairly limited
● Bad contracts can only touch Ethereum
○ Smart contract based assets requires an approve before (as before)
● Ethereum sending is visible as
○ ‘Ethereum has a similar “1 built-in program” for money transfer’
● Still there could be scams like
○ Give $10 ETH to get $200 ERC-20

Is execution (code + input) malicious or benign?
● Visibility is the key:
● Users needs to know before they sign a transaction what would be the outcome of sending
this RPC parameters to the contract
● We can try to analyze the code
○ CS theory tells us this problem is undecidable
● However, antivirus has been dealing with this issue for decades
○ VM / sandbox / detonation chamber
● Instead of analyzing what the program does, let’s just execute it in a
sandboxes environment!
● and then apply some security logic on it.

Ethereum is a state machine
● EVM is the runtime environment for smart contract in Ethereum

EVM opcodes
● Predefined instructions
● Smart contract written in High level languages, broken down into EVM
codes
● Execution is initiated by a transaction

Special variables in the EVM
● Not part of the “regular state”, by definition
○ Some of them are controlled by the user
○ Some of them are “global” variables
● Runtime environment variables:
○ COINBASE - the Account which is going to get the current block fee rewards
○ GASPRICE - Transaction’s gas price
○ BASEFEE - EIP1559 block’s basefee

Are we ready to simulate? Not yet!
● The problem:
○ We can execute a smart contract and observe state changes, but how
can we explain them to the user?
○ State changes are hard to explain
● Solution:
○ Events to the rescue!

Ethereum events
● Invoked by smart contracts during execution
○ Generated on-chain
○ Not stored on-chain - can’t be consumed by smart contracts
● Frequently used by off-chain services
● Any contract can emit any event
● Can we trust events?
○ We can trust good Smart Contract events - as they intend to represent a real on-chain state

Common events in ERC20 and ERC721 (NFT’s)
● Approval event
○ Emitted every time the token owner allows another address to access their tokens
■ In ERC721 - ApprovalForAll - all the tokens within the collection
■ In ERC20 - Approve - specific amount of tokens
● Transfer events
○ Emitted every time a token is being transferred from an address to another

Simulation flow
1. Transaction is being simulated
○ Potential emitted events are shown to the user
2. Based on the events results the user decides whether to reject or continue
the transaction
3. Transaction is broadcasted to the blockchain

Preventing BadgerDao with Simulations + FW

● Find a red pill predicate
○ Am I in a simulation now?
● If in simulation
○ Show benign behavior
● If in non-simulation
○ Attack!
Red Pills exploit: A blueprint
simulation? non-simulation?

Red Pills in Cyber Security
● Traditional Red pills:
○ Malware Vaccination tricks:
■ VM detection
■ isDebuggerPresent
■ SandBox detection
● Web3 Security Red Pills:
○ Malicious smart contract:
■ Can it be aware it runs in simulation?

Web3 Red Pills hypothesis: Special variables
● In real environment naturally provided by:
○ The user - User specifies variables (i.e gaslimit)
○ The environment - i.e block base fee
● However in simulation:
○ Being generated by the simulation node provider
● Almost any value is technically valid, however not every value is
“reasonable”
● Maybe these are our Red Pills?

Validating the hypothesis
● To validate, we need to see the value of special variables in simulation
● Challenge: simulation products are black boxes
○ Just showing simulation results
● Solution: Using standard events in order to debug!
○ Transfer events are restricted to a specific signature
○ Byte by byte debugging
○ Solidity casting

Bingo!
● Applying the technique we were able:
○ Easily debug every environment variable of any provider
○ Search for unreasonable values
● Some unreasonable values found
○ COINBASE always the null address (0x000000…000)
○ GASPRICE always 0
○ GASLIMIT always a constant extremely high values
● Once we discover an unreasonable value provided by a simulation vendor
○ We can create a “red pill” predicate for it:
■ If simulation, then show a good trade
■ If non-simulation, just take the money
● And finally, deploy dedicated exploit contract for every vendor

Exploit example: COINBASE null address
● Red pill predicate
○ Is COINBASE == 0 ?
● Exploit
○ Tricks the user to sign a transaction using the simulation:
■ At simulation sends ERC20 token back
■ On chain it will not!

Demo - Exploiting Coinbase wallet

Bounties, Grants
● Bounties:
○ Coinbase wallet
○ Rabby wallet
● Grants:
○ from the Ethereum Foundation: https://zengo.com/ethereum-foundation-awards-
zengo-a-grant-for-web3-security-research/

How to fix
● Use the REAL environment variables from the current environment
○ That way a malicious contract can no longer differentiate
● Some of them should be provided by the user:
○ GASPRICE
○ GASLIMIT
● Some of them aren’t known yet:
○ COINBASE - Use the last block’s value (consecutive COINBASE value may appear on-chain)

Cat and Mouse - TOCTOU
● Simulating the transaction + confirming it takes time
● Malicious application can leverage it:
○ Dapp checks the timestamp when the tx was craftet
○ Contract checks time elapsed
● Red Pill predicate
○ Is blockDiff > X

Demo - Exploiting using TOCTOU

Takeaways
● Web3 enables decentralized apps with thrilling use cases
● However, it creates new attack surfaces
○ Rogue contracts
○ Rogue interfaces
● Users have no visibility to what they are signing!
● You cannot fight what you cannot see
● Transaction simulation provides visibility
○ But has some limitations and can be attacked
■ Red Pills!
● Transaction simulation should be implemented securely
● With this new visibility, Web3 firewalls can save the users!

ClearSign: Web3 Personal Firewall

www.zengo.com
twitter.com/zengo
medium.com/zengo
github.com/zengo-x
contact@zengo.com

Web3’s red pill: Smashing Web3 transaction simulations for fun and profit

More Related Content

Web3’s red pill: Smashing Web3 transaction simulations for fun and profit

Editor's Notes