With spot ETFs, regulations shaping up and increased attention to crypto in 2024, the industry is expected to develop and shape well in the coming years. Its strong ties with technology and innovation point to the risk factors surrounding it, sometimes proving the space is still a battlefield for clever exploits.

The blockchain security space is seeing tremendous growth as well, with novel security mechanisms and numerous firms devoted to researching new threats and safeguarding blockchain protocols. 

Our main focus for this article is crypto hacks that could have been prevented in the first half of 2024, specifically linked to smart contract vulnerabilities. Here are some notable exploits in 2024 so far and how they could’ve been avoided:

Radiant Capital - Manipulation of Index Parameter ($4.5 Million)

Not 3 days had passed since New Years, and we already lost $4.5M to an index parameter attack of Radiant Capital’s newly launched USDC borrowing and lending market. Radiant is a cross-chain lending platform, and history shows cross-chain platforms tend to be more risky. 

The attack was very clever, as the hacker pumped the liquidity index of the USDC reserve via flash loans, borrowed $WETH against the deposited funds and exploited a rounding vulnerability thereby extracting the original deposit amount and inflated fees.

How to prevent this hack:

It’s common to take advantage of newly launched forks from AAVE or Compound to a new market.

• As this error was an error in precision - test the code against all possible scenarios, making sure the math will work as intended.

• Always perform multiplication before division. 

• Make sure your liquidityIndex cannot be manipulated, and double-check for well-known vulnerabilities in your forked code such as Radiant’s rounding error in the rayDiv function.

Gamma Strategies - Inconsistency in Deposit/Withdraw Accounting ($3.4 Million)

Just the next day on January 4th, Gamma Strategies - an Arbitrum-based active liquidity management protocol was exploited. The main attack vector was that the team allowed for broad price changes in certain vaults. The attacker used flash loans to manipulate the value of deposits, thereby minting an inflated amount of LP tokens.

Despite four different deposit protection mechanisms, the price change threshold was set too high, allowing the hacker to benefit from depositing and withdrawing multiple times.

How to prevent this exploit:

With price calculations it’s always crucial to strike balance.

• Set the price change threshold to a level which protects price mechanisms in the beginning stages of the market. Allow for acceptable price changes while preventing excessive manipulation.

• Play out all scenarios beforehand during your testing period and teamwork with auditors. 

• Implement regular security checks as an ongoing practice. In most cases you’ll be happy deciding to follow the regular audits path, especially when implementing new markets on a regular basis and growing your protocol.

Socket Tech / Bungee Exchange - Unauthorized Fund Transfers ($3.3 Million)

Socket Tech is an interoperability protocol providing asset transfers across multiple chains. The Socket gateway contract combines all interactions with Socket’s liquidity layer, where all bridges & DEXs aggregate into a single meta-bridge & dynamically allocates assets based on user preferences such as security or costs. 

A day before the attack, an admin introduced a new routeAddress meant to wrap/unwrap assets during swaps. However, there was direct use of .call() with external user-provided data swapExtraData, which didn’t account for a scenario in which the user provides a zero amount.

The attacker created 2 contracts - the first one targeting the USDC of users who approved the vulnerable gateway contract, and the second aiming to acquire user’s USDT, WBTC, WETH, MATIC and DAI.

How to prevent this hack:

Router contract exploits are very common due to calldata and infinite contract approvals by users.

• As we keep repeating - always assume user input is malicious when designing your mechanisms. This is the only way to make sure funds are protected from bad actors.

• Implement access control mechanisms to prevent unauthorized parties from exploiting these functions.

• Audit your code each time you introduce new custom functionality, like in the case of Socket’s newly added vulnerable address.

Abracadabra Money (MIM) - Rounding Issue Causing Precision Loss ($6.5 Million)

Another rounding issue came about later in January, when Abracadabra Money was exploited. The attacker benefited from Cauldrons V3 and V4, which allowed for unverified borrowing of MIM tokens, took out a loan and manually repaid all user’s debt, setting the totalBorrow.elastic value to zero, and bypassing security checks.

The amount was not exactly zero due to rounding issues in the contract, creating a discrepancy between the values of totalBorrow.elastic and totalBorrow.base. The attacker then borrowed and repaid a single token multiple times, raising his proportion of share in the pool. Due to the discrepancy, his borrowed part seem very small and this way he managed to drain all liquidity.

How to prevent this exploit:

• Ensure you handle mathematical functions with high precision in your implementation, especially with percentages, ratios, multiplication, division and rounding.

• Once again, test the code for all edge case scenarios and from the perspective of a malicious actor prior to launch.

• Use libraries crafted for secure mathematical operations and always favour multiplication before division where possible.

• You can increase variables to higher amounts for more precise calculations, and scale back to the necessary final result afterwards.

Prism Finance - Granted Approvals to Vulnerable Contract ($10 Million)

Later on in March, Prism Finance suffered a loss of $10 Million due to a lack of input validation in the MigrateTroveZap contract.

The hacker, who later turned out to be a white hat, made use of the automated migration functionality. Upon trigger of migration, the contract took into account the debt to collateral ratio, as well as invoking a flashloan to finalize the process. However, the lack of validation made it easy to invoke flashloan first upon payment of a fee. This way the information on user debt becomes unreliable and a false migration of funds can be executed.

How to prevent this hack:

• Validate your inputs like your money depends on it. Cause well, it does. 

• Ensure only authorized actors and addresses can interact with sensitive operations.

• Upon external interactions, always implement mechanisms to detect if returned data is truthful.

• Mitigate such risks by employing the principle of granting only the absolute most necessary rights and privileges for mechanisms to function properly.

Pump Fun - Malicious Actor with Access to Admin Functions ($1.9 Million)

Unauthorized access to Pump Fun’s mechanisms was the cause of its $1.9 million exploit in May. A former employee attacked the bonding curve (the relationship between circulating supply and token price), borrowing large amounts of $SOL and buying as many coins as possible on Pump Fun to make them reach 100% on their bonding curves. Then, he could access the liquidity and repay the loans.

How to prevent this exploit:

• Always check and update permissions when changes in your team occur.

• Employ a RBAC (Role-Based Access Control) to ensure only authorized users have access, especially to paramount functions such as withdrawals.

• Require extra approvals when necessary with multiple signatures required from other members of the core team.

• Implementing a real-time monitoring system will alert you in the beginning stages of such exploit.

Normie on Base - Design Flaw in Cross-Chain Bridge ($881K)

Normie’s cross-chain bridge was exploited at the end of May. Taxes on transactions with $NORMIE were sent to a team address. There was a vulnerability in the smart contract logic that allowed the exploiter to trick the contract into recognizing their address as privileged. All he had to do was have the same amount of NORMIE tokens as the team’s wallet.

He used flash loans to send a big sum of tokens to the team address, causing a dilution and a token price crash. $NORMIE funds at risk became 650 billion tokens, while only having a total supply of 1 billion tokens.

How to prevent this hack:

• Implement strict checks to prevent unauthorized addresses from being added to user lists.

• When it comes to changes to your token supply, and other important actions - make sure multiple signatures are required from trusted members of your team before the change takes effect.

• If you have forked memecoin contracts, carefully audit their implementation, to search for a similar vulnerability and mitigate it.

BOGE (DOGE on Base) - Vulnerability in Token Minting Process ($16K)

Another memecoin suffered the same attack the next day!

Hackers were quick to take what they learned the day before, and check whether identical projects have the same vulnerability. $BOGE on Base was just the right catch. 

How to prevent this exploit:

• Similarly, one option is Introducing checks to counter such an attack.

• Even a better solution is changing the design of the system so that it doesn’t compare token amounts when making authorization decisions. 

• Audit your code thoroughly prior to deployment, and definitely prior to high market cap growth. Remember to research and learn from past hacks in identical code.. even if they happened only yesterday!

UwU Lend - Price Manipulation ($23 Million)

Lending protocol UwU Lend fell victim to an oracle manipulation back in June. The Aave V2 fork had a price discrepancy in its oracles. The fallback mechanism was customized so that oracle fallback logic borrows assets at one rate and liquidates them at an artificially inflated one. 

Labeled as one of 2024’s weirdest money theft, it’s bizarre how this vulnerability went unnoticed by PeckShield. Not clear whether oracle mechanisms were designed this way pusposefully, however the fallback oracle was calculating price from several Curve pool states. The attacker could manipulate the pool state using borrowed tokens, and after that liquidated at a different rate.

How to prevent this hack:

For the purposes of prevention of such hacks, let’s assume this design was unintentional.

• To safeguard against such oracle manipulation, make sure no single oracle dictates results by utilizing multiple decentralized oracles to aggregate price data.

• Implement checks to validate the prices received from oracles against expected ranges or historical data, or implement Time-Weighted Average Pricing to deal with price fluctuations over time.

Kraken - Vulnerability Following a User Interface Update ($3 Million)

What was the interface update causing Kraken to lose control of $3M of its funds in June?

Security firm CertiK claimed they were testing the vulnerability they found, taking too long before disclosing it. 

The vulnerability - allowing users to initiate deposits and receive the funds, even if the deposit is not yet completed. No actual user funds were in danger, however for a brief period of time users could artificially print money in their accounts.

How to prevent this vulnerability:

• Always audit your mechanisms and architecture before deploying any changes. This vulnerability could easily be prevented if only noticed a tad earlier. Instead, it turned into quite the headache and a full-blown scandal between big industry players Kraken and CertiK.

LIFI - arbitrary call vulnerability ($10 Million)

LIFI is a bridge and DEX aggregation protocol. Last month the LiFi Diamond Contract was exploited in a security breach.

There was an arbitrary call vulnerability, allowing the attacker to make unauthorized transactions via transferFrom operations, for users who had infinite approvals. DepositToGasZipERC20 function lacked certain validations, while the swap function didn’t check call data - bad!

How to prevent this hack:

Don’t allow infinite approvals.

• Set a cap on approved fund transfers, reducing the risk of large unauthorized amounts.

• Implement stricter validation mechanisms to ensure safety against such attacks.

• Identify an attack-prone function beforehand during a comprehensive security review.

• Introduce a circuit breaker - detect the malicious transfers before they have the chance to reach as high as $10M.

Smart Contract Audits Significantly Decrease Attack Risks

The security of your smart contracts is paramount to protecting user funds and maintaining trust. Our team at Audita specializes in identifying and mitigating the above listed smart contract vulnerabilities.

We provide future-proof smart contract security services that can safeguard your projects against potential theft, ensuring that your smart contracts operate securely and efficiently. Don't leave your assets to chance—partner with us at Audita for peace of mind and robust protection against risks in the blockchain space.

Building a safer Web3 together, one audited protocol at a time.

STAY SAFU

Audita's Team