Home Web3 Security
Category:

Web3 Security

Time-Dependent Function Manipulation in Solidity Smart Contracts
Smart Contract AuditWeb3 Security

Time-Dependent Function Manipulation in Solidity Smart Contracts

by ImmuneBytes
written by ImmuneBytes

The Vulnerability

Smart contracts on Ethereum often have time-sensitive logic, whether it’s for auctions, lotteries, or token vesting. These time-sensitive functionalities commonly depend on the block.timestamp for execution. The problem arises from the fact that this block.timestamp is not absolutely immutable; it’s determined by the miner who mines the block, which means a miner has a small window (up to around 15 seconds according to the Ethereum protocol implementations) to manipulate this value to their advantage.

In a simple example, let’s say there is a decentralized auction contract that automatically accepts the highest bid made before a certain block.timestamp. If the miner is also a bidder, they could intentionally set the block’s timestamp to prematurely end the auction when they are the highest bidder, thereby winning the auction unfairly.

The Attack Scenario

The below contract enables a simple betting game where users guess whether a number will be odd or even. If their guess is correct, they win twice the amount they bet, minus a 10% fee. The contract utilizes the block.timestamp for generating the number, which introduces the vulnerability.

// Solidity program to demonstrate 
// timestamp dependence vulnerability
pragma solidity ^0.8.0;

contract OddEvenGame {
    uint public yourAnswer;

    function oddOrEven(bool yourGuess) external payable returns (bool) {
        yourAnswer = block.timestamp % 2;

        if (yourGuess == (yourAnswer > 0)) {
            uint fee = msg.value / 10;
            payable(msg.sender).transfer(msg.value * 2 - fee);
            return true;
        } else {
            return false;
        }
    }
}
  1. Exploiting Miner
    Bob, a miner, observes transactions sent to this contract. He understands that block.timestamp is used to decide the outcome of the bet.
  2. Timestamp Manipulation
    Before mining a block, Bob can manipulate the block’s timestamp to ensure it results in either an odd or even number when taken modulo 2.
  3. Execute Transaction
    Bob then creates a transaction by calling the oddOrEven() function with his ‘guess,’ which he knows will be correct because he manipulated the timestamp.
  4. Profit
    Bob mines the block with the manipulated timestamp and his transaction. If he successfully mines this block, the manipulated timestamp will ensure he wins the bet and takes the Ether.

Preventative Measures

  1. Avoid Direct Time-Dependence: For random number generation or other logic not strictly tied to time, try to use methods other than block.timestamp.
  2. Oracle Services: Use trusted Oracle services like ChainLink to bring reliable timestamp data into the smart contract. Chainlink’s Decentralized Oracle Networks can provide tamper-proof data for smart contracts.
  3. Time Padding: If you must use block.timestamp, consider implementing a time buffer after the supposed end time of the contract action. For example, you could add a rule that the auction will only end when block.timestamp is greater than auctionEndTime + 1 minutes, giving participants a grace period and reducing the miner’s ability to manipulate the end time.
  4. Multi-block Confirmation: Ensure that an action only be finalized after the same condition has been met in several consecutive blocks, decreasing the likelihood that any single miner can manipulate the outcome.

Real-World Examples

A notable real-world instance similar to this kind of attack would be the GovernMental Ponzi scheme that amassed nearly 1100 ETH. Miners manipulated the timestamp to appear as the last player to join the game and thus claimed the reward unfairly.

By acknowledging the flexibility and potential manipulability of the block.timestamp, developers can build more robust and attack-resistant smart contracts.

0 comments
0 FacebookTwitterPinterestEmail
Time Jacking in Mining Pools
BlockchainWeb3 Security

Time Jacking in Mining Pools

by ImmuneBytes
written by ImmuneBytes

Overview

Time jacking exploits a theoretical vulnerability in Bitcoin timestamp handling. During a time-jacking attack, a hacker alters the network time counter of a node on the blockchain network and forces the node to accept an alternative network.

This can be achieved when a malicious user adds multiple fake peers to the network with inaccurate timestamps. However, a time jacking attack can be prevented by restricting acceptance time ranges or using the node’s system time.

How does a Time-jacking Attack work?

In a time-jacking attack, the hacker manipulates one of the timers of the victim node and creates a “poisoned” block. The victim will reject this block, and the rest of the network will successfully accept and provoke a fork. The entire network then uses a blockchain built for the “poisoned,” and the victim considers the alternative chain with a token reuse (or double-spending) valid, in which the “poisoned” block does not appear.

The attack is carried out in two stages; Fork and isolate and Double-spend.

1. Fork & Isolate

The attacker needs to generate a new block, the same “poisoned” block that the victim ignores. In the same way, the victim will reject other blocks that will be added sequentially after the “poisoned” one.

An attacker can manipulate the time value of the victim’s network by connecting to it a sufficient number of neighbors announcing a lagging system time. The time value of the victim’s network decreases; the upper limit of the range of valid values of the timestamp of the verified block decreases.

But if the deviation of the neighbor’s time exceeds 70 minutes, then its time will not be taken into account when calculating the network time. Therefore, the maximum value by which the time of the victim’s network can be reduced is 70 minutes.

Accordingly, the “poisoned” block is a block whose timestamp must fall into the time window of all network nodes except the victim. Only then the whole network will successfully accept it, and the victim whose network time has been modified will be no less successful.

This results in the victim being isolated from the main network and considers the main blockchain, which will be built by the remaining nodes from the “poisoned” block, incorrect. In this case, the other blocks, helpfully generated by the attacker for an alternative chain, the victim will confidently accept.

2. Double-spending

At this stage, the attacker starts generating an alternative chain, in which he adds a transaction that transfers tokens to the victim’s wallet. Blocks of an alternative chain are sent to the victim.

The victim accepts this chain since the value of the timestamps is chosen by the intruder from his or her own time window, and the remaining nodes will be rightfully ignored — after all, they are already building their chain from a “poisoned” block that is longer than the alternative one.

As a result, the victim believes that he received tokens and sends the goods. The main network is sure that the tokens did not leave the intruder’s wallet, and he gets the goods for “thank you” — because the majority cannot be mistaken. After performing all of these tasks, the attacker is deemed successful in his or her illicit act.

Remediation

There are ways to mitigate or prevent time-jacking attacks from happening. Here are some preventive measures to keep in mind.

  • Use the node’s system time: Using the node’s system time, rather than network time, for block timestamps is advisable. Relying on hardware time sources would need extra calibration and maintenance. Even a slight discrepancy among nodes (as they adjust their clocks) could enable an attacker to disrupt the network or isolate a node.
  • Strengthen acceptable time ranges: The node’s network time could be restricted to a value within 30 minutes. This changes the maximum initial attack window to between 30 and 60 minutes instead of 70 and 140, but would not prevent splits entirely. Nodes with incorrect daylight savings handling might be left behind, though.
  • More confirmations: It’s advisable to demand more confirmations for transactions, striking a balance between speed and security against potential reversals. However, even with increased confirmations, a substantial financial attack could succeed if other miners manipulate timestamps or if the target system is offline.
  • Only trusted peers: Requiring secure nodes to rely solely on trusted peers can weaken security, as a few trusted peers might be compromised. A fully decentralized system doesn’t rely on a select group of peers. Mandating operators to manage their own networks or distribute servers geographically adds maintenance and synchronization challenges. Trusting peers or a distributed network alone doesn’t solve the global time agreement issue.
  • Median Blockchain Time Validation: Validate blocks and transactions exclusively using the median blockchain time, eliminating the possibility of timestamp splits. This ensures consensus as all peers rely on the chain’s embedded timestamps, removing disagreements based on variable clocks.
  • Delayed Timestamp Validation: Delayed validation involves retaining blocks with excessive timestamps for later re-checking, reducing timestamp inflation risk. Nodes rejoin the main chain once their system clocks catch up, minimizing synchronization delay compared to solely relying on system time. However, it’s more complex and may still allow timestamp-based splits.

Conclusion

While this attack only affects the Bitcoin chain, we should not disregard the fact that attackers continue to develop methods to intrude on other chains and perform their illicit intentions or acts. A time-jacking attack is more rigorous and time-consuming to perform, so once someone tries to pull off an attack, security can easily identify it, considering the drastic improvements of blockchain over the years.

0 comments
0 FacebookTwitterPinterestEmail
Arithmetic Issues in Solidity Smart Contracts
Smart Contract AuditWeb3 Security

Arithmetic Issues in Solidity Smart Contracts

by ImmuneBytes
written by ImmuneBytes

Introduction

Arithmetic issues, specifically integer overflow and underflow, are common vulnerabilities in Solidity smart contracts.

These issues occur when unsigned integers exceed their maximum value or go below their minimum value, wrapping around and causing unexpected behavior. This article will explore the attack vectors related to arithmetic issues in Solidity.

Vulnerability Points

1. Unchecked Withdrawal Function

Code Example:
solidityCopy code
function withdraw(uint _amount) {
    require(balances[msg.sender] - _amount > 0);
    msg.sender.transfer(_amount);
    balances[msg.sender] -= _amount;
}
Attack Vector:

The function does not properly check for integer underflow. An attacker can attempt to withdraw more than their balance, causing the balance to underflow and become a large positive number, effectively stealing funds from the contract.

2. Off-by-One Error in Array Manipulation

Code Example:
solidityCopy code
function popArrayOfThings() {
    require(arrayOfThings.length >= 0);
    arrayOfThings.length--;
}
Attack Vector:

The function does not account for the possibility of underflow when decrementing the array length. An attacker could exploit this to corrupt the state of the contract.

3. Unsigned Integer Arithmetic in Voting

Code Example:
solidityCopy code
function votes(uint postId, uint upvote, uint downvotes) {
    if (upvote - downvote < 0) {
        deletePost(postId);
    }
}
Attack Vector:

The function does not check for underflow in the subtraction operation. An attacker could manipulate the vote counts to trigger unintended post deletions.

4. Loop with Inadequate Data Type

Code Example:
solidityCopy code
for (var i = 0; i < somethingLarge; i++) {
    // ...
}
Attack Vector:

The loop uses the var keyword, which may resolve to a smaller data type like uint8. If somethingLarge exceeds 255, the loop will never complete, causing a denial of service.

Real-World Impact

  • The DAO
  • BatchOverflow and ProxyOverflow attacks affected multiple tokens.

Attack Scenarios

  1. Balance Draining: An attacker exploits the unchecked withdrawal function to drain the contract’s funds.
  2. State Corruption: An attacker exploits the off-by-one error to corrupt the contract’s state, potentially leading to further vulnerabilities.
  3. Data Manipulation: An attacker exploits the unsigned integer arithmetic in voting to delete posts maliciously.
  4. Denial of Service: An attacker exploits the loop with an inadequate data type to exhaust the contract’s gas, making it non-functional.

Mitigation Strategies

  1. Use OpenZeppelin’s SafeMath library for arithmetic operations.
  2. Always check for overflows and underflows using control statements.
  3. Update to Solidity version 0.8.0 or higher, which automatically reverts on integer overflow and underflow.

Conclusion

Arithmetic issues like integer overflow and underflow are critical vulnerabilities in Solidity smart contracts. They can lead to a variety of attacks, including fund theft, state corruption, and denial of service.

Developers should be vigilant in checking for these issues and use available tools and libraries to mitigate the risks.

0 comments
0 FacebookTwitterPinterestEmail
Self-Destruct Exploit: Forced Ether Injection in Solidity Contracts
Smart Contract AuditWeb3 Security

Self-Destruct Exploit: Forced Ether Injection in Solidity Contracts

by ImmuneBytes
written by ImmuneBytes

Introduction

The selfdestruct function in Solidity provides a mechanism for contract termination and balance transfer, but it comes with inherent security risks. One of the prominent vulnerabilities it can introduce is forced ether injection into a target contract, altering its state and potentially breaking its logic. This attack vector examines how a smart contract can be vulnerable to such an attack and how to mitigate it.

Understanding Self-Destruct in Solidity

In Solidity, the selfdestruct(address payable recipient) function transfers all Ether from the contract to a specified recipient address and removes the contract’s bytecode, rendering it inoperative. If the recipient address is a contract, it receives the Ether without any of its functions being called, not even the fallback function.

Attack Scenario: Breaking EtherGame

Let’s look at an example contract called EtherGame, which is based on Solidity by example.

solidityCopy code
pragma solidity ^0.8.20;

contract EtherGame {
    uint public targetAmount = 7 ether;
    address public winner;

    function deposit() public payable {
        require(msg.value == 1 ether, "You can only send 1 Ether");

        uint balance = address(this).balance;
        require(balance <= targetAmount, "Game is over");

        if (balance == targetAmount) {
            winner = msg.sender;
        }
    }

    function claimReward() public {
        require(msg.sender == winner, "Not winner");

        (bool sent, ) = msg.sender.call{value: address(this).balance}("");
        require(sent, "Failed to send Ether");
    }
}

In this simple game, players send 1 Ether to the contract, aiming to be the one who makes the total balance reach 7 Ether. The first player to do so becomes the winner and can claim the reward.

Vulnerability Details

An attacker can create another contract with a selfdestruct function and send enough Ether to break the game logic. For example, sending 5 Ether to the contract will make its balance reach or exceed the target amount, thereby making it impossible for any player to win the game.

Mitigation Strategies

The attack can be prevented by not relying on address(this).balance for critical game logic. Instead, use a self-maintained state variable to track the deposited Ether.

Here’s a safer version of the EtherGame contract:

solidityCopy code
pragma solidity ^0.8.20;

contract EtherGame {
    uint public targetAmount = 7 ether;
    uint public balance;
    address public winner;

    function deposit() public payable {
        require(msg.value == 1 ether, "You can only send 1 Ether");

        balance += msg.value;
        require(balance <= targetAmount, "Game is over");

        if (balance == targetAmount) {
            winner = msg.sender;
        }
    }

    function claimReward() public {
        require(msg.sender == winner, "Not winner");

        (bool sent, ) = msg.sender.call{value: balance}("");
        require(sent, "Failed to send Ether");
    }
}

In this revised version, we keep track of the deposited Ether with our own balance state variable. This makes the contract resilient against forced Ether injections via selfdestruct.

Conclusion

While the selfdestruct function has legitimate uses; it can be a significant security risk if misused or misunderstood. It is crucial to be aware of its implications and to follow best practices in smart contract development to mitigate associated risks.

0 comments
0 FacebookTwitterPinterestEmail
Bad Randomness in Solidity Smart Contracts
Smart Contract AuditWeb3 Security

Bad Randomness in Solidity Smart Contracts

by ImmuneBytes
written by ImmuneBytes

Introduction

Bad randomness, often referred to as the “nothing is secret” attack, is a vulnerability in Solidity smart contracts deployed on the Ethereum blockchain. This attack vector exploits the pseudo-random nature of certain variables and functions in Solidity, allowing an attacker to predict or influence the outcome of smart contract operations that rely on randomness.

Vulnerability Points

1. Using Block Hash for Randomness

Code Example:

solidityCopy code
function randomNumber() public view returns (uint) {
    return uint(keccak256(abi.encodePacked(block.difficulty))) % 10;
}

Attack Vector:

An attacker can monitor the block difficulty and potentially influence it by colluding with miners. By doing so, the attacker can predict the output of the randomNumber() function.

2. Using Block Timestamp for Randomness

Code Example:

solidityCopy code
function randomNumber() public view returns (uint) {
    return uint(keccak256(abi.encodePacked(block.timestamp))) % 10;
}

Attack Vector:

An attacker who controls a miner can manipulate the block timestamp, thereby influencing the output of the randomNumber() function.

3. Using Block Number for Randomness

Code Example:

solidityCopy code
function play() public payable {
    require(msg.value >= 1 ether);
    if (block.blockhash(blockNumber) % 2 == 0) {
        msg.sender.transfer(this.balance);
    }
}

Attack Vector:

An attacker can create a malicious contract that checks if the current block number is a winner. If so, it calls the vulnerable smart contract, ensuring a win since the block number remains constant within the same transaction.

Real-World Impact

  • Loss of more than 400 ETH in SmartBillions Lottery.
  • TheRun

Mitigation

  1. Use hardware random number generators (RNGs) for generating truly random numbers.
  2. Utilize decentralized randomness beacons like Chainlink’s VRF.

Conclusion

Bad randomness is an attack vector in Solidity smart contracts. Developers must be cautious when implementing randomness and should opt for secure and unpredictable sources to mitigate this risk.

0 comments
0 FacebookTwitterPinterestEmail
Exactly Protocol - Detailed Hack Analysis
Crypto Hacks & ExploitsWeb3 Security

Defi ‘Exactly Protocol’ Hack Analysis

by ImmuneBytes
written by ImmuneBytes

Introduction

On Aug 18, DeFi @ExactlyProtocol, operating on Optimism, encountered a breach resulting in a loss of around $7.3M. A loophole in the DebtManager contract allowed hackers to tweak the market address and evade integral permit checks, leading to the theft of users’ $USDC.

Summary of the Exploit

Attackers made use of an insufficient_check vulnerability in Exactly Protocol’s DebtManager contract. By injecting a fraudulent market address, they successfully skirted the protocol’s permit checks. This opened a door to activate a malicious deposit function, leading to the theft of users’ $USDC. Subsequently, they liquidated users’ assets for illicit gains.

Technical Breakdown

Vulnerability

The primary issue was in the DebtManager contract of the Exactly Protocol. It lacked rigorous validation for the market address input.

Attack Methodology

The attacker:

  • Manipulated the vulnerability in the `DebtManager` contract
  • Inserted a counterfeit market contract address, evading the `permit` checks
  • Leveraged this unauthorized access to initiate a harmful deposit function, culminating in the theft of users’ $USDC
  • Cashed out user assets to make illicit profits

Reentrancy

Demonstrating profound expertise, the attacker not only bypassed the permit check in the DebtManager contract but also tampered with the _msgSender to impersonate a victim. Using an untrusted external call, they accessed the crossDeleverage function again, stripping collaterals from the _msgSender.

Immediate Response and Investigation

Upon noticing the breach, Exactly Protocol acted swiftly. They acknowledged the incident and started an investigation. Operations were momentarily halted, but provisions were made to facilitate user asset withdrawals.

The protocol is now fully operational, and notably, no liquidations took place. Efforts are ongoing to recover the stolen funds, including establishing communication with the culprits.

Contextualizing the Attack

Market Dynamics

This breach occurred during a wider cryptocurrency market downturn. Established coins, namely XRP, Litecoin (LTC), and Bitcoin Cash (BCH), experienced significant drops. Bitcoin briefly dipped to $25,200 before rallying.

DeFi Sector Vulnerabilities

The Exactly Protocol incident isn’t an isolated case in the DeFi world. Security lapses, especially surrounding technologies like cross-chain bridges, have emerged. Hundred Finance on the Optimism network also faced a hack earlier, resulting in a loss of $7 million in crypto assets.

Attack and Follow-Up Movements

For those interested in a deeper dive, the blockchain transactions tied to the exploit are:

  1. https://optimistic.etherscan.io/tx/0x3d6367de5c191204b44b8a5cf975f257472087a9aadc59b5d744ffdef33a520e
  2. https://optimistic.etherscan.io/tx/0x1526acfb7062090bd5fed1b3821d1691c87f6c4fb294f56b5b921f0edf0cfad6
  3. https://optimistic.etherscan.io/tx/0xe8999fb57684856d637504f1f0082b69a3f7b34dd4e7597bea376c9466813585

Furthermore, the attacker initially secured funds from TornadoCash and bridged them to address 0xe4f3 on Optimism via the Optimism Bridge. The exploit contract was then launched by 0xe4f3, with addresses 0x3747 and 0x4171 executing the attack. Profits were converted to roughly 4324 Ether.

As of now, 1500 Ether has transitioned back to Ethereum via the Across Bridge. Meanwhile, 2833 Ether is en route back to Ethereum through the Optimism Bridge, though the transaction is in the Challenge Period. Surveillance continues on the attacker’s address.

Addresses Associated with the Exploit

  1. https://optimistic.etherscan.io/address/0x3747dbbcb5c07786a4c59883e473a2e38f571af9
  2. https://optimistic.etherscan.io/address/0xe4f34a72d7c18b6f666d6ca53fbc3790bc9da042
  3. https://optimistic.etherscan.io/address/0x417179df13ba3ed138b0a58eaa0c3813430a20e0

Conclusion

The DeFi arena, bursting with potential, also carries inherent risks. Rigorous contract audits, multi-layered security measures, and user education are paramount. As the DeFi world evolves, security must concurrently advance to safeguard a resilient ecosystem. Stakeholders are urged to remain cautious and informed.

An ineffective smart contract audit by unskilled auditors often result into costly exploits. At ImmuneBytes, we believe in treating every vulnerability (minor or critical) with utmost attention and our team of exceptionally adept and experienced auditors ensures that no shortcomings can escape their piercing eyes.

0 comments
0 FacebookTwitterPinterestEmail
Zunami Protocol Hack—Aug 13, 2023—Detailed Analysis Report
Crypto Hacks & ExploitsWeb3 Security

Zunami Protocol Hack—Aug 13, 2023—Detailed Analysis Report

by ImmuneBytes
written by ImmuneBytes

Overview

On August 13, 2023, Zunami Protocol, a prominent DeFi platform on the Ethereum blockchain, fell victim to a sophisticated flash loan attack.

This exploit led to a substantial financial loss of 1,178 ETH, equivalent to approximately $2.16 million. The attacker, operating from an externally owned address (0x5f4C2), ingeniously manipulated the StakeDAO (SDT) price on Sushiswap.

This manipulation inflated the balance of Zunami’s stable token, UZD, allowing the attacker to transfer the stolen funds through Tornado Cash illicitly.

The attack unfolded in two major transactions, with the more significant one resulting in the extraction of 1,152 ETH, revealing vulnerabilities in Zunami Protocol’s security mechanisms.

About Zunami Protocol

Zunami Protocol, launched in the bustling sphere of decentralized finance (DeFi), is a platform on the Ethereum blockchain specializing in stablecoin management and yield optimization.

Its primary objective is to streamline and maximize returns for stablecoin investors. The protocol has carved a niche in the DeFi space, attracting attention with its innovative approach to yield farming and liquidity provision.

Despite its relatively recent inception, Zunami Protocol has marked significant milestones in terms of total value locked (TVL) and user adoption, positioning itself as a noteworthy player in the DeFi landscape.

However, the recent security breach underscores the perpetual challenges DeFi platforms face in safeguarding assets against increasingly sophisticated cyber threats.

Root Cause of the Exploit

The Zunami Protocol hack was fundamentally a consequence of price manipulation, exploiting the way UZD (Zunami’s stable token) balance was calculated. The core of this vulnerability lay in the assetPriceCached() function used in the formula:

Balance[address] * assetPriceCached()/DEFAULT_DECIMALS_FACTOR

Here, Balance[address] represents the UZD balance of the user, and DEFAULT_DECIMALS_FACTOR is a constant. The crucial aspect is the assetPriceCached() function, which returns the value of _assetPriceCached. This value was manipulated by the attacker using the cacheAssetPrice() function.

The contract responsible for the total holdings calculation across all Zunami pools is 0x2ffcc661011bec72e1a9524e12060983e74d14ce. The vulnerable pool in this exploit was identified as 0x984.

The formula for calculating total holdings in this strategy is:

_lpBalance * lpPrice + sdt * sdtPrice + config.crv * crvPrice

sdt is calculated by _config.sdt.balanceOf(address(this)), representing the balance of SDT in the strategy contract. The attacker increased this balance by transferring SDT into the strategy in one of the exploit steps.

priceTokenByExchange() function depends on the prices of Sushiswap pairs Stake DAO-WETH (0x22def8cf4e481417cb014d9dc64975ba12e3a184) and WETH-USDT (0x06da0fd433c1a5d7a4faa01111c044910a184553).

The attacker manipulated these prices in the exploit.

Vulnerable Contract: 0x2ffcc661011bec72e1a9524e12060983e74d14ce

Attack Contract: 0xa21a2b59d80dc42d332f778cbb9ea127100e5d75

Hacker Add: https://bit.ly/3OqXilq

Detailed Analysis of the Zunami Protocol Hack

The attack was executed in two major transactions, resulting in the loss of approximately 1,178 ETH:

The attack was carried out in two transactions:

  • (26 ETH)Txn 1:https://bit.ly/455zElH
  • (1152 ETH)Txn 2: https://bit.ly/3sfqkNf

For 2nd Transaction (Take the second attack, which yielded the most profit (i.e., ~1152 ETH), as an example):

Initial Transaction: The attacker withdrew 10 ETH from Tornado Cash for creating the attack contract.

Flash Loan Execution: Utilizing flash loans of 7,000,000 USDT from UniSwapV3, 7,000,000 USDC, and 10,011 WETH (~$18.4 million) from Balancer, the attacker initiated the exploit.

Token Swaps and Price Manipulation:

  • Swapped 5,750,000 USDC for 5,746,896 crvFRAX on Curve, later exchanged for 4,082,036 UZD in pool 1.
  • Swapped 1,250,000 USDC for 1,250,333 crvUSD on Curve, later exchanged for 791,280 UZD in pool 2.
  • Swapped 11 WETH for 55,981 SDT in pool 3, transferring the SDT to the strategy.
  • Swapped 10,000 WETH for 58,042 SDT in SushiSwap: SDT, and 7,000,000 USDT to 2,154 WETH in SushiSwap: USDT, significantly increasing the price of SDT-USDT.

Inflating UZD Balance: The attacker then called cacheAssetPrice() in the UZD contract (0xb40b), inflating their UZD balance from 4.8 million UZD to 16.9 million UZD.

Funds Conversion and Movement: The perpetrator skillfully manipulated their artificially inflated UZD balance, converting it into different crypto assets:

  • In the first pool, they exchanged 14,158,424 UZD for 7,281,124 crvFRAX.
  • In the second pool, 2,744,533 UZD was traded for 1,891,351 crvUSD.
  • Following these transactions and the repayment of the borrowed amounts, the attacker successfully secured 1,152 WETH, equivalent to roughly $2.12 million.

Stolen Fund Details

Fund Movement

The stolen 1,178 ETH were moved through various transactions and eventually sent to Tornado Cash.

Hack Aftermath

Response by Zunami Protocol

Initial Acknowledgment: The team announced the occurrence of the exploit on their Twitter account, assuring users that the Omnipool collateral remained secure.

Collateral Distribution Plan: Zunami Protocol stated that UZD and zETH collateral would be distributed to holders from just before the hack, with equal compensation to all participants, regardless of their interaction with specific liquidity pools or addresses. This was communicated via Twitter.

Additional Measures: An extra comprehensive audit was planned for Zunami V2, along with updates and fixes to omnipools and zStables.

Compensation and Refund Details:

Process and Timeline: Users were informed about the upcoming collateral distribution in USDT/USDC/DAI, which they would need to claim themselves. The team posted updates on the expected start of fund distribution, as mentioned in their Twitter update.

Resources for Affected Users

Balance Calculation Script: https://github.com/ZunamiProtocol/ZunamiProtocol/commit/d00df349abc439b8e0d668d1d6879138b53334a8

UZD Balances: Detailed information was provided here:
https://docs.google.com/spreadsheets/d/121VgUuIOakQwhIdL3d7Af2SrvQHYInYqrNeer4TpsZ0/edit?usp=sharing

zETH Balances: Information was made available here:
https://docs.google.com/spreadsheets/d/15VneBK-Xg8TpSfbT2YkWr6thIqClKJqz32yCKSoEf1w/edit?usp=sharing

Claiming Process:
The official link for claiming the refund for UZD and zETH for the block before the hack was provided at claim.zunami.io. Official claiming addresses were also shared:

UZD: 0xa655Aa809D1FE7a55e22425780bb676E8AE0A143

zETH: 0x6756EfFa8aABeB9031279e4C71d8c1BD3Ae8f9Ef

Future Developments

Zunami V2 Launch: The team announced the upcoming launch of Zunami V2, which includes necessary fixes and an audit to prevent similar exploits in the future.

Based on the comprehensive analysis of the Zunami Protocol hack, the following lessons and mitigation steps can be drawn to prevent similar incidents in the future:

Lessons Learnt

Vulnerability in Pricing Mechanisms: The exploit highlighted the vulnerability in DeFi protocols related to the calculation of asset prices and balances. Protocols should rigorously test and secure their pricing mechanisms, especially when they are tied to complex functionalities like flash loans.

Flash Loan Attack Awareness: DeFi projects need to be highly cautious of flash loan attacks, as they allow attackers to amass significant temporary capital to manipulate markets or exploit vulnerabilities.

Importance of Comprehensive Audits: Engaging with security firms for periodic audits and staying updated with the latest security practices and patches. This also includes post-deployment monitoring and rapid response mechanisms. These audits should be conducted by reputable firms like ImmuneBytes with a strong track record in identifying similar vulnerabilities.

Robust Monitoring Systems: Continuous monitoring of the protocol’s activities for unusual patterns or spikes in transaction volume and prices can help in early detection of potential exploits.

Conclusion

The Zunami Protocol hack serves as a grave reminder of the vulnerabilities present in blockchain systems, particularly within the DeFi sector.

This incident, involving the exploitation of pricing mechanisms and the theft of over 2 million dollars, underscores the critical need for heightened security measures and the importance of regular, comprehensive audits in the blockchain domain.

It highlights the emerging challenges and the evolving nature of threats that such platforms face. Furthermore, the role of professional auditors like ImmuneBytes becomes increasingly vital.

Their expertise in proactive security assessments can play a pivotal role in identifying and mitigating potential vulnerabilities before they can be exploited, thereby bolstering blockchain projects’ overall security and integrity.

This hack not only sheds light on specific security flaws but also offers valuable lessons for the future of blockchain security, driving the industry toward more robust and resilient systems.

0 comments
0 FacebookTwitterPinterestEmail
AVAXUSDC Joe LP NXUSD Market-hack-analysis
Crypto Hacks & ExploitsWeb3 Security

AVAX/USDC Joe LP NXUSD Market—Flash Loan Exploit—Sep 6, 2022—Detailed Analysis

by ImmuneBytes
written by ImmuneBytes

Overview

On September 7, 2022, the Nereus protocol’s AVAX/USDC Joe LP NXUSD market was reported to be exploited, leading to the creation of $500k NXUSD bad debt. The incident was initially reported by the Nereus team through community channels and later highlighted by on-chain analytics groups. The exploit utilized a flash loan and culminated in a $371k profit for the attacker.

The Discovery of Exploit

At roughly 10:30PM UTC on September 6, 2022, the Nereus team became aware of the issue and quickly communicated it to their community through their discord platform.

Subsequent monitoring and assessment by some 3rd party auditors and on-chain analysis groups, identified the event as a flash-loan exploit, which led to a financial advantage of approximately $371k for the exploiter.

Immediately following the discovery, Nereus liaised with security professionals to devise a containment strategy. Law enforcement was notified to assist in the investigation.

In terms of mitigation, the compromised JLP market was both liquidated and paused by the Nereus team. The bad debt was covered by using NXUSD from the team’s treasury, ensuring no user funds were jeopardized. The NXUSD remained over-collateralized throughout this crisis.

It was clarified by the Nereus team that the lending and borrowing components of the protocol were never vulnerable during this incident.

The Flash Loan Attack

The exploit was orchestrated by an individual or group who devised a tailored smart contract. This contract utilized a massive $51M flash loan to momentarily manipulate the AVAX/USDC Trader Joe LP pool’s price. As a result, the attacker managed to mint 998,000 NXUSD, which was disproportionate to their collateral valued at approximately $508k.

The vulnerability stemmed from the recent introduction of a collateral type that supported AVAX/USDC Trader Joe LP tokens. A critical oversight occurred in the price determination process, making it prone to exploitation. Price calculations depended on real-time values without implementing any time-weighted average price (TWAP) mechanism. This absence of TWAP exposed the protocol to single-block price manipulation.

The Attack Details

The exploit was centered on the Nereus protocol’s recent support for AVAX/USDC Trader Joe LP tokens as collateral. A critical oversight in the price calculation mechanism for this collateral type was identified as the vulnerability.

Specifically, the protocol’s price calculation depended on real-time on-chain values: wAvaxReserve, usdcReserve, and totalSupply from the Trader Joe Pool.

Due to the absence of a Time Weighted Average Price (TWAP) mechanism, these values were open to manipulation within a single block.

The formula used for LP price calculation was:
[ \text{LP price} = \frac{(wavaxReserve \times avaxPrice) + (usdcReserve \times usdcPrice)}{totalSupply} ]

The vulnerability was evident in the pool price chart, with a noticeable spike at Block Height: 19613453.

The exploit transaction can be referenced at: Snowtrace Transaction: https://snowtrace.io/tx/0x0ab12913f9232b27b0664cd2d50e482ad6aa896aeb811b53081712f42d54c026

Sequence of the Exploit

  1. Initiate a flash loan of 51,000,000 USDC from AAVE v3.
  2. Swap 280,000 USDC for 14,735 WAVAX in the wAVAX/USDC Joe pool.
  3. Inject liquidity using 260,000 USDC and 13,401 WAVAX into the Joe pool, resulting in the acquisition of 0.04533097793130507 JLP tokens.
  4. Swap the remaining 50,460,000 USDC for 505,213 WAVAX, artificially inflating the pool price to about $98 per WAVAX.
  5. Utilize the borrow function in the NXUSD market, depositing 0.04533097793130507 JLP, and borrowing 998,000 NXUSD. Here, the manipulated collateral value was ~$1,330M USD, whereas its true market value was around $500K USD.
  6. Swap 506,547 WAVAX (505,213 + (14,735–13,401)) back to 50,426,896 USDC.
  7. Convert 998,000 NXUSD into 955,678 avCRV using the NXUSD Factory 3crv pool.
  8. Swap 955,678 avCRV for 977,269 USDC.e in the 3crv pool.
  9. Convert 977,269 USDC.e into 970,010 USDC.
  10. Repay the flash loan with 51,025,500 USDC to AAVE v3.

Net Outcome for the Exploiter: A profit of 371,406 USDC.

Immediate Response and Mitigation

Upon detection, the Nereus team promptly:

  • Notified the community and relevant stakeholders.
  • Consulted with security experts.
  • Developed a mitigation plan, which included liquidating and pausing the affected JLP market.
  • Paid off the bad debt from the Team’s treasury, ensuring no user funds were at risk.
  • NXUSD remains over-collateralized and its lending/borrowing functions were never at risk and continue to function as intended.

Future Steps and Security Enhancements

  1. Implementation of TWAP calculations for more secure price feeds, especially for assets without Chainlink oracles.
  2. Continuous review and update of audit and security practices to prevent future vulnerabilities.
  3. A 20% White Hat reward was offered for the return of the exploited funds, alongside active efforts to trace and recover the stolen amount.
  4. While the incident was regrettable, it served as a valuable lesson for the Nereus team, who reiterated their commitment to user safety, protocol security, and risk mitigation.

0 comments
0 FacebookTwitterPinterestEmail
DAO-Maker-Hack-Analysis
Crypto Hacks & ExploitsWeb3 Security

DAO Maker Exploit—Sep 4, 2021- Detailed Analysis

by ImmuneBytes
written by ImmuneBytes

On September 4, 2021, DAO Maker’s vesting contract was exploited, resulting in a significant loss of funds. This report provides a detailed account of the hack using multiple sources of information.

Technical Details of the Attack

Vulnerability in DAO Maker

DAO Maker’s init() function was exposed, allowing the attacker to reset 4 token contracts with malicious data. Following this, the emergencyExit() function was utilized to extract the funds from each contract.

Four impacted contracts and their respective transactions were:

  • 0x6e70c88be1d5c2a4c0c8205764d01abe6a3d2e22: 13.5M CAPS withdrawn
  • 0xd6c8dd834abeeefa7a663c1265ce840ca457b1ec: 5M CPD (2.5M CPD withdrawn twice)
  • 0xdd571023d95ff6ce5716bf112ccb752e86212167: 1.44M DERC
  • 0xa43b89d5e7951d410585360f6808133e8b919289: Approximately 20.6M SHO

Post exploit, the attacker initialized two more contracts.

Another address also displayed a pattern of init()-emergencyExit() calls, hinting at potential whitehat activity or developers attempting to salvage assets.

The attacker eventually traded the tokens for DAI through MetaMask and 1inch

Tokens Involved and their Vesting Contracts

  • Four tokens that were affected are: DeRace Token (DERC), Coinspaid (CPD), Capsule Coin (CAPS), and Showcase Token (SHO).
  • They all utilize DAO Maker’s vesting system. The vulnerability lay in that the DAO Maker vesting contract could be attacked when DERC tokens were issued.
  • A deeper analysis showed that the init function did not authenticate the caller, enabling the hacker to become the owner of the vesting contract.

Detailed Analysis of Contracts and Transactions:

The contracts related to DERC:

  • Vesting agency contract: 0x2fd602ed1f8cb6deaba9bedd560ffe772eb85940, 0xdd571023d95ff6ce5716bf112ccb752e86212167
  • Vesting implementation contract: 0xf17ca0e0f24a5fa27944275fa0cedec24fbf8ee2
  • The attacker’s address was identified as 0x2708cace7b42302af26f1ab896111d87faeff92f

Aftermath of the Exploit

Monetary Impact

The attacker swapped the stolen tokens for DAI:

  • Ternoa: 13.5M CAPS for 378,189 DAI on 1inch
  • Coinspaid: 5M CPD for 158,216 DAI on 1inch
  • DeRace: 1.44M DERC for 997,833 DAI on 1inch
  • Showcase: 20.6M SHO for 67,663 DAI via MetaMask Swap Router

As of the report time, token prices had been affected:

  • Ternoa CAPS: -45% initially, recovered to -11%
  • CoinsPaid CPD: Slumped to -60%, then -25%
  • DeRace DERC: Plummeted to -75%, later around -25%
  • Showcase SHO: Approximately -75%

Public Response and Opinions

  • DAO Maker claimed audits from three firms. However, only one of the audits linked to DAO Maker, and that link from one of them was broken. This raised concerns about transparency and the efficacy of these audits.
  • A sentiment emerged, suggesting that while audits are essential, the responsibility for security should lie with the team, not solely with external auditors.

Further Findings

Movement of Stolen Funds

  • On September 8 2021, it was confirmed that 500,000 DAI related to the DAO Maker exploit was moved through the Tornado Cash mixing platform, a tool designed to preserve transaction privacy

Connection to Another Exploit

The attacker’s address `0x00a62eb08868ec6feb23465f61aa963b89e57e57` was also implicated in a previous attack on July 14th, targeting the SpaceGodzilla project on the BSC Chain

In SpaceGodzilla exploit, flash loans were leveraged to borrow significant amounts, facilitating price manipulation of platform coins within the PancakeSwap trading pool.

The attacker exploited specific vulnerabilities present in the SpaceGodzilla project, resulting in an arbitrage profit of 25,378.78BUSD.

Conclusions

  • The DAO Maker hack unveiled vulnerabilities in its contracts and raised questions about the transparency and reliability of its audit claims.
  • The attackers demonstrated sophistication, utilizing platforms like 1inch and MetaMask.
  • It’s essential for the community to differentiate DAO Maker from other projects like Makerdao to prevent confusion.
  • Efforts should be made to enhance contract security, especially for projects that handle substantial user funds.

0 comments
0 FacebookTwitterPinterestEmail
wintermute-hack-analysis-sep-2023
Crypto Hacks & ExploitsWeb3 Security

Wintermute Crypto Exchange Hack – Sep 20, 2022 – Detailed Analysis

by ImmuneBytes
written by ImmuneBytes

Executive Summary

On Sep 20, 2022, the cryptocurrency market maker Wintermute experienced a significant security breach, resulting in approximately $160 million theft.

This report provides a comprehensive analysis of the incident, including its background, causes, impact, and the actions Wintermute took in response.

About Wintermute

Wintermute, founded in 2017, is a renowned global algorithmic market maker specializing in providing liquidity to centralized and decentralized trading platforms.

It has gained recognition as a key liquidity provider on various cryptocurrency exchanges, including Binance, FTX, and Kraken, decentralized finance (DeFi) platforms like Dydx and Uniswap and Crypto ETP of ETC Group

Since Sep 2022, Wintermute became the official market maker and strategic partner for the Tron blockchain network.

Wintermute in one of the largest players in the market and as of Q2 2023, it is working with more than 1000 counterparties.

Since May of 2022, it has executed over 8.4M total OTC trades, which also includes its single biggest trade which exceeded $1 billion.

Incident Overview

On Sep 20, 2022, Wintermute fell victim to a security breach that resulted in a substantial loss of around $160 million. Founder and CEO Evgeny Gaevoy confirmed the breach through a tweet, specifying that the funds were associated with Wintermute’s DeFi operations.

Importantly, the breach did not impact Wintermute’s centralized exchange or over-the-counter services, and the company assured users of the safety of their remaining funds.

Root Cause Analysis

The breach was traced back to a vulnerability in a service utilized by Wintermute called “Profanity.”

Profanity aimed to simplify complex cryptocurrency addresses by creating “vanity addresses.”

Due to the vulnerability in Profanity, it was possible for anybody with access to substantial computing power could generate every possible key or password created for any Profanity vanity address and also scan the accounts associated with it to know the amount of money they held.

As a result, malicious actors could generate keys and passwords for these vanity addresses to get unauthorized access to accounts and steal funds.

As per an estimate, by using around a thousand GPUs for 50 days, it was possible to brute-force private keys of every 7-character vanity address.

The author of Profanity had abandoned the project a few years ago, and due to lack of further development, this security flaw was never patched.

Wintermute attempted to mitigate the risk by blacklisting accounts using Profanity addresses. However, a human error within the Wintermute team resulted in one of the 10 accounts not being blacklisted, which is believed to be the avenue through which the $160 million was stolen.

It is believed that Wintermute had been using Profanity with the primary goal of reducing its trading transaction costs and not for simplifying complex names for accounts, which are generally 30-character-long combinations of varied letters and numbers.

Investigation and Analysis

Despite an extensive investigation, authorities have been unable to identify or trace any single individual or entity responsible for the Wintermute breach.

Initially, Evgeny Gaevoy, the CEO of Wintermute, expressed a willingness to treat the incident as a “white hat” event. This approach involves compensating a hacker for identifying and rectifying vulnerabilities within a system.

Gaevoy tweeted an address where the hacker could return 90% of the stolen funds, with the remaining 10% as a bounty. Unfortunately, no funds were returned, leaving the identity and motives of the hacker shrouded in mystery.

Numerous theories have circulated online regarding the possible perpetrators of the hack. Prominent cyber sleuth James Edwards suggested that based on analysis, smart contract code, and suspicious transactions, the hack might have been an inside job. However, it is essential to note that these theories remain speculative, as no concrete evidence has been discovered thus far.

Following the attack, Evgeny Gaevoy took to Twitter to provide updates. He disclosed that Wintermute’s DeFi operations had been compromised, but the company’s CeFi (Centralized Finance) and OTC (Over-the-Counter) offerings remained secure and unaffected.

Although, due to the exploit, Wintermute owed a debt of $200 million to several DeFi platforms, CEO Gaevoy reassured users that Wintermute remained financially solvent, with more than double the $160 million lost in the breach still available in equity. He also emphasized Wintermute’s commitment to honor loan recalls if users wished to exercise that option.

Stolen Assets and Transactions

In an official tweet, the Founder and CEO, Evgeny Gaevoy provided the breakup of the stolen funds. In this $160m exploit, the hacker took away about:

  • $120 million worth of Wintermute’s “stablecoins” including USDC and USDT
  • $20 million worth of Bitcoins and ether
  • Other insignificant cryptocurrencies worth $20 million

As part of the on-chain analysis, it was observed that the hacker transferred over $160 million worth of assets from 90 different sources to their wallet address: 0xe74b28c2eAe8679e3cCc3a94d5d0dE83CCB84705.

The hacker conducted various transactions to obscure the origins of the stolen assets:

  • Converted 9,470,755 BUSD to 9,467,293 DAI using Curve.Fi.
  • Converted 3,246,604 TrueUSD to 3,246,041.4025 DAI using an unnamed smart contract.
  • Converted 61,350,986 USDC to 111,953,508 using LP 3pool Curve.
  • Converted 23,609,070 DAI to 29,461,553 USDT using Curve.Fi.
  • Converted 350,000 WINU to 35 wETH using Uniswap V2.
  • Unwrapped 6,919.6925 wETH to ETH.

These transactions indicate an attempt by the hacker to mix and diversify the stolen assets, likely as part of an effort to launder the funds. Additionally, the hacker’s actions extended to the purchase of non-fungible tokens (NFTs), which further complicates the tracing of the stolen funds.

Furthermore, it is noteworthy that an incoming transaction of 9.9435 Ether was detected from a Tornado Cash address that had been flagged on Aug 8, 2022. It suggests that the hacker may have employed privacy-focused tools to obscure their activities and maintain anonymity.

The hacker’s wallet possessed diverse assets, including nearly $13 million in Wrapped Bitcoin (WBTC), $9.3 million in Ethereum (ETH), and various other tokens. 

Most stolen funds, amounting to $114 million in stablecoins, were transferred to Curve Finance to evade detection. By mingling with a pool of similar tokens worth $869 million, it became considerably more challenging for the asset issuers to freeze the stolen assets.

Aftermath and Recovery

Wintermute reassured its user base that the company’s financial stability remained intact, with over $350 million in equity, exceeding the amount lost in the breach. Additionally, users were given the option to recall their loans with the company to enhance their security.

Wintermute temporarily halted normal trading operations on its DeFi platform immediately after the breach for a brief period but later resumed operations.

It is worth noting that Wintermute had previously encountered an incident earlier in the year involving the accidental transfer of $15 million worth of optimism (OP) tokens, which the recipient eventually returned.

 Conclusion

The Wintermute crypto exchange hack of September 2022 highlighted the vulnerabilities inherent in the cryptocurrency ecosystem. While the hacker’s identity remains elusive, Wintermute demonstrated resilience and financial stability, reassuring users of the safety of their remaining funds and offering an option to recall loans for added peace of mind.

As the investigation continues, the cryptocurrency community emphasizes the importance of robust security measures in the evolving landscape of decentralized finance.

0 comments
0 FacebookTwitterPinterestEmail
Newer Posts
Older Posts