Excited to partner with the @Blockwarden_io team to innovate and develop new security products for the web3 ecosystem 🤝

Another day, another business logic vulnerability combined with a flash-loan attack! Rewinding to the $44.7 Million Hedgey Finance exploit on the 19th of April, we summarize and consolidate some of the key lessons learned around vulnerability and mitigation from the community. We’re teamed up with @ZealynxSecurity on this content, we'll be partnering to research more Web3 Security hot topics! As reported in @rekthq the protocol was exploited on both Ethereum Mainnet and Arbitrum Network across a series of transactions. The root cause lied in a lack of input validation on users’ parameters, allowing the attacked to manipulate and gain unauthorized token approvals. @CharlesWang published guidance on this topic a few days ago, xitter.cf/CharlesWangP/status/17…. In summary, improper input validation is the predominant root cause for smart contract issues. Missing or improper input validation is a vulnerability in a smart contract that occurs when the contract fails to adequately check and validate the data and parameters supplied by users or external sources before processing them. Consensys Diligence audited the protocol in question. The individual auditors from the firm, from a brief background check, are certainly experienced. Nonetheless, they missed this bug leading to critical exploit. Lessons learned around this that a single audit is not sufficient to gain robust security coverage. In our experience at least two audits by researchers with robust credentials and reputation is necessary and a bug bounty is also strongly advised to mitigate against potential exploit. You can check out @1nf0s3cpt's DeFiHackLabs repo (github.com/SunWeb3Sec/DeFiHa…) where there is already a PoC uploaded to replicate this exploit.

New post, new bug analysis! 🔍 Exploitable flaw found in Ondo’s lending protocol! Learn how an attacker can drain funds of initial depositors from the freshly deployed CToken contract. Our team member, @akshaysrivastv, uncovered a unique vulnerability in the CToken contract during the📷 @code4rena contest. Think you can spot it before we reveal the details? 👀💡 Background The CToken is a yield-bearing asset that is minted when users deposit underlying tokens. The amount of CTokens minted to a user is calculated based upon the amount of underlying tokens user is depositing. As per the implementation of CToken contract, there exists two cases for CToken amount calculation: 1. First deposit - when CToken.totalSupply() is 0 2. All subsequent deposits The Bug As the exchange rate is dependent upon the ratio of CToken’s totalSupply and underlying token balance of CToken contract, the attacker can craft transactions to manipulate the exchange rate. How can they do it? 1. Once the CToken has been deployed and added to the lending protocol, the attacker mints the smallest possible amount of CTokens. 2. Then the attacker does a plain underlying token transfer to the CToken contract, artificially inflating the underlying.balanceOf(Token) value. Due to the above steps, during the next legitimate user deposit, the mintTokens value for the user will become less than 1 and essentially be rounded down to 0 by Solidity. Hence the user gets 0 CTokens against his deposit and the CToken’s entire supply is held by the Attacker. 3. The Attacker can then simply redeem his CToken balance for the entire underlying token balance of the CToken contract. The same steps can be performed again to steal the next user’s deposit. 🔄 It should be noted that the attack can happen in two ways: -> The attacker can simply execute Step 1 and 2 as soon as the CToken gets added to the lending protocol. -> The attacker watches the pending transactions of the network and front-runs the user’s deposit transaction by executing Step 1 and 2 and then back-runs it with Step 3. Impact A sophisticated attack can impact all user deposits until the lending protocols owners and users are notified and contracts are paused. Since this attack is a replicable attack, it can be performed continuously to steal the deposits of all depositors that try to deposit into the CToken contract. The loss amount will be the sum of all deposits done by users into the CToken multiplied by the underlying token’s price. Suppose there are 10 users and each of them tries to deposit 1,000,000 underlying tokens into the CToken contract. Price of underlying token is $1. Total loss (in $) = $10,000,000 Recommended Mitigation Steps The fix to prevent this issue would be to enforce a minimum deposit that cannot be withdrawn. This can be done by minting a small amount of CToken units to 0x00 address on the first deposit.

We were delighted to have @escrow_ represent the SD team on stage for a live-audit showdown at @code4rena's Lmeow event at EthDenver! Check out a quick highlight video that the C4 team put together🔥 youtube.com/watch?v=Cw9BH5gY…

Want to know what an elite security researcher’s unique findings look like? We deep dive into two of our most talented, @saidamdev and @Xc1008Cui’s High Risk finding within the @code4rena INIT Capital invitational audit. @hansfriese was the judge for this contest. INIT Capital is a web3 protocol that allows users to Lend, Borrow & Access Strategies with Liquidity Hooks. The finding in question related to a vulnerability where an attacker could exploit the tokenOut function and replace the intended token to be transferred out with an arbitrary (high-value) token. In this case the exploiter would be a malicious order creator. Vulnerability Deep Dive When an order is created, there are 4 required validation checks. One of them is to check whether the order.tokenOut is equal to marginPos.baseAsset or _tokenOut is equal to marginPos.quoteAsset. 
This validation is crucial for ensuring that only valid tokens, specifically those that are part of the margin position being created, can be used in the order creation process. Unlike during the creation of the order, where certain conditions are checked to ensure that tokenOut matches specific assets, there are no such constraints when updating tokenOut within the updateOrder function. 
 This lack of restriction means that any token can be chosen or specified arbitrarily.
The ability to change tokenOut to any token of choice opens up the possibility of exploitation. Attack Vector Just before the order is filled, the creator (=attacker) can front-run the operation by changing the order.tokenOut to a token with a high value, leveraging their knowledge of impending market movements. The executor is likely to approve the hook with multiple tokens and transfer the amount using this new high-value token. Recommended Mitigation To validate the new token when updateOrder is called: By ensuring that the token used for the order update is one of the two assets associated with the margin position, the contract prevents attackers from manipulating the order to their advantage.