The introduction of Web3 smart contracts has opened unlimited opportunities for decentralized apps (dApps) and users. With smart contracts, anything that can be coded can be deployed by anyone on the blockchain. As a result, in a Web3 environment, the users’ blockchain transactions, previously merely used for sending coins to peers, are now, in fact, Remote Procedure Calls (RPCs) for smart contracts.
The flip side of this expressiveness is that it’s almost impossible to know analytically in advance what would be the outcome of such RPC to an arbitrary smart contract. Attackers abuse this observability gap to trick users into signing transactions that are harmful in reality. This situation bears a close resemblance to the desktop environment: users need to evaluate in advance if a particular program behavior will be benign.
To solve this gap, Web3 security has taken a page out of the desktop’s security book by using a sandbox-style emulation to evaluate the transaction's outcome before it gets sent to the blockchain. In Web3 lingo, such sandbox emulation is referred to as transaction simulation.
In this talk, we will present our newly discovered attack methods against Web3 simulations, including the first-ever Web3 red pill exploits that allow smart contracts to know that they are running in a simulation and as a result, need to behave differently.
We have tested our findings against numerous leading simulation providers in the Ethereum Virtual Machine (EVM) domain and found that they are indeed vulnerable to such attacks. As a result of our responsible disclosure, multiple (currently three) issues were fixed, and we were awarded bug bounties. We will explain these exploits in detail, including the research methodology allowing us to inspect simulators’ inaccessible inner workings.
We will conclude with new and enlightening insights we gained through this research regarding the true capabilities and limitations of Web3 simulations.
7. 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
9. 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
11. 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)
12. 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
13. 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)
14. NFT in the wild
● The user owns NFTs
○ Ownership is public on blockchain
○ User can transfer via wallet
● Multiple marketplaces
○ For example: Opensea, rarible
17. 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!
24. 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! :)
27. 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/
28. 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?
29. Answer: because humans make mistakes
● The program (code + input) is executed perfectly, but either code or input (or
both) is malicious!
30. 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
31. 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
32. Attack #3: Malicious code
● The program (code + input) is executed perfectly, but:
○ The code is malicious
● Definitely going to discuss that today
33. Malicious interfaces in the wild: BadgerDAO
● “Bringing Bitcoin to DeFi” : Earn interest on your BTC
○ via ERC20
34. 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)
35. BadgerDAO Who is $50M fish?
● According to press
○ Celsius
○ Using MetaMask
36. 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
37. 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
38. 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.
40. Ethereum is a state machine
● EVM is the runtime environment for smart contract in Ethereum
41. EVM opcodes
● Predefined instructions
● Smart contract written in High level languages, broken down into EVM
codes
● Execution is initiated by a transaction
42. 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
45. 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!
46. 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
47. 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
48. 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
52. ● 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?
53. 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?
54. 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?
55. 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
56. 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
57. 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!
60. 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/
61. 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)
62. 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
65. 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!
What is blockchain [20 mins]
Distributed database
Private key, public key, signing, address, transaction
MPC in a nutshell
Fees
Explorers
Ethereum [25 mins]
Ethereum vs. Bitcoin
Smart contracts and apps:
ERC20
NFTs
DeFi
Web3 and WalletConnect
Web3 security in a nutshell
Other chains [5 mins]
Honorable mentions for chains ZenGo supports / supported / will support: Tezos, Dogecoin, Terra, Binance, Solana
Layer 2
Team [5m]
Research team - areas of research: Blockchain, Security, Cryptography and MPC
people