3 posts tagged with "Sharing"

Introduction​

In this monthly series, HashDit is sharing the monthly security incidents in the crypto space and what we can learn from them. For this Mar 2024 edition, the total losses mounted up to $146 million, showing a 50% decrease compared to March 2023.

Of which, they are split across 2 sections: DApps ($114m) and Phishing ($32m).

In this sharing, we focus on the DApps incidents. Below are the top 5 DApps incidents that DApp Developers should pay attention to.

Top 5 DApps incidents​

Munchables - $62.5m - Insider Attack​

Munchables is a GameFi and NFT protocol. In this attack, it was confirmed to be an Insider Attack where a rogue employee was malicious, gaining access to a privileged account. After malicious logic was introduced in a proxy contract upgrade, 62M funds were transferred out by the attacker. Thankfully, after some negotiation and investigation, the funds were eventually returned.

Root cause: Malicious developer was hired and suspected to be linked to DPRK, and had bad intentions right from the start. It was found that the malicious logic was already introduced during deployment and the bad actor used manual manipulation of the getLocked storage slot to assign himself an enormous Ether balance in the contract, so that his locked amount would bypass the withdrawal checks.

Onchain information:

Hack tx

Malicious contract upgrade

Code snippet:

Unverified contract

PrismaFi - $12m - Lack of Validation​

PrismaFi is a DeFi protocol, which is known as a non-custodial and decentralized Ethereum LST & LRT backed stablecoins. In this attack, the hackers bypassed the migrate function and called the flash loan directly with carefully crafted input data.

The flash loan's callback function, onFlashloan(), was called. The lack of proper checks allowed the hackers to close a trove owner's Trove and immediately reopen it within the same TroveManager. The transaction caused the owner's position to be closed and reopened, resulting in the trove owner having a new position with the same debt but less collateral and the difference in collateral sitting in the zap contract.

The hackers then opened a new Trove and used the MigrateTroveZap contract to migrate it, effectively using the remaining collateral for their own Trove. Finally, the hackers closed their Trove and took the profits.

Root cause: The root cause of the vulnerability was twofold:

1. By directly calling the onFlashloan() function, the user could manipulate other trove managers positions.
2. The contract allowed for a mismatch between the collateral in the initial position and the collateral in the new position, with the difference being susceptible to being taken.

Onchain information:

Hack tx 1

Hack tx 2

Hack tx 3

Code snippet:

WooFi - $8.7m - Price Manipulation​

WooFi is a DeFi protocol which operates as a DEX, allowing users to swap tokens. In this attack, the attacker was able to compromise the WooPPV2 contract on Arbitrum. The exploit consisted of a sequence of flash loans that took advantage of low liquidity to manipulate the price of WOO in order to repay the flash loans at a cheaper price.

Root cause: There were 2 configuration issues.

1. A previously unidentified error resulted in the price being adjusted far outside of the expected range ($0.00000009)
2. The fallback check, normally executed against Chain Link, didn’t cover the WOO token price.

Onchain information:

Hack tx 1

Hack tx 2

Code snippet:

SSS_HQ - $4.8m - Function wrongly implemented​

SSS_HQ or Super Sushi Samurai is a GameFi platform on Blast chain. In this attack, thankfully a White Hat was able to spot the bug before any malicious actor, where he increased his own balance by repeatedly transferring to himself. He subsequently swapped these tokens in the liquidity pool and protected the liquidity of ~$4.8m.

Root cause: The tax transfer logic is wrongly implemented in the _update method of the SSS.sol code. The _balances[to] value is incremented before the _balances[from] value is updated (done within the _postCheck method), seen in the first picture. As such, the balance of the to address uses the stale value i.e original balance, seen in the second picture. This is summed with the amount variable, stored in the toBalance variable and subsequently overwriting the _balances[from] in the last statement, almost doubling the sender’s balance.

Onchain information:

White-hat Hack tx

Code snippet:

Unizen - $2.1m - Lack of Validation​

Unizen is a DeFi protocol which operates as a DEX across multiple chains. In this instance, the attack happened on Ethereum, just 5 hours after the victim proxy was upgraded to a vulnerable logic contract. The vulnerable contract introduced a function 0x1ef29a02 which allowed arbitrary calldata to be sent.

Root cause: Lack of validation in a Swap related function (which allowed arbitrary transferFrom calls, specifying the From, To and Amount parameters). As such, victims that have approved their funds to this contract will be affected.

Onchain information:

Hack tx

Code snippet: Unverified contract

Key lessons for developers​

1. In light of potential insider compromises, it's crucial to apply thorough background checks for new employees. Specifically, keep an eye out for potential red flags including:

   • Preference for certain platforms: Malicious developers seem to favor using Github, often impersonating user profiles such as SuperTalentedDev726 or CryptoKnight415.

   • Use of numbers: Both email addresses and Github usernames often contain numerical sequences. It's suspected they use this as a method for tracking the identities they impersonate.

   • Asian identities: There's a tendency toward choosing Japanese (and possibly Korean) identities, often claiming prior education in Japan.

   • Prominent educational background: The falsified credentials often include elite universities in Japan, Hong Kong, and Singapore. Such institutions may include Singapore State University, Nanyang Technological University, University of Hong Kong or Hong Kong University of Science and Technology.

   • Codebase theft: While not always the case, these imposters often steal existing projects from GitHub and recondition the commit messages to reflect their assumed usernames.

   • Multiple applications: They tend to apply repeatedly for the same job, resorting to multiple email addresses for their submissions.

   • Premature expertise: They often claim experience in Solidity/EVM too early (such as in 2015), which is an unlikely scenario giving the nascent state of blockchain technology at the time.

2. Input validation is a crucial process - it's essential to verify all potential user inputs, especially when these inputs affect changes to the state of the system. This holds particularly true in the below scenarios:

   • Calldata Parameters: Given that attackers have the ability to craft any data, extra validation steps must be in place for calldata parameters.

   • User Approvals: During the process where the protocol contract manages users' approvals, meticulous input checks are paramount to prevent potential malicious activities.

3. To guard against price manipulation, it's essential to ensure that updated prices cannot be influenced to reflect unexpected values. Oracles, both on-chain and off-chain types, can be employed by developers. Here's how:

   • Set Boundaries: Implementing limits can block prices from being abruptly manipulated to an impossible value, regardless of the oracle type in use.

   • Fallback Oracle: Integrate a secondary oracle as a fallback measure. This ensures that if the initial oracle fails, there is a backup in place to verify the consistency of prices. By doing so, it ensures continuous, reliable price feeds, and safeguards against single point of failure.

4. Ensuring that the deployed function aligns with the intended objective is a critical requirement, especially for high-stakes operations such as accounting. This assurance can be achieved through:

   • Thorough Testing: Execute comprehensive fuzz testing and edge case analysis. This doesn't solely ensure correct function logic, it also helps to identify potential flaws and security vulnerabilities that might otherwise be overlooked.

   • Use Trusted Templates: Consider using trusted codebases, such as Openzeppelin, as a foundation for your code. These established libraries have been vetted extensively by the developer community, reducing the likelihood of introduction of unexpected bugs or issues.

Feel free to contact us at support@hashdit.io for any support needed! Stay safe!

*Unverified contracts screenshots courtesy of Dedaub’s decompiler!

Monthly Incident Sharing (Feb 2024)​

Introduction​

In this monthly series, HashDit is sharing the monthly security incidents in the crypto space and what we can learn from them. For this Feb 2024 edition, the total losses mounted up to $132 million, showing a 141% increase compared to February 2023.

Of which, they are split across 3 sections: DApps ($65m), CEXs ($62m) and Phishing ($5m).

In this sharing, we focus on the DApps incidents. Below are the top 5 DApps incidents that DApp Developers should pay attention to.

Top 5 DApps incidents​

PlayDapp - $30m - Private Key Compromise​

PlayDapp is a GameFi and Web3 Service protocol. In this attack, the hacker was able to compromise the original Minter account. As such, a malicious minter account was added and he minted 200m $PLA tokens, before dumping them on the open market.

Since then, the token transfer method has been paused and the token is planning to be migrated to a new address $PDA.

Root cause: The hacker was able to compromise the private key of the original Minter account. It is unclear if it was an internal or external attack.

Onchain information:

Add Malicious Minter tx

Malicious Mint tx

Vulnerable code snippet:

Ronin Network’s Jihoz - $10m - Private Key Compromise​

Ronin Network is a bridge protocol allowing cross chain of funds. In this attack, Ronin Network’s cofounder Jihoz had his wallet compromised. However, the attack is limited to only personal accounts, and does not affect operations of Sky Mavis and the Ronin chain.

Root cause: The hacker was able to compromise the private key of Jihoz’s wallet. As such, his assets were stolen from there.

Onchain information:

• Ronin: https://app.roninchain.com/tx/0x206bc24404b66f9a4424c7515bd6da92ce95640fae66fe217784a0edd71334dd https://app.roninchain.com/tx/0x93977df7f34204a88ed12ddb591e2e58a0aad6edfd009ca6db4491e14f9f38d9 https://app.roninchain.com/tx/0x9784ad2501cff282fa98a87272a9ac4379170fb80a2da92e5c7195fa5af274f1 https://app.roninchain.com/tx/0x7fb315e8c27d78f6a3c4bd812b2afcf0b3b3e80fd36c8db3ab3d0e9dfa58c291

• Ethereum: https://etherscan.io/tx/0x4962a88dfd49e49d3df0f290ae7d4b73632b2afc943a7ea5c2ee45140de7ad93 https://etherscan.io/tx/0x517dac8e59ca0d5e7017323a75dd732b2d48b07c9de20c2bfcaf1cee22cd7d7b https://etherscan.io/tx/0x5cd2b28d70b79d7f1d92f7273234f2a4ce3b153731ef44dffedac425de311201 https://etherscan.io/tx/0xcdd35d3c3a1b584dfa86732a61d5f42f6c5b0c03c6805ccd97294c6f1a0163f5

Vulnerable code snippet:

Shido - $3.3m - Private Key Compromise​

Shido is a L1 blockchain protocol which combines the interoperability of Cosmos, and the development power of EVM and WASM. In this attack, the attacker was able to compromise the StakingV4Proxy owner's wallet on Ethereum, upgrading to a malicious logic, withdrawing $SHIDO tokens and dumping them on the open market.

Root cause: The hacker was able to compromise the private key of StakingV4Proxy’s owner wallet. It is unclear if it was an internal or external attack.

After transferring ownership to a malicious owner, he immediately upgrades the StakingV4Proxy contract with a malicious withdrawToken() function that withdraws all $SHIDO tokens from the contract.

Onchain information:

StakingV4Proxy owner transfer tx

StakingV4Proxy upgrade tx

Withdraw all $SHIDO tokens tx

Vulnerable code snippet:

Seneca - $3.1m - Lack of Validation​

Seneca Protocol is a DeFi lending platform and stablecoin issuer. In this attack, the attacker was able to compromise approximately 1,385 PT-Kelp rsETH from a Seneca collateral pool. He subsequently swapped these tokens for approximately $3 million worth of ETH.

Root cause: There is a lack of validation check for the user input data in the performOperations() function. This bug allows any account to call the function while specifying OPERATION_CALL as the action to be performed, allowing an exploiter to arbitrarily invoke external calls to steal funds from approving users.

Onchain information:

Hack tx on Ethereum

Hack tx on Arbitrum

Vulnerable code snippet:

BlueberryFDN - $1.6m - Oracle Misconfiguration​

BlueberryFDN is a DeFi protocol which allows lending and borrowing of funds across chains. In this instance, the attack was front-runned by a whitehat, c0ffeebabe.eth. The vulnerability was due to the lending contract's incorrect handling of price decimals. As such, the attacker was able to borrow all the liquidity of three lending pools (OHM, USDC, WBTC) with extremely low collateral, since the assets borrowed are under-estimated, due to the non-normalized price.

Root cause: There was an incorrect usage of the oracle because the oracle always returns prices scaled to 18 decimals, thus causing assets that have less than 18 decimals to be undervalued significantly when being borrowed.

On Ethereum, WETH has a decimal of 18, OHM has a decimal of 9, USDC has a decimal of 6, and WBTC has a decimal of 8. Since BlueberryProtocol’s price oracle scales all token prices based on a decimal of 18, this caused the value of OHM to shrink by 1e9, USDC by 1e12, and WBTC by 1e10. As a result, the attacker managed to borrow assets worth 460 ETH by only collateralizing 1 ETH.

Onchain information:

Hack tx

Code snippet:

Key lessons for developers​

1. Keys should be properly secured, rotated regularly and have some level of decentralization. Adopt a zero-trust model. Conduct proper background checks for new employees in view of insider compromises.

2. Validation is important - ensure all possible user inputs are checked for state changing methods. This is especially true for calldata parameters where attackers can craft any data and when the protocol contract handles users’ approvals.

3. Proper handling of decimals in different tokens used in the protocol is fundamental, particularly when calculating token price values. Furthermore, guaranteeing that the price oracles used in the protocol are normalized to the expected decimals is critical. Price oracles provide current and accurate token prices, thus any discrepancies might lead to significant errors in token pricing and overall system operations.

Feel free to contact us at support@hashdit.io for any support needed! Stay safe!

Monthly Incident Sharing (Jan 2024)​

Introduction​

In this monthly series, HashDit is sharing the monthly security incidents in the crypto space and what we can learn from them.

For this Jan 2024 edition, the total losses mounted up to $153 million, showing a staggering 453% increase compared to January 2023.

Top 5 DApps incidents​

Orbit Chain - $81.5m​

Orbit Chain is a Bridge protocol, which uses the model of locking collateral on the source chain to mint wrapped tokens on the destination chain. In this attack, the hacker was able to compromise 1 of the bridge’s vault and steal its funds. Hack tx

Root cause: Backend compromise. The hacker was able to produce 15 correct Signer keys (v, r, s values), although the threshold needed was just 7.

Vulnerable code snippet:

Magic Internet Money (MIM) - $6.5m​

Magic Internet Money is a DeFi protocol which allows lending and borrowing of funds. In this attack, the attacker was able to compromise 1 of the protocol’s markets and steal funds. Hack tx

Root cause: The borrow function in CauldronV4 contracts was vulnerable to manipulation of the part parameter (the user’s share of total debt) via repeatedly borrowing and repaying an asset, taking advantage of the rounding error.

Vulnerable code snippet:

Gamma Strategies - $4.6m​

Gamma Strategies is a DeFi protocol which allows active liquidity management and market making strategies. In this attack, the attacker was able to compromise 1 of the protocol’s vaults and steal funds. Hack tx

Root cause: The liquidity ratio checker function erroneously allowed for deposits in any ratio so long as the contents within the vault were single-sided. This allowed for a disproportionate amount of token 0 being deposited, gaining more shares than expected. A second issue was there was no check for the current tick to be within the base position’s lower and upper tick (only a check for the tick change)

Vulnerable code snippet:

Radiant - $4.4m​

Radiant is a DeFi protocol which allows lending and borrowing of funds across chains. In this attack, the attacker was able to compromise 1 of the protocol’s markets and steal funds. Hack tx

Root cause: "New/empty market" exploit. It is a known vulnerability to the combination of a rounding error and a totalSupply value of 0. Bug introduced in recent upgrade.

Vulnerable code snippet:

Socket Dot Tech - $3.3m​

Socket Dot Tech is an Interoperability protocol bringing seamless connectivity across blockchains. In this attack, the attacker was able to compromise 1 of the protocol’s vaults and steal funds. Hack Tx

Root cause: Unsafe call in the performAction() function. The attacker constructed calldata in the swapExtraData parameter to call transferFrom() of arbitrary tokens, transferring tokens approved to the contract by other users to the attacker's address. Bug was introduced in the recent proxy upgrade.

Code snippet:

Key lessons for developers​

1. Keys should be properly secured, rotated regularly and have some level of decentralization. Adopt a zero-trust model. Conduct proper background checks for new employees in view of insider compromises.

2. Validation is important - ensure all possible user inputs are checked for state changing methods. This is especially true for calldata parameters where attackers can craft any data and when the protocol contract handles users’ approvals.

3. Rounding in Solidity always rounds down. As such, it is important to perform multiplication before division and to round down for the user during withdrawals, and round up during deposits. Consider increasing precision during calculations to avoid unexpected manipulation attacks.

   However, in the latest donation attacks for lending protocols, we see that the usual rule to favor protocol for calculations is no longer sufficient. There must be better health checks for bad debt as well, at the end state of a transaction.

4. For projects utilizing lending protocols:

   • When deploying a new market (especially for Compound / Aave v2 forks), ensure that it is first initialized with 0 Collateral Factor and deploy with small deposit to lock dead shares.
   • Disallow deposits when the pool price is out of the base range of liquidity.
   • Increase precision on price change thresholds and deposit ratios.
   • For those allowing single-sided pool deposits, add a conditional statement to prevent deposits of any ratio of assets so long as vault is single-sided.

5. Always engage a security auditor to review all code upgrades before they are deployed on chain. This prevents new bugs from being introduced.

Feel free to contact us at support@hashdit.io for any support needed! Stay safe!