BonqDAO, a decentralized, and over-collateralized lending platform built on the Polygon network, suffered a major security breach on February 2, 2023. The platform enables users to borrow against their own tokens by locking them up in a Trove, a smart contract controlled only by the users, and minting a low volatility payment coin, BEUR, pegged to the Euro.
The attack exploited a vulnerability in the integration of the Tellor Oracle system, which is used by BonqDAO to obtain token price information. By manipulating the price of AllianceBlock's WALBT tokens, the attacker managed to steal 100 million BEUR stablecoins and 120 million Wrapped AllianceBlock Tokens (WALBT). This article will provide an in-depth analysis of the hack, detailing the impact it had on both the platform and its users.
The hack had a profound impact on BonqDAO, the affected tokens, and the DeFi ecosystem at large. The following are the key areas affected by the attack:
The attacker was able to steal 100 million BEUR stablecoins and 120 million WALBT tokens. The stolen funds were converted into other cryptocurrencies and laundered through Tornado Cash, a privacy tool for Ethereum transactions, making it harder to trace and recover the stolen assets.
The news of the hack led to a significant decline in the value of the affected tokens. Bonq Euro (BEUR), a stablecoin pegged to the Euro, fell to an all-time low of $0.15 on February 3, which is a severe depreciation for any stablecoin. Additionally, the AllianceBlock Token (ALBT) experienced a major hit as collateral damage from the attack.
Tellor is a decentralized Oracle protocol that provides an immutable, open, and permissionless network for data reporting and validation. It enables anyone to provide data and allows everyone to verify its accuracy. In the context of BonqDAO, Tellor is used as a price oracle to obtain token price information.
To become a reporter for the Tellor Oracle, a user needs to stake a certain amount of TRB tokens. Once the required stake is deposited, the user is eligible to report data using the submitValue function. However, it is important to note that if a user reports invalid or malicious data, their staked amount may be slashed as a penalty. This mechanism encourages accurate reporting and helps maintain the integrity of the data provided on the network.
The submitValue function, as seen in the code snippet below, is part of the TellorFlex contract:
This function allows the reporter to submit a value to the Tellor Oracle network. In summary, the Tellor Oracle allows anyone to become a reporter by staking a certain amount of TRB tokens and submitting data using the submitValue function. This function ensures that only users with a sufficient stake can report data, and the slashing mechanism discourages the submission of invalid data, maintaining the integrity and accuracy of the data provided on the network
The attacker began by staking 10 TRB (Tellor's native tokens) on the TellorFlex oracle allowing them to become a reporter.This is a necessary step for anyone who wants to submit a new data point to the Tellor Oracle. The staking serves as collateral, meaning if the submitted data is found to be incorrect or malicious, the stake can be forfeited.
The attacker submitted a false price for WALBT tokens, setting it at 5,000,000 USD. This is much higher than the actual price. The Tellor Oracle, which is used by BonqDAO to get price information, accepted this manipulated price.
With the manipulated price in place, the attacker created a Trove within the BonqDAO platform. A Trove is a smart contract that allows users to lock up their tokens as collateral and borrow other tokens against it. The attacker deposited a small amount of WALBT tokens (0.1 WALBT) into the Trove, and due to the inflated price, they were able to borrow $100 million worth of BEUR tokens, which are stablecoins pegged to the Euro.
The attacker then used Uniswap, a decentralized exchange, to swap the borrowed BEUR tokens for other cryptocurrencies like USDC, a stablecoin pegged to the US Dollar.
The attacker created a second Trove with WALBT tokens and deposited 13.2 WALBT tokens into it. Then, the attacker staked another 10 TRB on the TellorFlex Oracle, but this time submitted a much lower price for WALBT tokens (0.0000001 USD).
With the low WALBT token price in place, the attacker proceeded to liquidate multiple Troves of WALBT tokens. Liquidation in this context means repaying the borrowed BEUR tokens and getting the locked WALBT tokens back. Since the WALBT price was now extremely low, the attacker could repay the borrowed BEUR tokens with a minimal amount of WALBT tokens, effectively stealing a large amount of WALBT tokens in the process.
After successfully stealing 113.8 million WALBT tokens and 98 million BEUR tokens, the attacker began moving the funds out through Tornado Cash, a privacy tool for Ethereum transactions. This allowed them to launder the stolen funds and make it harder to trace.
The attacker exploited the vulnerability in the integration of the Tellor Oracle system, which allowed them to manipulate the price and ultimately steal a large amount of tokens.
To prevent similar vulnerabilities from being exploited in the future, several mitigation strategies can be implemented to secure the price oracle integration within DeFi platforms like BonqDAO.
Instead of relying on instant prices, DeFi platforms should use the Time-Weighted Average Price (TWAP) over a predetermined period. This approach minimizes the risk of price manipulation by averaging out the price fluctuations and provides a more accurate representation of the token's value.
Integrating multiple price oracle sources can help minimize the impact of a single oracle failure or manipulation. By aggregating data from different sources, the platform can cross-verify the accuracy of the price data and ensure a more reliable feed.
Implementing real-time monitoring systems to detect sudden and significant price changes can help in identifying potential price manipulation attempts. By setting up alerts for abnormal price fluctuations, the platform can take corrective actions and prevent further exploitation.
In the case of BonqDAO, the reliance on instant prices from the Tellor oracle made the platform susceptible to price manipulation. By using the latest price data without allowing time for validation and scrutiny by other network participants, BonqDAO exposed itself to the risk of accepting false price information. This vulnerability enabled the attacker to manipulate the price of WALBT tokens and exploit the platform, causing significant financial losses. Implementing the above-mentioned mitigation strategies can help platforms like BonqDAO to better secure their price oracle integrations and prevent future attacks.
Attacker's Address: 0xcAcf2D28B2A5309e099f0C6e8C60Ec3dDf656642
Attacker's Contract: 0xed596991ac5f1aa1858da66c67f7cfa76e54b5f1
TellorFlex Contract: 0x8f55D884CAD66B79e1a131f6bCB0e66f4fD84d5B
BONqDAO Contract: 0x4248fd3e2c055a02117eb13de4276170003ca295
Attack Transaction 1: 0x31957ecc43774d19f54d9968e95c69c882468b46860f921668f2c55fadd51b19
Attack Transaction 2: 0xa02d0c3d16d6ee0e0b6a42c3cc91997c2b40c87d777136dedebe8ee0f47f32b1
After the successful execution of both transactions, the attacker was able to steal 113.8 million WALBT tokens and 98 million BEUR tokens. They then proceeded to convert the BEUR tokens into stablecoins like USDC using Uniswap, totaling around $534K.The attacker moved the funds to the Ethereum blockchain and started to launder their gains through Tornado Cash, a privacy solution. This allowed them to obscure the origin of the funds, making it more difficult for anyone to trace their movements.
The BonqDAO hack serves as a stark reminder of the risks involved in decentralized finance and the need for stringent security measures to protect users' funds. By exploiting a vulnerability in the price oracle integration, the attacker was able to manipulate the price of the WALBT token and cause significant financial losses for the BonqDAO platform and its users.
This incident highlights the crucial role that thorough, smart contract audits play in safeguarding DeFi platforms. By conducting a comprehensive audit of the smart contracts involved, potential vulnerabilities and weaknesses can be identified and addressed before an attacker can exploit them. For a reliable and professional smart contract audit, consider partnering with BlockApex.io, a leading provider of security solutions for blockchain-based projects. Through rigorous examination and assessment, BlockApex.io can help ensure that your smart contracts are secure, protecting your platform and users from potential hacks and exploits.
Orion Protocol is a liquidity aggregator that connects to major cryptocurrency exchanges and swap pools, both centralized and decentralized. This allows users to obtain the best price for their trades from a single platform. On February 2, 2023, the Orion Protocol was exploited on both Ethereum and BNB Chain, leading to a loss of approximately $3 million in assets due to a reentrancy vulnerability in one of its core contracts.
The attackers exploited a reentrancy vulnerability in the Orion Protocol's core contract, ExchangeWithOrionPool, by constructing a fake token (ATK) with self-destruct capability that led to the transfer() function. They then carried out the attack by depositing 0.5 USDC and using a flash loan of 191,606 USDC to swap through the Orion pool via the path (USDC-ATK-USDT).
A reentrancy attack is a type of security vulnerability in a smart contract, where a malicious actor exploits the contract's logic to repeatedly call a function before the previous function call finishes. This can lead to unintended consequences, such as stealing funds or locking them indefinitely.
The purpose of the doSwapThroughOrionPool function is to perform a token swap using the Orion Pool, a decentralized exchange (DEX) that allows users to trade tokens based on the provided swap data.
This function is called by external contracts or users to initiate a token swap. The doSwapThroughOrionPool function takes the following parameters:
user: The address of the user initiating the swap.
to: The recipient address where the swapped tokens will be sent.
swapData: A struct containing the swap data, including path, amount to spend, amount to receive, whether it's an exact spend or exact receive, and the supporting fee.
The primary issue in the doSwapThroughOrionPool function is the insufficient validation of the path addresses provided in the swapData parameter. The function allows a malicious user to provide a path that includes an arbitrary contract address, which can potentially execute unintended actions.
The code snippet below shows where the new path is created, and the addresses in the provided path are copied to the new path:
The function does not validate whether the addresses in the path are legitimate tokens, pools, or factories. An attacker can exploit this vulnerability by including a malicious contract address in the path that manipulates the token transfers or performs other unexpected actions when called within the swap process.
The attacker creates a malicious token contract (ATK) with a transfer() function that has a callback mechanism. They transfer and authorize the ATK token in preparation for the attack.
The attacker takes a flash loan of 191,606 USDC from a lending platform.
The attacker calls the doSwapThroughOrionPool() function of the vulnerable smart contract to swap the borrowed 191,606 USDC using the exchange path [USDC, ATK, USDT]. The ATK token is the malicious token created by the attacker, which will be used for the callback.
As the doSwapThroughOrionPool() function in Orion protocol executes the token swap, it triggers the transfer() function of the malicious ATK token. The transfer() function of the ATK token then calls back the depositAsset() function of the vulnerable smart contract through the callback mechanism.
Due to the lack of reentrancy protection in the depositAsset() function of Orion protocol, the attacker is able to re-enter the depositAsset() function through the ATK token's transfer() function during the token swap. As a result, the smart contract records the attacker's deposit amount as the full flash loan amount of 191,606 USDT, inflating the balance of tokens in the contract.
The inflation of the attacker's deposit amount in the Orion protocol's smart contract, combined with the token swap, creates an artificial price increase for the USDT tokens. The smart contract calculates the difference in USDT token balance before and after the swap, resulting in the attacker receiving more USDT tokens than they should have.
After accumulating a significant deposit amount, the attacker calls the withdrawal function of the vulnerable smart contract to withdraw 5,689,532 USDT, which includes their inflated deposit and the profit from the exploit.
The attacker pays back the original flash loan amount of 2,853,326 USDT, keeping the remaining profit for themselves.
The attacker swaps their remaining profit of 2,836,206 USDT for 1,651 WETH and transfers it to their wallet or another platform for further anonymity.the attacker transferred approximately 1100 ETH into Tornado Cash, a privacy-focused protocol, to obfuscate their tracks.
The attacker replicated this attack on the BNB Chain, generating an additional profit of $191,434. Consequently, the total profit amassed from both attacks reached approximately $3 million, with $191,434 earned on the BNB Chain and $2,836,206 on the Ethereum network.
Implement reentrancy guards in your smart contracts, such as the nonReentrant modifier provided by OpenZeppelin. This will prevent functions from being called multiple times before the original call has completed.
Ensure that your smart contract functions follow the checks-effects-interactions pattern, where you first perform checks, then update the contract state, and finally interact with external contracts. This can prevent unexpected state changes during external contract interactions.
ATK Token(Fake): 0x64acd987a8603eeaf1ee8e87addd512908599aec
Attacker’s 1st Address: 0x3dabf5e36df28f6064a7c5638d0c4e01539e35f1
Attacker’s 2nd Address: 0x837962b686fd5a407fb4e5f92e8be86a230484bd
Attacker’s Contract(ETH): 0x5061F7e6dfc1a867D945d0ec39Ea2A33f772380A
Vulnerable Contract: 0x420a50a62b17c18b36c64478784536ba980feac8
Attack Txn (ETH): 0xa6f63fcb6bec8818864d96a5b1bb19e8bd85ee37b2cc9
ATK Token(Fake): 0xc4da120a4acf413f9af623a2b9e0a9878b6a0afe
Attacker’s 1st Address: 0x3dabf5e36df28f6064a7c5638d0c4e01539e35f1
Attacker’s 2nd Address: 0x837962b686fd5a407fb4e5f92e8be86a230484bd
Attacker’s Contract(BSC): 0x84452042cB7be650BE4eB641025ac3C8A0079b67
Attack Txn (BSC): 0xfb153c572e304093023b4f9694ef39135b6ed5b251545317
Reentrancy attacks are a significant threat to smart contracts, potentially causing substantial financial losses and damage to the reputation of projects. By understanding the nature of these attacks and implementing the recommended mitigation strategies, developers can significantly reduce the risk of such vulnerabilities in their smart contracts.
It is crucial to follow best practices in smart contract development and stay updated on the latest security techniques. Regular audits, testing, and code reviews are essential to identify potential vulnerabilities and ensure the safety and integrity of your smart contracts.
Finally, to ensure the highest level of security for your smart contracts, consider partnering with professional auditing firms like BlockApex.io. Their expertise in smart contract audits and security assessments can provide invaluable insights and help safeguard your projects from potential threats and vulnerabilities.
Zunami is a decentralized protocol operating in the Web3 space, specializing in issuing aggregated stablecoins like UZD and zETH. These stablecoins are generated from omnipools that employ various profit-generating strategies. Recently, the protocol was exploited, resulting in a loss of $2.1M. The exploit specifically targeted Zunami's UZD and zETH liquidity pools on the Curve ecosystem. This analysis delves into the impact and mechanisms for this kind of vulnerability.
The Zunami Protocol experienced a severe price manipulation attack that led to a loss of approximately $2.1M. The attacker was able to exploit Zunami’s zETH and UZD liquidity pools on the Curve platform. This caused the zStables (zETH and UZD) to depeg dramatically - zETH by 85% and UZD by 99%.
The Zunami Protocol hack serves as a cautionary tale about the risks and vulnerabilities present in complex decentralized financial systems. The exploitation capitalized on multiple weaknesses in Zunami's design, leading to a substantial loss of funds and trust. Given the growing number of such exploits, it's imperative for projects in the DeFi space to take robust security measures seriously, undergoing rigorous audits from a reputed audit firm like Blockapex and implementing strong protective mechanisms to shield both their assets and their user base.
Jimbo's Protocol is a decentralized finance (DeFi) system built on the Arbitrum chain. The protocol uses a semi-stable floor price for its ERC-20 token, $JIMBO, backed by a treasury of Ether (ETH). However, despite its pioneering efforts to maintain on-chain liquidity and price floors, Jimbo's Protocol recently faced a Flash loan attack. On May 28, 2023, a sophisticated attacker managed to exploit a loophole in the protocol's slippage control mechanism, walking away with approximately $7.5 million in ETH.
The attack had immediate and severe consequences for Jimbo's Protocol and its community. The attacker successfully drained a large portion of the treasury's ETH, affecting the protocol's stability and trustworthiness. The incident led to a sharp 40% decline in the value of $JIMBO, eroding the token's market position and investor confidence.
In decentralized finance (DeFi), liquidity rebalancing is the process of reallocating assets within a liquidity pool to ensure efficient capital utilization and smooth price discovery. In simple terms, it means making sure there's enough "money" in the right places in a trading pool to make trades easy and fair.
Slippage occurs when the price of an asset changes between the time you place an order and the time the order is fulfilled. In DeFi, it's particularly important to control slippage to prevent significant price fluctuations that could result from large trades.
In $JIMBO's case, rebalancing happens via three primary functions: Shift(), Reset(), and Recycle(). These are triggered based on the state of different bins—Floor Bin, Active Bin, and Trigger Bin.
The Shift() function plays a crucial role in the $JIMBO protocol, automatically activating when the Active Bin (the pool bin where the current trading price resides) moves past the Trigger Bin. The function performs two primary actions:
Simultaneously, the Shift() function also invokes a Reset() function call to redistribute the remaining $JIMBO tokens within the pool.
For more comprehensive insights into how these bins operate within the protocol, please refer to this Link
Step 1: Obtain Initial Funds
Step 2: Inflate $JIMBO Price
Step 3: Transfer Tokens to Contract
Step 4: Invoke Shift()
Step 5: Crash the Market Price
Step 6: Trigger Another Rebalance
Step 7: Exploit and Profit
The attacker then returns the initial ETH borrowed through the flash loan, retaining a substantial net gain of 7.5 million.
The critical flaw was the absence of slippage controls in the Shift() function, enabling the attacker to trigger rebalancing actions at artificial price levels. Once liquidity was redeployed at these inflated prices, the attacker could then manipulate the market to purchase tokens at a much lower cost, making a substantial profit in the process.
Attacker’s Address(ETH)
Notable Transactions:
JimboController Contract
Attack Transaction
The protocol also sent an On chain message to the hacker
A system with a more sophisticated rebalancing mechanism that includes proper slippage control, could have likely prevented this exploit. By undergoing a comprehensive security audit, potentially from firms like BlockApex, protocols can identify and address these vulnerabilities before they're exploited.
The Jimbo Protocol incident serves as a cautionary tale that even innovative DeFi protocols are vulnerable to sophisticated attacks. This event highlights the importance of comprehensive security audits, a service that BlockApex specializes in, to identify and mitigate vulnerabilities in DeFi protocols. As the DeFi sector continues to evolve, so should its security measures to protect investor interests and maintain system integrity.
Platypus Finance is a decentralized finance (DeFi) platform. On February 17, 2023, the platform was hacked, resulting in a loss of approximately $8.5 million worth of assets. In this hack analysis, we will delve into the details of the attack, the vulnerability that was exploited, and the impact it had on the platform and its users.
The financial implications of this exploit are substantial, with the attacker managing to siphon off a significant amount of funds. By exploiting the vulnerability in the emergencyWithdraw function of the MasterPlatypusV4 contract in Platypus Finance, the attacker was able to create "bad debt" in the system, allowing them to acquire the debt's upside.
As a result the attack hack had a significant impact on the Platypus Finance ecosystem and its users. The attack resulted in a loss of approximately $8.5 million worth of tokens and caused a large decline in the price of the USP stablecoin. The price of USP fell by more than 66% compared to its intended $1 peg, and the project's native PTP token lost a quarter of its value in a day. The attacker was able to mint 40 million USP tokens from the Platypus Finance's contract MasterPlatypusV4 contract using 44 million Platypus LP-USDC tokens as collateral. However, the team was able to recover approximately $2.4 million USDC from the attack contract, reducing the overall impact of the hack.
The emergencyWithdraw function allows users to withdraw their funds from the pool without accounting for rewards. This function is intended for emergency situations and is designed to be used when a user needs to exit the pool quickly without waiting for the rewards to accrue.
The emergencyWithdraw function takes a pool ID as an argument and retrieves the corresponding pool and user information from the mapping. It then resets the rewarder to zero, transfers the user's LP tokens to their address, updates the sumOfFactors, and sets the user's amount, factor, and rewardDebt to zero
The isSolvent function in Platypus Finance contract is used to determine if a user's collateral position is solvent, meaning if the value of the collateral is greater than or equal to the outstanding debt. It takes the user's address, the token address, and a boolean indicating if the position is being opened or closed as arguments.
The isSolvent function first retrieves the user's debtShare and checks if it is zero. If it is, it returns true, indicating that the position is solvent. If the debtShare is non-zero, it calculates the debtAmount by multiplying the debtShare with the totalDebtAmount and interest since the last accrual, and dividing the result by the totalDebtShare. It then checks if the debtAmount is less than or equal to the borrow limit if the position is being opened or the liquidate limit if the position is being closed.
The vulnerability in the emergencyWithdraw() and _isSolvent() functions is due to an improper solvency check that allows an attacker to withdraw their collateral without fully paying back their debt. Specifically, the solvency check only considers whether the user's debt amount exceeds the borrowing limit, but does not take into account the actual debt owed by the user.
This means that an attacker can deposit collateral to borrow USP tokens, but then withdraw their collateral without paying back the full amount of USP borrowed. Since the solvency check only considers the borrowing limit, the attacker can appear solvent and pass the check even if they owe a significant amount of debt.
The vulnerability is caused by a logical flaw in the code, as the solvency check should also consider the actual debt owed by the user, not just the borrowing limit. The code should be updated to accurately calculate the amount of debt owed and ensure that it is fully paid back before allowing a user to withdraw their collateral.
The attacker borrowed a massive 44 million USDC from a lending protocol, just like taking out a huge loan from a bank.
The attacker deposited the 44 million USDC into a platform called Platypus USDC Asset (LP-USDC) and received 44 million LP-USDC tokens similar to a person depositing money in a bank and receiving a line of credit.
Using the 44 million LP-USDC tokens as collateral, the attacker borrowed 41.79 million USP tokens from the system, similar to taking out a second loan by leveraging the line of credit received earlier.
The attacker found a vulnerability in the system's solvency check (emergencyWithdraw and isSolvent functions) , which didn't properly account for the debt amount. This loophole allowed the attacker to withdraw the initial collateral without repaying the borrowed USP tokens, as the debt was within the 95% borrowing limit cap.
The attacker used the loophole to withdraw their initial collateral (44 million LP-USDC tokens), equivalent to taking back their initial deposit from the bank without repaying the second loan.
The attacker withdrew the 44 million USDC from the LP-USDC Asset, converting the collateral back into cash.
The attacker swapped the 41.79 million USP tokens for various stablecoins across multiple platforms, making a total profit of approximately $8.5 million, similar to exchanging the second loan for valuable assets.
Finally, the attacker repaid the initial 44 million USDC flash loan, keeping the $8.5 million profit.
To mitigate the vulnerability in the emergencyWithdraw() and _isSolvent() functions in Platypus Finance, the solvency check should be updated to consider the actual debt owed by the user rather than only taking into account the debt limit. This can be achieved by implementing a check that validates the user's current debt amount against their collateral value.
This will ensure that users cannot withdraw their collateral without fully paying back their debt, thereby preventing the creation of "bad debt" in the system. It is also recommended to perform thorough testing and auditing of the updated solvency check to ensure its effectiveness in preventing such attacks. Additionally, implementing a time-delayed withdrawal feature can provide an additional layer of security and prevent attackers from instantly withdrawing their collateral in case of a vulnerability exploit.
Attacker's address: 0xeff003d64046a6f521ba31f39405cb720e953958
Attack transaction: 0x1266a937...
Attack contract: 0x67afdd6489d40a01dae65f709367e1b1d18a5322
The hack resulted in USP being depegged by over 50%, and the stolen $8.5 million remains in the hacker's contract. $1.5 million of stolen USDT has been blacklisted.
In conclusion, the MasterPlatypusV4 hack, a.k.a Platypus Finance hack, highlights the importance of robust security measures and thorough audits in the world of decentralized finance. The attacker exploited a vulnerability in the emergencyWithdraw() function, which only checked the isSolvent variable and disregarded the debt amount. By carefully navigating through the various steps, the attacker managed to make a profit of approximately $8.5 million in stablecoins, causing significant damage to the protocol and its users.
This incident serves as a reminder that even well-designed protocols can have unforeseen vulnerabilities. It is crucial for DeFi projects to implement stringent security practices, regularly update their code, and undergo comprehensive audits by reputable firms. To ensure the highest level of security and protection for your DeFi project, consider partnering with a trusted auditing firm like BlockApex for thorough and reliable smart contract audits. By taking these precautions, projects can minimize the risk of such hacks and foster a safer ecosystem for all participants.
Dexible Finance is a decentralized finance (DeFi) aggregator. It allows users to trade tokens seamlessly across multiple DEXes in a single interface, optimizing for the best rates and lowest fees. However, on February 17, 2023, a security vulnerability was exploited in the platform's recently introduced v2 smart contracts, resulting in the loss of approximately $2 million worth of tokens. In this hack analysis, we will discuss the nature of the vulnerability, the attackers' exploitation method, and the overall impact of the hack on the platform and its users.
The Dexible Finance hack had significant consequences for the platform and its users. The attackers managed to exploit a vulnerability in the selfSwap function of the platform's v2 smart contracts, which allowed them to siphon tokens from users who had granted permission to Dexible to manage their tokens. The hack affected a total of 17 user accounts, with the majority of losses coming from a single address belonging to BlockTower Capital, a prominent investment firm.
In total, approximately $1.5 million was stolen on the Ethereum network and an additional $450k on other platforms (Arbitrum and BSC). The stolen funds were sent to Tornado Cash, a privacy-focused mixer service, to obfuscate the attackers' tracks and make it difficult to trace the origin of the stolen funds.
The selfSwap function is a part of Dexible's smart contract and is responsible for enabling users to perform token swaps without the involvement of an affiliate or automatic discounts. The function takes a SwapTypes.SelfSwap request as an input, which contains information about the tokens to be swapped, the fees, and the routing details.
It creates a SwapTypes.SwapRequest object with the provided data and initializes a SwapMeta object that stores various metadata about the swap, including fee details, gas amounts, and balances.Once the SwapMeta object is created, the selfSwap function calls the fill function, passing the SwapRequest and SwapMeta objects as arguments. After the fill function returns the updated SwapMeta object, the selfSwap function proceeds with the postFill method to finalize the token swap.
The fill function is called by the selfSwap function and is responsible for executing the token swap based on the routing information provided in the SwapRequest object. It first performs a preCheck to ensure that the request and metadata are valid. Then, it iterates through the specified routes and approves each route amount for the respective spender. The function then calls the router specified in each route using the routerData provided.
If the router call is unsuccessful, the function reverts with an error message. Otherwise, the fill function calculates the output amount of the token swap and checks if it is sufficient compared to the requested amount. If the output is insufficient, the function reverts with an error message. Finally, the fill function returns the updated SwapMeta object to the selfSwap function.
The vulnerability in the selfSwap and fill functions lies in the lack of validation and verification for the router address (routerID) provided in the SwapRequest object. This omission allows an attacker to pass their own contract address as the router, which is not verified on-chain. As a result, the fill function performs a delegate call to the attacker's provided routerData, allowing the attacker to transfer the victim's approved tokens directly to their account.
The absence of routerID validation and an on-chain verification mechanism in these two functions leaves the smart contract susceptible to manipulation by malicious actors, leading to the loss of tokens for the affected users.
The attacker creates their own malicious contract that mimics a legitimate DEX. This contract contains a "transferFrom" function, which can transfer tokens from an approved account to the attacker's address.
The attacker prepares a SwapTypes.SelfSwap request containing the details of the tokens they want to swap. They provide the address of their malicious contract as the router in the routing information, bypassing any on-chain verification.
Analogy: It's like a thief providing false bank details to a victim, tricking them into sending money to the thief's account instead of a legitimate bank.
The attacker calls the selfSwap function on the Dexible contract, passing their crafted selfSwap request. The Dexible contract processes the request and calls the fill function with the SwapRequest and SwapMeta objects.
During the execution of the fill function, the malicious router address provided by the attacker is used to perform a delegate call to the routerData. Since there is no validation for the routerID, the fill function ends up calling the attacker's malicious contract instead of a legitimate DEX.
The malicious contract's "transferFrom" function is executed, transferring the victim's approved tokens directly to the attacker's address. The attacker then converts these tokens to other cryptocurrencies or sends them to privacy-focused services like Tornado Cash to obfuscate their tracks.
Analogy: The thief withdraws the funds from the victim's account and moves them through various accounts or services to hide the source of the stolen funds.
By following these steps, the attacker can exploit the vulnerability in the selfSwap and fill functions to steal tokens from unsuspecting users who have granted the Dexible contract permission to manage their tokens.
Implement a mechanism within the selfSwap function to ensure that the provided router address is a legitimate DEX. An on-chain allowlist or a registry of approved DEX addresses can be used to validate the router address before proceeding with the swap.
Analogy: A bank verifying the authenticity of a recipient bank account before allowing a funds transfer.
Include a whitelist of approved router addresses in the Dexible contract. By doing so, you can prevent users from interacting with malicious contracts, as only approved router addresses will be allowed to process swaps.
Analogy: A bank only allowing transfers to verified and approved external accounts.
Add validation checks within the fill function to ensure that the routerID provided in the selfSwap request matches a known and approved router address. This added layer of security can help prevent unauthorized access to users' funds.
Analogy: A bank double-checking the recipient account details during a transfer process to prevent fraudulent transactions.
Users should regularly review and revoke token allowances granted to contracts. By doing so, they can minimize the risk of losing funds due to vulnerabilities in the contracts they interact with.
Analogy: A bank customer frequently reviewing and updating their list of approved payees to ensure that their funds are only accessible to trusted parties.
By implementing these recommendations, the security of the Dexible contract can be significantly improved, reducing the risk of similar exploits in the future and providing a safer environment for users to manage their digital assets.
Transaction: 0x138daa4c…
To understand the attacker's actions, we can analyze the transactions on the blockchain associated with the hack. We'll use the transaction 0x138daa4c as a reference.
The attacker's address can be found from the transaction: 0x684083f312ac50f538cc4b634d85a2feafaab77a
By inspecting the transaction details on a blockchain explorer like Etherscan, we can find information such as:
The selfSwap request data, The gas used and the status of the transaction (successful or failed). The tokens involved in the swap and the amounts transferred.
After the attacker successfully exploited the vulnerability, they converted the stolen tokens to other cryptocurrencies or sent them to privacy-focused services like Tornado Cash to obscure their tracks. By tracing the flow of funds from the attacker's address, we can gather information about their actions after the hack.
Examining other transactions associated with the attacker's address can provide insights into any patterns or similarities with other hacks. Additionally, it can help identify if the attacker has targeted multiple platforms or contracts.
By analyzing the transactions related to the hack, we can better understand the attacker's methods, actions, and the impact of the exploit. This information can be useful for preventing similar incidents in the future and improving the security of smart contracts.
The Dexible hack serves as a stark reminder of the importance of thorough security measures and audits in the world of decentralized finance. By exploiting a vulnerability in the selfSwap and fill functions, the attacker was able to bypass important safeguards and steal millions of dollars from unsuspecting users.
The incident highlights the need for rigorous security practices such as verifying router addresses on-chain, implementing whitelists, and regularly reviewing approval allowances. Following these recommendations can help prevent similar attacks and create a safer ecosystem for users to interact with DeFi platforms.
One crucial step in ensuring the security of smart contracts is to have them audited by reputable firms like BlockApex. A thorough audit by experienced professionals can help identify potential vulnerabilities and weaknesses in the code, allowing developers to address them before deployment. This proactive approach to security can save projects from significant financial losses and protect the trust of their user base.
In conclusion, the Dexible hack underscores the importance of robust security measures in the rapidly evolving DeFi landscape. By learning from these incidents and implementing best practices, we can build a more secure and trustworthy decentralized finance ecosystem.
Kokomo Finance, a lending protocol that had recently launched on Optimism, rug pulls users and disappears with approximately $4 million worth of tokens. The project’s token, KOKO, had only been launched less than 36 hours before the rug. The rug occurred through changes made by the project’s deployer address, which rugged Wrapped Bitcoin deposits. The project’s website, Twitter, GitHub, and Medium, were deleted soon after.
Kokomo Finance has taken off with approximately $4 million worth of user funds, leaving users unable to withdraw their funds. Wrapped Bitcoin deposits were rugged, with almost $2M of tokens still remaining in the project’s pools on Optimism.
The deployer of KOKO Token, identified as address 0x41BE, created a malicious contract called cBTC, modified the reward speed, paused the borrow function, and replaced the implementation contract using the function mentioned below with the malicious one. Another address, 0x5a2d, approved the cBTC contract to spend 7010 sonne WBTC. After the implementation contract was switched to the malicious cBTC contract, the attacker used the 0x804edaad method to transfer sonne WBTC to address 0x5C8d. Finally, the address 0x5C8d swapped 7010 sonne WBTC for 141 WBTC (~4M) in profit.
The stolen funds are currently held in four addresses:
Here are some indicators to look for in a smart contract that may indicate it could be a rugpull:
Kokomo Finance’s rugpull serves as a warning to the importance of conducting thorough security audits and implementing proper security measures in decentralized finance. As the rug occurred through changes made by the project’s deployer address, it is important to ensure that all aspects of a protocol are audited and secured.
Also read Hack Analysis on Euler Finance
Safemoon is a decentralized finance (DeFi) project with over 2.5 million holders and more than $50 million locked in liquidity. It features a deflationary utility token, SAFEMOON, and has a fully diluted market capitalization of over $1 billion, according to CoinMarketCap. On March 28, 2023, Safemoon was hacked, and the attacker drained the SFM/BNB pool, resulting in a loss of $8.9M worth of ‘locked LP’.
Safemoon suffered an attack in which the SFM/BNB pool was drained, resulting in a loss of $8.9M worth of ‘locked LP’. The attack was carried out by exploiting a vulnerability in the new Safemoon contract that allowed anyone to burn SFM tokens from any address, thus inflating the price of SFM tokens in the pool. The attacker was able to drain the pool of BNB liquidity by selling previously acquired SFM tokens into the artificially inflated pool, resulting in a profit of 28k BNB. The hacker has claimed to return the funds, but there are doubts about their trustworthiness.
The vulnerability exploited in the Safemoon hack was introduced in the project's latest upgrade, which took place approximately six hours before the attack. The upgrade included a new implementation of the token contract, which mistakenly left the burn function as publicly callable. The code for the function is as follows:
The function transfers the specified amount of SFM tokens from the specified address to the bridgeBurnAddress, effectively burning them. However, the mistake in the implementation made anyone call it and burn tokens from any address.
The attacker exploited the burn function, and the majority of the funds were transferred to 0x237D where they remain at the time of writing. The exploit transaction can be traced using the transaction hash: 0x48e52a12…, and the attacker’s address is 0x286e09932b8d096cba3423d12965042736b8f850.
Safemoon’s hack serves as a reminder of the risks involved in deploying new features into the mainnet without proper security checks. Projects need to ensure that their smart contracts are secure and audited to prevent such exploits from happening. Security audits can be conducted by third-party audit firms such as Blockapex, which specializes in auditing smart contracts and DeFi protocols.
Also read Hack Analysis on DeFi Geek Community Japan.
SushiSwap is a decentralized exchange built on the Ethereum blockchain that utilizes an automated market maker (AMM) system to provide liquidity and facilitate token swaps. The organization aims to revolutionize the DeFi sector by incorporating a wide range of products, including decentralized lending markets, yield instruments, auction platforms, and staking derivatives. However, like many DeFi platforms, SushiSwap has experienced a significant security breach. In this analysis, we aim to shed light on this hacking incident, its impacts, the steps taken by the attacker, and recommendations for enhanced security.
On April 9, 2023, SushiSwap suffered a security breach which led to a loss of over $3.3 million. The attack exploited a flaw in the RouteProcessor2 contract of SushiSwap's router processor. The fallout was felt across several major chains that had previously authorized the RouteProcessor2 contract.
The attacker set off the exploit by executing the processRoute() function within the vulnerable RouteProcessor2 contract, inserting an atypical argument. This action led the router to interact with a new contract that had been purposely prepared by the attacker.
The attacker used the uniswapV3SwapCallback()method within the vulnerable contract’s internal swap() function. This method was used to send tokens from the source account to the attacker-controlled recipient's address. No checks or pool verifications were performed before passing the user-provided pool parameter to the swap, enabling the attacker to set their pool address as the LastCallPool variable address.
Having set their pool address, the attacker could then use the fraudulent pool’s uniswapV3SwapCallback function within its swap() function to bypass the msg.sender check. This allowed the attacker to steal the tokens of other users who had previously accepted the Routerprocessor2 contract.
As a mitigation strategy, it is highly recommended that user inputs are validated and modifiers are utilized on critical functionalities that may affect balances and user funds. Proper implementation of access control is also vital, with only the contract owner being allowed to perform critical transactions. Conditions should not be bypassable by any form of privilege escalations.
The malicious activities initiated by the attacker were linked to the following addresses:
Attacker's address: 0x719cdb61e217de6754ee8fc958f2866d61d565cf
Attacker's transaction: 0xea3480f1f1d1f0b32283f8f282ce
RouteProcessor2 Vulnerable Contract: 0x044b75f554b886a065b9567891e45c79542d7357
Attacker's Contract: 0x000000c0524f353223d94fb76efab586a2ff8664
The SushiSwap incident underscores the crucial need for rigorous security measures and audits within the DeFi landscape. Despite being a prominent platform, even SushiSwap wasn't immune to security breaches, reminding us that every project, regardless of size or reputation, carries potential risks if not adequately secured.
The pace of the DeFi world necessitates the utmost priority to smart contract security. Implementing rigorous security procedures, conducting thorough audits, and maintaining transparent communication with the community are all fundamental to safeguarding the platform and users' assets.
Organizations like BlockApex, with their expertise in smart contract auditing, can help platforms identify and mitigate potential vulnerabilities before they're exploited.
This incident is a timely reminder of the importance of security in the thriving yet risky landscape of DeFi. It's essential for platforms to maintain robust security protocols to foster trust and ensure their continued success.
Also, read our Hack Analysis on Merlin DEX!
