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.

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

2. 👋 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

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

4. 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!

5. Good luck from Coinbase 😉

6. Blockchains: Bitcoin → Ethereum

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

8. Bitcoin is an arcade machine

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

10. Ethereum is a game console

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

15. Blockchain: Web3

16. Classic Blockchain: “Bitcoin”

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!

18. Web2

19. Web3 Echosphere: Web + Blockchain

20. Web3 Echosphere: Web + Blockchain

21. 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.

22. The Web3 Triangle – Demo

23. Web3: Moving apps to the 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! :)

25. Rumor has it that Microsoft 💕 Ethereum too…

26. Web3 Security

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.

39. Simulation to the rescue

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

43. Runtime execution

44. Runtime execution: Example

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

49. Preventing BadgerDao with Simulations + FW

50. Attacking simulations

51. Red pill & Blue pill

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!

58. Demo - Exploiting Coinbase wallet

59. Disclosures table

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

63. Demo - Exploiting using TOCTOU

64. Wrap up

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!

66. ClearSign: Web3 Personal Firewall

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

68. 2023
Thank
you!