How to Ensure Web3 Users Are Safe from Zero Transfer Attacks

How to Ensure Web3 Users Are Safe from Zero Transfer Attacks

Authors: Vlad Estoup & Sebastian Fabry

Security is inherent at the protocol level, and many hacks and attack vectors are actively prevented through safe design best practices, audited and battle-tested code, and consistent testing. Phishing attacks however come not from finding an exploit in the code, but by manipulating the user’s behavior. So how can Web3 developers help keep users safe from this type of attack?

Let’s dive into a specific type of phishing exploit known as the “zero transfer attack.” This is a phishing technique where the attacker tricks the user into mistakenly sending funds to the attacker’s address, because it resembles a trusted address in the user’s transaction history. According to Coinbase, this approach has led to a loss of $19m in victim funds from various wallet providers between late November 2022 and February 2023, which is just the tip of the iceberg since it is difficult to distinguish between intentional and unintentional transactions. 

This research aims to highlight a behavior in the implementation of the ERC-20 token standard that has been recently exploited in the wild through address poisoning attacks. The motivations for publishing this are twofold: 

  • To shed light on a security issue in order to empower secure development best practices across smart contract developers
  • To invite suggestions and comments as to how the ERC-20 implementation could be improved to better protect users against address poisoning while simultaneously adhering to ERC-20 and without impacting the vast DeFi ecosystem

The Address Poisoning Attack

It is possible for any account to make a transaction that transfers zero tokens to another account. This transaction would be executed and recorded on the blockchain. An attacker would seek to use a zero transfer to leverage users’ tendencies to rely on transaction history and quickly validate wallet addresses by comparing the first and last several characters. By polluting the transaction history of users’ wallets, attackers are able to take advantage of those who quickly copy/paste addresses and conduct frequent transactions.

This phishing attack exemplifies how a behavior with no “direct” security impact can still lead to large financial consequences. An attacker would take advantage of this by following these three steps: 

  1. Execute a zero-value transaction from a wallet containing tokens, or vice-versa, to an attacker’s wallet that is similar to one that the victim’s wallet regularly interacts with.
  2. The user would accidentally copy/paste the address from the last wallet that interacted with theirs (in this case, the attacker’s). Sometimes, their wallet may wrongly suggest the attacker’s wallet, as it was the last one they interacted with on-chain. 
  3. Funds would be irreversibly sent to the attacker’s wallet. 

The Cause for the Attack Vector

The ERC-20 standard defines a set of rules and guidelines for implementing a token contract on the Ethereum blockchain. One of the core functions of an ERC-20 token contract is the transferFrom function, which allows a third party to transfer tokens from one address to another on behalf of the token owner. It requires approval from the token owner, which is usually set by calling the approve function which sets an allowance for the spender. This function can be regarded as the backbone of the ERC-20 DeFi ecosystem.

To quote directly from the ERC-20 standard regarding the transferFrom function:

The function SHOULD throw unless the _from account has deliberately authorized the sender of the message via some mechanism.

Transfers of 0 values MUST be treated as normal transfers and fire the Transfer event.

The OpenZeppelin implementation does its best to conform to these statements. Zero-value transfers are allowed in OpenZeppelin’s ERC-20, but because any address technically has a default allowance of 0 for any token, they can be executed from and to any address. 

The reason for this lies in how the _spendAllowance function evaluates the approval between the caller and the sender of the funds. There is a require statement that evaluates the currentAllowance against the amount requested by the sender, at which point it will return “ERC20: insufficient allowance” if the allowance is not sufficient for the transfer. 

That being said, there is a clear distinction between must and should in the specification. While the ERC-20 standard mandates that the function should throw unless the _from account has deliberately authorized the sender of the message via some mechanism, the implementation does not throw in the case of a zero-value transfer, because the currentAllowance would be zero, and thus equal to the amount. This aspect of the implementation highlights the subtle difference between should and must, as the must statement is strictly adhered to while the should statement is not interpreted as restrictively. 

Executing transferFrom with a value of 0 for any chosen from and to addresses will be successful, even if the approval between the from address (the sender of funds) and address(this) (the caller of the transferFrom function) has been explicitly set to 0 (not approved). This behavior is true for most ERC-20 contracts (Uniswap, Compound Finance, Solmate and many others behave this way) which means that there are almost no safeguards in place to prevent zero-value transactions.

This allows an attacker to execute transferFrom instructions from arbitrary addresses with an amount of 0. These transactions trigger a Transfer event, as with any other transfer. In this case, it would include the victim’s address, the attacker’s address, and a value of 0. If an off-chain client happened to be listening to this event (which is often the case for wallets or any application tracking transaction data), they would be polluted by this malicious data. This leads to the potential attack vector illustrated above.

Potential Solutions

The Discussed Solution

Some researchers have proposed an on-chain solution to address the ERC-20 standard address poisoning attack. The proposed solution involves modifying the require check within the _spendAllowance function to evaluate that the currentAllowance is greater than or equal to the maximum of amount and 1, which would require the Approval to be non-zero. 

This approach would swiftly address the issue of address poisoning attacks, which have become increasingly common in recent times. However, this implementation deviates from the statement “Transfers of 0 values MUST be treated as normal transfers and fire the Transfer event.” If this change was made, a currentAllowance of 0 would not satisfy this check.

Risk Assessment and Path Forward

It is important to understand that ERC-20 is final and cannot be updated, and even if it could, it would not affect the behavior of the many non-upgradeable contracts on the blockchain. 

The issue at hand is not with triggering the event itself, but rather with how off-chain tools display these events and how users rely on that information. Instead of trying to change a longstanding standard, it may be more effective to make changes to tools (e.g., block explorers, wallets, exchanges) by defaulting to not display or interact with zero-value transfers unless a toggle is activated.

Any changes on OpenZeppelin’s end to disallow or restrict zero-value transactions within its implementation could greatly impact its current use cases, perhaps even breaking many of them. Restricting this implementation risks creating more issues than the benefits it would bring to the community.

We invite suggestions as to how the ERC-20 implementation could be improved to better protect users against address poisoning while adhering to ERC-20 and without impacting the vast DeFi ecosystem.

The main way to address this issue, as of right now, is through continuous education and more secure UX patterns. By verifying addresses during transfers of tokens, and not relying on wallets’ built-in mechanisms for automatically pasting addresses in the to field, users can be one step ahead of malicious actors who take advantage of the “0 transfer”. 

As for how clients listen to these events, it makes sense to monitor for Transfer events when the _value is zero and treat these differently off-chain, perhaps by raising a notification or avoiding using the data to prepopulate address fields in the future. As an additional layer of security, blockchain-based address books that uniquely and distinctively identify each account can prevent accidental transfers to undesirable addresses. 

Implementing these guidelines can help improve the security of Web3 users. As has been shown, the security of the end user relies not only on the secure implementation of contract standards, but also the UX patterns of applications and wallets. 

OpenZeppelin has built the most-trusted open-source libraries for blockchain developers: Contracts version 4.8. Repositories are tested, secure, optimized and gas-efficient for Web3 developers to build and deploy dApps, DeFi and Web3 projects. 

These considerations are being shared in a continued effort to improve security best practices across the blockchain developer ecosystem. For security advisory, smart contract design, audits and incident response – get in touch with the OpenZeppelin security team.

Final Results – Blockchain Hacking Techniques of 2022 | Top 10

Final Results – Blockchain Hacking Techniques of 2022 | Top 10

In 2022, blockchain development saw increased participation and the launch of new technologies, but this also led to a surge in new hacking techniques and exploits leading to losses exceeding $3.7B. OpenZeppelin, in collaboration with the community of Web3 security experts, have documented the top security research from 2022 to promote best practices and effective security measures across the industry. This is crucial as blockchain technology becomes more widely adopted and impacts more aspects of daily life, there is a necessity to support developers and communities through safer Web3 experiences.

We’re thrilled to announce the final results of the Top 10 Blockchain Hacking Techniques of 2022.

This project was met with great participation from the community as well as our panel of Web3 security experts which include samczsun the Head of Security at Paradigm, Nikesh Nazareth a Security Researcher at OpenZeppelin, Tincho an Ethereum Security Researcher and the Creator of Damn Vulnerable Defi, cts the Co-Founder of Zellic and Perfect Blue, Independent Security Researcher Ashiq Amien, and Independent Security Researcher PwningEth.

This initiative not only highlights new and practical security research but also provides a must-read top 10 list for all blockchain security researchers and Web3 security enthusiasts. While other projects, such as DASP Top 10, identify the most common vulnerability types, our project showcased the most novel, pervasive, and impactful vulnerability types, techniques, and methodologies. We want to give credit to PortSwigger for leading the Top 10 Web Hacking Techniques project, which inspired us to create a similar initiative in the blockchain space.

This year’s Top 10 highlights that vulnerabilities can emerge in unexpected places, such as differences between low-level languages and high-level languages and a vulnerability related to wrapped tokens. The discoveries also underscore the significant impact of vulnerabilities that could lead to the loss of funds or even the collapse of entire protocols. It’s essential to collaborate and coordinate the disclosure process, as seen in the Compound-TUSD Integration Issue Retrospective.

The ranking includes both well-known teams and individual researchers, which emphasizes the importance of community-wide engagement in securing the blockchain ecosystem. The high bounties offered for these discoveries demonstrate the value of incentivizing security research.

Full List of Nominations 

The Web3 security research community submitted a pool of entries, from which the top ten were ultimately chosen. While these ten entries were deemed the most innovative and significant discoveries of 2022, it’s important to note that all submissions were of high caliber and warrant recognition. 

Here is the list of hacking techniques received during the submission phase.

OpenZeppelin is a leading blockchain security company providing products & audits to the most trusted organizations in Web3. The Top 10 Blockchain Hacking Techniques of 2022 provide critical insights into the ongoing challenges facing blockchain security. Ultimately, the collective efforts of the blockchain security community can help to ensure the safety and stability of blockchain protocols in the future.

Since 2016, OpenZeppelin has worked to secure the decentralized economy. We create products for security-minded builders and provide security solutions for industry leaders. Our partnerships with top L1s, L2s, DAOs, DeFi protocols, and Web3 projects allow us to ensure that security best practices for blockchain development stay ahead of emerging threats. If you’re interested in getting in touch with the team for security solutions, smart contract advising, or audits then feel free to get in touch.