Recently, there have been numerous security attack incidents, and these incidents have had a significant impact on project teams. One of the primary reasons for these attacks is improper business logic design, which may contain vulnerabilities or weaknesses that hackers exploit for their attacks. Additionally, price manipulation is another factor leading to security attacks, where hackers may manipulate prices or market behavior to execute their attacks.In this article, we will examine the common characteristics of recent attacks and how project teams can avoid these issues.<h2 id="header-0">I. Improper Business Logic Design</h2><h3 id="unexpected-burning-of-pair-tokens">Unexpected Burning of Pair Tokens</h3>Many recent security incidents resulting from improper business logic design are primarily caused by anomalies in the balances of pair tokens.Some projects incorporate transaction fees or token burning functions into their business design. This means that during the token transfer process, a certain percentage of fees may be collected or a portion of the transferred tokens may be directly burned. This is often implemented to generate revenue for the project or incentivize users to hold tokens, among other purposes. However, if the code design is not robust enough, serious issues will arise.For instance, in the process of transferring tokens, some projects deduct extra tokens without considering that deducting from a pair could lead to significant consequences. In these projects, the logic of the transfer function is typically designed for the sender and receiver to execute a normal token transfer while deducting a certain amount for fees or burning. However, when the deduction address is a pair, it can result in an abnormal reduction in the balance of one token in the pair through non-trading means, causing a significant change in the K value and allowing a small amount of one token to be exchanged for a large amount of the other.Here is an example from an actual project’s code:The token contract had an issue of accidentally burning the balance of a pair. When the initiator of the token transfer is not the pair contract, it updates the pool by deducting 1% of the transaction amount from the pair’s token balance and then updates the reserves. Hackers can exploit this by repeatedly calling the transfer function to transfer tokens to themselves, causing one of the pair’s tokens to be depleted significantly. Eventually, they can exchange a large amount of the other token using the remaining tokens.<img src="https://academy-public.coinmarketcap.com/srd-optimized-uploads/ba90e48e550340e5ae3721ee5b82eaae.png" />The following is the real process of a security event:Initially, 2555 $WBNB tokens were exchanged for 139 billion Bamboo tokens.<img src="https://academy-public.coinmarketcap.com/srd-optimized-uploads/0de0bd095f3c40bd90f5a267eb459164.png" />Continuously using the transfer function to send tokens to oneself resulted in an abnormal decrease in the balance of Bamboo tokens in the pair.<img src="https://academy-public.coinmarketcap.com/srd-optimized-uploads/21e16430d1c342c98269ee5163ef29f1.png" />Repeatedly using the transfer function to send tokens to oneself further decreased the balance of Bamboo tokens in the pair.<img src="https://academy-public.coinmarketcap.com/srd-optimized-uploads/504c9ca2a8864dfc838633c39a8b1bb5.png" />Another example of accidentally burning pair tokens is shown in the following code. The contract checks the current transaction type, and if it is 2 (meaning the “to” address is the pair contract, akin to selling tokens), the contract records 20% of the transaction volume as the burning amount. This amount can be subsequently burned by calling the goDead() function, which can partially stabilize the token’s price. However, the contract did not consider certain situations, such as directly sending tokens to the pair, which would lead the contract to believe the user is selling tokens. In this case, those tokens can be fully extracted using the pair’s skim function. This means that despite no apparent change in the pair, repeatedly calling the goDead() function can unexpectedly decrease the balance of one token in the pair.<img src="https://academy-public.coinmarketcap.com/srd-optimized-uploads/b0da16f12fb747aab14c952409b27603.png" /><img src="https://academy-public.coinmarketcap.com/srd-optimized-uploads/87e0535db8b74c98afcdcbf76f8067a3.png" />The following is also a real process of a security event:Continuously using the transfer and skim functions to control the amountToDead value abnormally.<img src="https://academy-public.coinmarketcap.com/srd-optimized-uploads/d2d2d92049c2451ba069516779582cce.png" />Calling the goDead() function to burn tokens in the pair.<img src="https://academy-public.coinmarketcap.com/srd-optimized-uploads/a0982392ea6c44eabf00f3867dfb404b.png" />Exchanging a small amount of tokens for a large amount of USDT.<img src="https://academy-public.coinmarketcap.com/srd-optimized-uploads/5a5c476b5b0b4d83a4562ebdc54cafee.png" />In summary, the transfer function of tokens must be carefully designed to avoid accidental deductions from pair balances. Pair balances should only change during liquidity addition, removal, and trading processes, and the changes should not exceed the incoming amount to ensure the health of pair funds.<h2 id="header-1">II. Price Manipulation Issues</h2>For attacks related to price manipulation, the main cause is often that project contracts do not consider the possibility of price manipulation when obtaining prices. This is especially true for business logic functions involving two reverse calculations, such as stake &amp; unstake, deposit &amp; withdraw, which generally use the same parameters but apply opposite calculation logic.Between these two operations, if it’s possible to control some or all of the parameters through other functions or contracts unevenly, there can be a price difference between the two operations, potentially leading to asset theft.<h3 id="1-read-only-reentrancy">1. Read-Only Reentrancy</h3>Reentrancy has always been one of the most common and impactful vulnerabilities in the blockchain ecosystem. In the early days of Ethereum, reentrancy attacks were often due to the target function fallback() calling the project contract again, while the project contract’s variables had not yet been updated. This could bypass certain checks, such as DAO events.As the Ethereum ecosystem has grown and matured, project teams have become more focused on preventing reentrancy attacks, and with the introduction of solidity version 0.8.0 and later, active checks for overflows have become the norm. Today, more attacks occur through reentrancy to control prices or parameters to achieve malicious goals.For example, recent occurrences of frequent read-only reentrancy are due to variables not being completely updated before and after reentrancy, causing the price calculation function called during reentrancy to produce abnormal results, leading to asset theft.Readers interested in this topic can refer to the following link: <a href="https://www.beosin.com/resources/essential-auditing-knowledge--what-is-the-difficult-to-guar" rel="noopener noreferrer nofollow">Essential Auditing Knowledge | What is the Difficult-to-Guard “Read-Only Reentrancy Attack”</a>?<h3 id="2-dependency-on-pair-balances">2. Dependency on Pair Balances</h3>Pairs can most accurately reflect changes in token prices and provide the most precise source of price information. However, the prices in a pair are instantaneous and can be manipulated through large token exchanges, resulting in sudden price surges or crashes. If business logic relies on the prices in the pair as parameters for calculations, it can lead to unexpected results.For example, the burnForEth function determines the amount of ETH to send to the caller based on the quantity that can be exchanged from the pair. This quantity is calculated based on the balances of two tokens in the pair. Under normal circumstances, this represents the most accurate price. However, if one token from the pair is exchanged in large quantities for ETH in advance, it can cause a significant drop in the price of ETH within that pair. As a result, the calculation for the amount of ETH that can be exchanged becomes abnormally high, causing the contract to send more ETH to the caller. Finally, the caller can exchange the extra ETH back using the pair, restoring the price to normal.<img src="https://academy-public.coinmarketcap.com/srd-optimized-uploads/62505c02533a40ad8df82617c0248994.png" />Here is a real process of a security event:The attacker used a flash loan to exchange a large amount of WAX tokens, causing the price of WAX to surge.The attacker continuously called the burnForEth function to burn WAX and withdraw ETH. At this point, the price of WAX used for the calculation had surged, allowing the attacker to obtain more ETH.<img src="https://academy-public.coinmarketcap.com/srd-optimized-uploads/ef1393bbde42496a96374d632d479ddd.png" /><img src="https://academy-public.coinmarketcap.com/srd-optimized-uploads/549062df8aa34698ab00912f5da98334.png" />Finally, the attacker exchanged the ETH back and repaid the flash loan, making a profit.<img src="https://academy-public.coinmarketcap.com/srd-optimized-uploads/2fab100857c540b483698b90faff2b55.png" />In conclusion, security incidents have always been one of the most significant threats in the blockchain ecosystem, and project teams need to remain vigilant. Business logic that involves price calculations should have rigorous controls, and it’s advisable to avoid direct reliance on pair balances for price calculations. When calling external functions to obtain prices, consider whether they can be manipulated. Project teams can also collaborate with professional security partners to detect and address potential security threats promptly.<h2 id="header-2">Contact</h2>If you need any blockchain security services, welcome to contact us:<a href="https://beosin.com/" rel="noopener noreferrer nofollow">Official Website</a> <a href="https://eagleeye.space/" rel="noopener noreferrer nofollow">EagleEye</a> <a href="https://kyt.beosin.com/" rel="noopener noreferrer nofollow">KYT</a> <a href="https://twitter.com/Beosin_com" rel="noopener noreferrer nofollow">Twitter</a> <a href="https://t.me/beosin" rel="noopener noreferrer nofollow">Telegram</a> <a href="https://www.linkedin.com/company/beosin" rel="noopener noreferrer nofollow">Linkedin</a>

Security Audit | What Are the Common Characteristics of Recent Web3 Attacks, and How Can Projects Avoid These Issues?

Table of Contents

Beosin

Other articles published on Oct 16, 2023

Ethereum Staking Entices Fewer Investors: What Does It Signal?

US Government Becomes a Major Bitcoin Holder

Clarification on sharing false spot Bitcoin ETF news

Trezor's New Products Aim to Streamline Crypto for Beginners, Limited Edition Trezor Safe 3 Sold ...

Solana and Dubai’s DMCC forge alliance to fuel blockchain boom

Check out Onyx, An Innovative and user-friendly DeFi Protocol

Join our free newsletter for daily crypto updates!