Dexible - February 20, 2023


Drop your email to read the BlockApex newsletter and keep yourself updated around the clock.

    Table Of Content



    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.

    Hack Impact

    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.

    Vulnerable Functions Overview

    The selfSwap function

    Dexible - Self swap function

    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

    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.

    Security Flaw in the Functions

    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.

    Attacker's Playbook: Exploiting the Vulnerability

    Step 1: Crafting the malicious contract

    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.

    Step 2: Preparing the selfSwap request

    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.

    Step 3: Calling the selfSwap function

    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.

    Step 4: Executing the fill function

    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.

    Step 5: Profiting from the vulnerability

    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.

    Recommendations for Enhanced Security

    Verify the router address on-chain

    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.

    Whitelist legitimate routers

    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.

    Enforce routerID validation in the fill function

    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.

    Regularly review and update approval allowances:

    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 Analysis: Tracing the Attacker's Steps

    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.

    Step 1: Identify the attacker's address

    The attacker's address can be found from the  transaction: 0x684083f312ac50f538cc4b634d85a2feafaab77a

    Dexible Tokens management history Image

    Step 2: Analyze the transaction details

    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.

    Step 3: Follow the flow of funds

    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.

    How they transferred stolen tokens to other cryptocurrencies

    Step 4: Observe related transactions

    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.

    Conclusion: Lessons Learned and the Importance of Security

    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.

    More Hack Analysis

    Euler Finance (March 14, 2023)

    The Euler Finance hack had a devastating impact on the platform and its users, with approximately $197 million worth of assets stolen, including ETH, WBTC, USDC, and DAI. This placed Euler Finance at number 6 on the leaderboard of the largest DeFi hacks. The platform's total value locked (TVL) dropped from $264 million to just $10 million.

    Merlin DEX - April 26, 2023

    In April 2023, Merlin DEX,a decentralized exchange (DEX) built on ZkSync, suffered a hack during a Liquidity Generation Event for its MAGE token, resulting in an estimated loss of $1.8 million from the protocol.

    LEVEL FINANCE - May 2, 2023

    The Level Finance hack significantly affected the platform and its users, as the attacker managed to steal $1.1 million in referral rewards. This breach undermined trust in Level Finance and raised concerns about the security of similar DeFi platforms.

    Platypus Finance - February 16, 2023

    On February 17, 2023, Platypus Finance 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.

    SushiSwap - April 9, 2023

    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.

    Orion Protocol - February 4, 2023

    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.

    Harvest Finance Hack Analysis & POC

    Harvest finance got hacked for around $34M due to a flashloan attack which manipulated the price in the Curve pool to retrieve more USDT tokens than originally deposited USDT amount in fUSDT pool.

    Yearn Finance - April 13, 2023

    The Yearn Finance hack that occurred on April 13, 2023, resulted in the loss of approximately $11.4 million. The exploit was carried out through a misconfiguration in the yUSDT vault, revealing a flaw in the system's architecture.

    Dforce Network - February 13, 2023

    The attack on dForce network had significant consequences for the platform and its users. By exploiting a reentrancy vulnerability in the wstETH/ETH pool on Curve and the dForce wstETH/ETH Vault, the attacker was able to manipulate the virtual price of the pool, which in turn affected the oracle used by the dForce wstETH/ETH Vault

    1 2 3
    Designed & Developed by: 
    All rights reserved. Copyright 2023