How to Protect Wallet Users From the Red Pill Attack

The Red Pill attack is a sophisticated technique used to exploit vulnerabilities in the way some wallets and dapps simulate transactions.

Wallet and dapp users rely on simulations to understand the financial implications of their transactions before signing them. Because of this, maintaining the reliability and integrity of simulations is paramount.

However, the Red Pill attack capitalizes on a flaw in how transaction simulations work. Its purpose is to trick users into approving malicious transactions that appear legitimate during the preview phase.

In this article, we'll delve into the intricacies of the Red Pill attack, highlight preventive measures, and explain how Tenderly's simulation platform inherently safeguards dapps and wallets from these types of vulnerabilities.

The genesis of the Red Pill attack

The Red Pill attack was first discovered by the team behind the crypto wallet ZenGo. The attack exploits a weakness in the way transaction simulations are executed.

Carrying out a successful Red Pill attack relies on exploiting a special type of variable in Solidity known as "special variables."

These variables contain information about the blockchain environment, such as the current block timestamp, miner address, or block number. In a simulation, these variables are usually set to the default value of 0.

An attacker will deploy a contract that, at some point of execution, tries to check the values of special variables to determine if the transaction is in a simulated environment. If the check comes back positive, the contract will return information that won’t be the same as if it were executed as part of a block on the blockchain.

Most Red Pill attacks happen because the preparation of the execution wasn’t done properly, meaning that some environment fields weren’t initialized. This enables the hackers to determine if the transaction is a simulation and not an actual transaction on the blockchain.

Dissecting the Red Pill attack

To understand the basics of the Red Pill attack, let’s analyze a simple smart contract. The malicious contract below shows the logic that can be used to detect whether the contract is in a simulated environment or on the actual network.

// Language: solidity
//SPDX-License-Identifier: Unlicense
pragma solidity ^0.8.0;

contract RedPill {
 function getResult() public view returns (uint) {
     if (block.coinbase == address(0x0000000000000000000000000000000000000000)) {
       return fakeResult();
     }
     return realResult();
 }
 
 function realResult() private pure returns (uint) {
     return 10;
 }

 function fakeResult() private pure returns (uint) {
     return 1;
 }
}

The function getResult()checks the block.coinbase value, which is a special variable in Solidity that represents the current block miner’s address.

In a simulation, the block.coinbase variable might be set to a null address because there's no real block and hence no miner during a simulation.

This is where the Red Pill attack comes into play.

If block.coinbase is equal to the null address, the getResult() function returns the result of fakeResult(), which is 1.

However, in a live transaction, block.coinbase will contain the address of the actual miner, and the getResult() function will return 10. This is how a malicious actor can determine if the contract is in a simulated environment.

From there, the attacker can change the behavior of the smart contract to deceive the user and potentially lead to undesired outcomes or even loss of assets.

But as hackers evolve in their sophistication and knowledge for mounting attacks, the countermeasures to surpass them are also evolving.

Protecting against the Red Pill attack

The discovery of the Red Pill Attack had significant consequences. It led to swift action by popular wallets and transaction simulation platforms to address the vulnerability.

The primary defense involves not using arbitrary values for the special variables that are vulnerable to manipulation when in a simulation. By inputting precise values, the use of these variables as "red pills" in malicious contracts can be prevented.

Tenderly's simulations always initialize special variables. Default values are never used. Instead, Tenderly populates the values of special variables with meaningful data derived from the actual state of the blockchain.

Using actual blockchain data ensures that simulations accurately reflect the conditions of the live blockchain. This is how Tenderly protects wallets, dapps, and their end users by making it more difficult for attackers to exploit vulnerabilities like the Red Pill attack.

Enhancing flexibility with Block Header Overrides

Furthermore, Tenderly allows wallets and dapps to set custom values for special variables through block header overrides. These overrides enable wallets and dapps to modify certain properties of the block header during the simulation.

To make this possible, Tenderly exposes a custom RPC endpoint, tenderly_simulateTransaction. This endpoint accepts a Block Overrides object where wallets and dapps can set custom values for special variables.

The Block Overrides object allows wallets and dapps to override the following header fields in a block:

• number: Override the block number.
• difficulty: Override the block difficulty.
• time: Override the block timestamp.
• gasLimit: Override the gas limit.
• coinbase: Override the block miner.
• random: Override the block's extra data, which feeds into the RANDOM opcode.
• baseFee: Override the block base fee.

By allowing users to override block headers, Tenderly makes transaction simulations inherently more secure. It also prevents attackers from exploiting the kind of vulnerabilities that the Red Pill attack targets, allowing wallets and dapps to adjust the parameters of the simulation to more accurately reflect the conditions of the live blockchain.

Making wallets more secure with Tenderly simulations

Security vulnerabilities like the Red Pill attack stress the importance of robust transaction simulation implementations.

Whether you're a wallet provider or a dapp developer, Tenderly's simulations can significantly enhance the security and user experience of your product.

Tenderly offers three types of simulations to support a wide array of projects and use cases:

• Simulations in UI: Ideal for quick tests and debugging, these simulations provide a user-friendly interface for running transaction simulations. Each simulation can be opened in Tenderly user-friendly Dashboard, allowing wallet users to inspect the results with Debugger or resimulate the transaction with different values. Learn more about Simulation UI.
• Simulations via API & RPC: Geared toward wallets and dapps that want to quickly implement a transaction preview option into their UI without the need to build the solution from scratch or manage infrastructure. Learn more about Tenderly Simulation API and Simulation RPC.