Web3 Threats

The private key that corresponds to the user’s wallet address controls the transfer of value on the public ledger, be it in the form of tokens or native cryptocurrency. To capture this value, a potential attacker has a number of options:

• Theft of private keys: With the knowledge of the private key, the attacker can send a transaction for every token and native currency associated with the address, transferring the assets to the attacker's own address. Any staked tokens in third party systems can be withdrawn and transferred to the attacker’s address. There are numerous examples of this in the wild: fraudsters often pose as customer support convincing users to install a fake wallet software that captures and shares the user’s passphrase with the attacker.

• Obtaining user’s authorization: Through social engineering and confusing Web3 wallet user experiences, the attacker convinces the user to sign a transaction that can be crafted to:

  1. Transfer tokens to the malicious dApp attacker’s address;

  2. Grant unlimited allowance to the attacker’s address for a target ERC20 token – funds are drained from the wallet to the attacker’s address through a secondary transaction; A recent comprehensive study of abuse of unlimited ERC20 approvals, presents a representative sampling of recent exploits that fall into this category. This includes direct attack vectors (user transacting with a malicious dApp) as well as indirect, where third-party contracts are vulnerable.

  3. Transaction Fees manipulation for a smart contract under attacker’s control.

• Compromise of 3rd Party Smart Contracts: Exploit smart contract vulnerabilities and then drain user assets that temporarily reside under the contract address ownership (there are numerous examples of bridge hacks that fall into this category).

The Human Factor: Design with Operator Error in Mind

From recent trends in Web3 attacks, it’s clear that the human factor plays a central role. Users might be lured into violating one or more best security practices without knowing – in the case of the Profanity bug hack, vanity Web3 addresses were generated that made it possible for attackers to derive the private key. Once the system is configured into a secure state, over time it is likely that the security posture will decay, if it requires regular end-user effort to upkeep.

In a recent 8 million USD exploit, users were lured into installing an unofficial update of a popular Web3 wallet. It is suspected that the fake wallet update involved users re-entering the seed phrase (giving the attacker full access to the victim’s crypto assets). The FailSafe threat model is designed with these seemingly game over scenarios in mind. In the later part of this section, we introduce how the defence-in-depth principle is applied throughout the lifecycle of a transaction, and how the application of FailSafe multi-layered defences minimises losses from the type of incidents noted above.