Securing Your Crypto: Exploring 9 DeFi Incidents

Exploring 9 Incidents from August to November 2022

Today we will be discussing the various ways Coinchange has gone the extra mile to protect its users from the dangers of DeFi hacks. As the DeFi space continues to grow, so too does the number of malicious activities. Thankfully, Coinchange has taken the initiative to shield its users from potential hacks and cyber threats. From advanced protocol Risk Assesment Frameworks to a dedicated team of Research Professionals, Coinchange has equipped itself with the necessary tools to ensure a secure DeFi yield earning environment. In this blog, we will be exploring 9 different DeFi incidents/exploits that happened since August 2022, and the various ways Coinchange has worked to protect its customers from those risks. Interestingly, 1/3rd of these incidents have been related to bridges/interoperability protocols and hence Coinchange Research team is publishing a long form report on the Interoperability of Blockchains. So, let's dive right in and find out how Coinchange is safeguarding its users!

#1. Uniswap User Loses $8M Worth of Ether in Phishing Attack.

Uniswap User Loses $8M Worth of Ether in Phishing Attack. The attacker enticed users with a fake Uniswap airdrop message. The message claimed to airdrop UNI tokens to liquidity providers (LP) based on the number of fake LP tokens they received. Liquidity providers supply their assets on Uniswap in return for rewards. Interacting with the phishing message, however, gave the underlying smart contract permission to transfer assets out of and gain full control of a user’s wallet. One person, who was providing over $8 million worth of wrapped bitcoin (WBTC) and USD coin (USDC) to a WBTC/USDC liquidity pool, according to blockchain data, unknowingly interacted with the phishing message. In the hours following the attack, Binance founder Changpeng Zhao alerted users to be aware of a possible exploit on Uniswap. This was however later corrected, as the exploit was limited to a phishing message and did not affect the Uniswap protocol.

‍

The attacker was able to gain control of the wallet, exit the LP’s positions and transfer the tokens to other wallets. Blockchain data further shows the attacker started to move stolen funds through privacy protocol Tornado Cash.

Does this hack affect Coinchange? 

Phishing scams happen all the time. However we are not exposed to this attack as Coinchange doesn’t interact with any UI for any protocol that we use in our strategies. We create proxy contracts that directly interact with the smart contracts of the protocols and this eliminates the interaction with the UI or the website interface of the protocols. 

#2. Nomad just got drained for nearly $200M in one of the most chaotic hacks ever. 

First of all, Nomad is a protocol that allows the transfer of funds between blockchains aka it is a bridging protocol. There were a series of transactions over the Nomad Bridge between the Moonbeam and Ethereum networks where users would initiate a transaction sending 0.01 WBTC to the bridge from Moonbeam and they would receive 100 WBTC on the Ethereum network. Send 0.01 WBTC and receive 100 WBTC. Typically these transactions should be a two-step process. 1. Proving the validity of the transaction and 2. Processing it. In this case, the transaction was processed without proving validity. In an upgrade to the protocol, Nomad decided to initialize the value of trusted roots to 0x00. To be clear, using zero values as initialization values is a common practice. Unfortunately, in this case, it had a tiny side effect of auto-proving every message. This is why the hack was so chaotic - once an attacker started the hack transaction, anyone could simply copy the transaction without knowing how it worked, and execute the hack from their account allowing them to steal the funds. 

PeckShield found that one of the Nomad bridge exploiters is also a RariCapital (Fuse Arbitrum) exploiter, who gained ~$3m in this exploit. Also, the Connext protocol which is a bridging protocol had collaborated with Nomad to provide liquidity on Nomad and they lost 3m in this hack out of the 190m. 

Once it became known, the whitehat hackers stepped in to execute the hack in the same way only to return the funds to Nomad. The Nomad team is asking hackers to return at least 90% of the stolen funds or else risk legal action. So far they have managed to recover $32M. 

Does coinchange participate in providing liquidity to bridges? And if so, how do we mitigate the risks? 

Coinchange doesn’t provide liquidity to bridges. We only use the bridges to transfer assets from one chain to another. Before we integrate and use the bridge we assess 4 main risks with our risk assessment framework, mainly: Smart Contract risk, Financial/liquidity risk, Operational Risk, and Decentralization risk. We pay particular attention to the messaging being used by the bridge and the trust assumption. This process we have in place at Coinchange helps us select only the most secured bridge for our cross-chain strategies. Additionally, the learnings from these hacks are included in our research processes making it a robust framework.  

#3. Acala Network hack

On Monday, August 15, 2022 The Acala hack saw over 1 billion aUSD stablecoins minted from thin air. aUSD stablecoin depegged by over 99% over that weekend and forced the Acala team to pause the hacker’s wallet, which is raising concerns about its true decentralization.

What is ACALA? Acala is a cross-chain decentralized finance (DeFi) hub that issues the aUSD stablecoin based on the Polkadot blockchain. AUSD is a crypto-backed decentralized stablecoin which Acala calls censorship-resistant stablecoin. A new iBTC-aUSD liquidity pool that launched on Aug 13th contained a software bug. That bug resulted in those error mints of aUSD which were transferred to the wallet addresses of a number of iBTC/aUSD LP contributors when they claimed their iBTC/aUSD LP Rewards. This resulted in 1.2 billion aUSD being minted without collateral. This event crashed the U.S. dollar-pegged stablecoin to $0.01, and in response, the Acala team froze the newly minted tokens by placing the network in maintenance mode.

If we look at the price chart here, aUSD started depegging around Aug 13th 2022, dropped to around 70 cents, then went back up to almost 1 dollar and then fully depegged to 1 cent. So that’s the bad news.

The good news? 99%+ of the erroneously minted aUSD remained on Acala parachain, and only a small proportion was transferred out from Acala parachain. The 99% was immediately locked from further leaving the system and a governance vote was passed to burn these 1B+ aUSD with 95% voting in favor of burning.

As of August 24th, aUSD is floating around 70 cents on the dollar.

How does Coinchange mitigate such risks? 

One thing is clear that even if protocols themselves are audited, there can still be bugs that go undetected in the smart contracts of newly launched pools within the protocol. At coinchange we check the extent of audit coverage and we flag the sections of the protocol that have not been audited. Another metric we look at is how long the pool has been active for and how many transactions have occurred in that pool till date. This tells us the maturity and robustness of the smart contract. In this case, the iBTC/aUSD pool was launched 2 days before this incident happened and as such would not have passed requirements in the Risk Framework. Besides, Coinchange doesn’t interact with Polkadot Ecosystem yet, as they are still in their early stages. 

#4. Compound ETH Market Freeze Analyzed By Coinchange

Compound voted on-chain for implementation of a new oracle price feed for its market (moving from Uniswap v2 to Uniswap v3). The issue arose when the change was implemented as it resulted in essentially the ETH market being frozen. No more borrowing could occur since all borrow attempts would revert. The code had been previously audited by 3 audit firms (Dedaub, ABDK and Open Zeppelin) before voting took place. Once the issue was flagged, the decision was to revert to the previous oracle price feed contract that is still operational.

This is where the controversy or issue arises. Two paths are currently used to deal with such urgent issues in the space:  a protocols team could quickly revert to the previous working contract if they have full control over the protocol's smart contract via admin key. Second way of doing it is through governance process with multisig + timelock, which Compound uses. The full process takes at least 7 days to implement changes in the case of Compound and can take less or more than that depending on the governance process for the particular protocol. 

The voting already happened for Compound and the oracle reverting to the previous version happened on September 6th. No funds were stolen or lost in this process but the ETH market was not available for the 7 day period. 

How does Coinchange protect users against such events?

Those issues are common in the space, again audits are mere snapshots of the smart contract reviewed at one point in time. If changes happen after the audit, they can become voids of relevance. Also, the governance process for urgent matters like this one or other (pausing market due to extreme volatility for a token) are something that could benefit from a dedicated multi-sig which could enact changes faster. Coinhange analyzes the governance process and control over the protocol smart contract in its risk assessment framework, and as per our analysis, it is evident that ownership of the protocol via admin key only rather than multisig + adequate time lock duration are most probable to attacks leading to users loss of funds.  

#5. Wintermute lost $160M due to compromised hot wallet

Wintermute was hacked for ~160m on September 20th. It was a hot wallet compromise due to the Profanity bug that was publicly disclosed a few days ago by 1inch team.The attack started with a transaction where Wintermute’s hot wallet started calling their vault contract to transfer tokens out to the hacker’s contract. The vault only allows admins to do these transfers and Wintermute’s hot wallet is an admin. We can say that the contracts worked as they should but the admin address itself was likely compromised.

The Real Issue: 

The admin address was a vanity address (i.e. it starts with several zeroes) which were generated using a tool called Profanity. Profanity had a critical bug that was disclosed by 1inch team just a few days prior to this exploit. 

Why didn’t Wintermute act on this news from 1inch?

The CEO of Wintermute said that when the bug disclosure by 1inch team happened, wintermute accelerated the “old key” retirement. But due to an internal (human) error, a wrong smart contract function was called and they blacklisted the router instead of the operator (contract that signs). 

The result:

The attacker funded the Wintermute admin address using their own ether to pull off the exploit.

It seems that the attacker exploited the bug in Profanity to recover the private key of this hot wallet. Wintermute said they are still solvent and healthy so there’s no need to panic. Founder and CEO of wintermute addressed this on twitter: 

‍

The CEO says that they did use Profanity and an internal tool to generate addresses with many zeroes in front (0x0000000). But their reason behind this was gas optimization, not “vanity”. What do you think about this, Jerome and how does Coinchange mitigate such issues?

How does Coinchange guard users against such risks? 

This is a challenge of running an Automated Market Maker, ie 100% on-chain. Most of the exploits come from human errors or from bad security practices. Investing into processes to minimize human impact is something we need to continuously focus on as well as keeping up with best security standard. Being purely on-chain brings a whole new level of complexity and attack vectors, and that’s why at Coinchange we have an off-chain logic being executed on-chain through proxy smart contracts, which can only work in one way. No one can get access to it since we’ve built our execution infrastructure to prevent it from happening.

#6. Binance Bridge hack which resulted in initially $500+ million stolen.

What is the Binance hack about?

BNB Chain, the blockchain, is composed of BNB Beacon Chain and BNB Smart Chain (BSC). BSC Token Hub bridge was exploited and the hacker took 2,000,000 BNB worth about $570m. The BNB Chain was halted after the exploit was discovered. A tweet from the official BNB chain Twitter account indicates the chain is back in operation after pushing out a software update to freeze hackers' accounts. The chain validators adopted a software update that would close the exploit used by hackers to drain funds. 

But the way the attacker executed the exploit was by forging proof of validity on two separate blocks. This is the second hack of its kind, where Wormhole bridge suffered an exploit from a similar attack vector. In short, there was a bug in the way that the Binance Bridge verified proofs which allowed the attacker to forge arbitrary messages. Fortunately, the attacker here only forged two messages, but the damage could have been far worse. 

An interesting thing to note is that Binance is the largest user of the Cosmos software. Binance Token Hub inherits from the Cosmos IBC repo. IBC stands for Inter-Blockchain Communication and “is a protocol for interoperability between different ledgers. It is being designed and implemented as a core component of the Cosmos network, where multiple tendermint based or non-tendermint based ledgers connect to each other.” as per Cosmos’ Medium. The crux of the problem is that a hacker was able to forge a Merkle proof. A Merkle proof is a cryptographic proof. Many blockchains store their data in a Merkle tree so that proofs can be produced proving some piece of data is included in the tree. Merkle proofs are used heavily in IBC so that e.g one blockchain can prove it has a packet destined for another. Of course, it would be a big problem if you could prove that some piece of data is in the tree but it actually isn't. This is basically what happened with Binance. 

What do we learn from this and how can Coinchange mitigate such risks? 

Coinchange doesn’t participate in liquidity provisioning on bridges. So such hacks do not affect our user funds. Secondly, we must all take security seriously. This incident is an opportunity to remind everyone of the importance of strong security practices in the software development lifecycle, to spread some awareness of what IBC is and how it works, and to invite the entire ecosystem to help improve IBC. This should be true for the other types of bridge implementation across ecosystems as they are key to a successful interoperable crypto landscape. 

#7. Mango Markets on Solana Blockchain were exploited for over $100 M.

What is Mango Markets?

It is a Decentralized spot margin, perpetual futures markets, borrowing and lending protocol on Solana. It is permissionless, all on-chain and all markets are collateralized. Sounds like a perfect Web3 protocol with plenty of functionality. So what could possibly go wrong? 

There are two things here that were key for this exploit to happen:

1. Health factor
2. Too many feature packaged for “maximum capital efficiency”

‍

Jerome, Coinchange’ Head of Research put together a thread explaining the exploit and remediation to it.

Lets unpack the first one:

A health factor represents the status of a position based on the collateral value against its liquidation threshold. Generally health factor below 1 mean liquidation in MMP. Health factor above 1 mean no liquidation and head room to borrow more since collateral value is superior than borrowed value. This is the mechanism that was exploited.

Going onto second aspect:

While Mango Market pushed the boundary of product combination (lending/borrowing + perpetual futures markets and spot margin) this is where the issue came from. Indeed the health factor take into consideration all those components (as it should be) to calculate the position eligibility to borrow more or if it should be liquidated. In this case the exploiter team (Avraham Eisenberg + others) leveraged the mechanism of unrealized profit on a perpetual position on MNGO to inflate their health factor, allowing them to borrow (withdraw) all crypto from Mango Markets worth around $116M at the time. 

In details here is what happened: 

Two accounts were used to conduct the exploit. On account “A,” the team initially used 5 million USD Coin (USDC) to purchase 483 million MNGO and go short, or bet against, the asset. Then on account “B,” the team used another 5 million USDC to buy the short position opened by Account A, to effectively hedge the position (short + long position of same amount). 

The group then used more funds to buy up spot MNGO tokens, taking its price from just 2 cents to as much as 91 cents within a ten-minute span. This was only possible as spot MNGO was a thinly-traded token with low liquidity, which allowed the group to manipulate the prices.

As spot MNGO prices increased, the account “B” quickly gained around $420 million in unrealized profits which was used in the account health factor calculation. Because of that prop up health factor, the exploiter was then able to borrow (i.e withdraw) around $116 million in liquidity from all tokens available on Mango, which effectively wiped out the protocol and made it insolvent. (only $116 M borrowed because MNGO has a collateral factor of 20%.)

Here oracle providers had no faults. The oracle price reporting worked as it should have," Mango wrote on Twitter.

On October 12th, the exploiter team made a proposal on Mango Governance to try and negotiate for a bounty and to be clear of legal investigations. It failed to meet the quorum.

As of october 18th, another vote has passed where the Mango team asked the exploiter team to reimburse the funds to the treasury. 

The exploiter team reimbursed the funds while keeping around $50M as a “bounty”. 

What does Coinchange recommend to prevent such incidents?

This is the first situation of  its kind: economic exploit with doxxing of the exploiter and usage of a portion of the exploited fund as bounty. But there are three ways in which we can reduce the occurence of such issues:

1. Quadratic voting: essentially allows a voter to signal how deeply they care about an issue by making it costly to only vote for it (either with credits or with real token). This protects DAO governance from attacks of voter that don’t feel like spending the credit. 
2. Threshold for “NO” votes could be implemented. On top of quorum threshold (minimum number of vote both “YES” & “NO” to consider the vote valid) this could help sort the issue of the “NO” vote not considered in case of attacks or high concentration of voting in selected users.
3. Strong Due Diligence on the liquidity of the governance token. Understand the attack vector that long-tail asset creates for MMP and model the risk. We saw a similar situation in Venus hack. 

Our risk assessment framework has questions that look for these features in the lending protocols helping us filter out the ones that don’t pass our framework test. 

‍

#8. Derebit Exchange Hot wallet Hack

Deribit, launched in 2016, is a leading cryptocurrency futures and options exchange that enables crypto traders to execute derivatives trading strategies. Their hot wallet was hacked for $28m on 1st November 2022. But in their tweet they said that the client funds are safe and loss is covered by company reserves. Which was a bit confusing because how can the client funds be safe if you just lost $28m? They clarify this by saying that it's their company procedure to keep 99% of user funds in cold storage to limit the impact of these types of events and that they have enough company reserves to cover for these losses meaning effectively no user lost any funds. 

Also the hack was applicable only to BTC, ETH and USDC hot wallets where they got drained completely within minutes. They halted withdrawals to make sure it is safe to open it back up. 

How did this happen?

The attacker was able to get access to their hot wallet server which enabled him/her to withdraw the funds from those hot wallets. They withdrew BTC, ETH and USDC and later converted all the USDC to ETH. So currently the stolen BTC and ETH sit in an externally owned attackers wallet which is outside of Deribit’s control. How the attacker got access to the server is still not clear. Was it a regular phishing attack like in the case of the Ronin hack that gave the attacker access to the server? Or was it an insider who already had access to the server? We don’t know as of this recording. 

How will they make up for the lost money? 

Well, they have two ways, Insurance funds and Protocol Reserves. And in this case, they mentioned that the insurance fund will not be affected and the Protocol Reserves are sufficient to cover the loss. They do not openly communicate about how much they have in reserves but they do have around $40M in the insurance fund. 

How did they fix the issue?

• They re-generated the deposit wallet addresses on the front end and removed the old deposit addresses. 
• They migrated all hot wallets to Fireblocks which resulted in all Deribit deposit addresses to be renewed.
• All on-chain withdrawals require manual (human) approval for the time being by a Deribit admin on the 3rd party Fireblocks application.
• And they have appointed an on-chain forensics company to assist with tracking and recovery of assets or liaising with global law enforcement. 

What steps does coinchange recommend these exchanges take?

With the limited information that we have at the moment, this is clearly not a web3 attack vector, but a Web 2 security breach. One of the issues in Web 3 is that we have a tendency to emphasize too much on smart contract audits and coding best practices, which is essential but not sufficient. We simply cannot ignore the traditional cybersecurity best practices of Web 2 such as keeping your servers secure so that hot wallet keys are not lost. It is very surprising that an exchange that has been in operation since 2016 (7 years) gets attacked for traditional cybersecurity issues. We talk about this in much detail in our next long-form research report on the “Interoperability of Blockchains” which will be released in December. The bottomline is we should make sure that the Web 2 infrastructure that enables the Web 3 applications is secured by the best cybersecurity practices. 

#9. FTX and Alameda Research Fiasco

Alameda Research is a quantitative trading firm and as of 2021, Sam-Bankman-Fried owned approximately 90% of it. FTX is a cryptocurrency exchange that offers derivatives, options, volatility products and leveraged tokens also owned and managed by Sam-Bankman-Fried. 

Alameda Research and FTX were intrinsically connected; Alameda had participated in FTX’s ICO and received $4.19B worth of FTT (FTX’s native tokens) in exchange. Fast forward to Q2 2022, many believe that Alameda blew up along with 3AC and others but they only survived because they were able to secure funding from FTX using some of the FTT as collateral. Later FTX continued to solidify its image as a solvent and responsible entity that could bail out any failing crypto business which helped FTT’s price which was crucial to save Alameda. 

All this would have been fine if the price of FTT didn’t collapse. However, on Nov 2, CoinDesk reported that Alameda’s balance sheets are largely made of FTX’s native FTT token. It showed that trading giant Alameda’s balance sheet was made up of a coin that a sister company invented. As per the article, “ As of June 30, the company’s assets amounted to $14.6 billion. Its single biggest asset: $3.66 billion of “unlocked FTT.” The third-largest entry on the assets side of the accounting ledger? A $2.16 billion pile of “FTT collateral.” Other major asset was SOL tokens which is Solana blockchain’s native currency which SBF was an early investor in. 

As this news spread, CZ the founder of Binance tweeted this:

‍

‍

This caused a FUD, resulting in a selling pressure on the FTT token. This puts FTX and Alameda in a bad spot as Alameda loans would get liquidated since they used FTT as collateral. At this moment we don’t have the full details but there is good reason to believe that the drop in price of FTT caused Alameda to become insolvent and a series of withdrawals from FTX users created a bank run on the exchange. 

At this point it is clear that FTX has a hole in their balance sheet because it lent money to Alameda either to generate yield or to bail them out following the 3AC collapse. Bottom line is that Alameda Research is a trading firm that secured centralized loans which they are unable to repay now. They also took some DeFi loans which they already repaid because those positions were public, and the liquidations happen by code without warning. So if you were an indirect lender to Alameda through a DeFi protocol, you got your money back. If you were a centralized lender to Alameda, you are in deep trouble. 

This is why Coinchange has never and will never participate in centralized lending activities although it might provide a higher return. 

How is Coinchange unaffected by this incident? 

As a centralized DeFi Yield provider we don’t lend out user funds off-chain, nor do we trade/lend to CeFi Exchange. Ever! We use our customer assets in DeFi protocols that are run by math/code and transparent blockchain data. Centralized Lenders such as FTX, Celsius and BlockFi have loaned out user funds off-chain and customers had to trust them without any transparency or control over the funds. Any individual can access DeFi yields if they have the right resources, knowledge and time. However it is extremely tedious, time consuming and expensive to earn DeFi yields but at Coinchange we have the benefit of  economy of scale to reduced the gas costs and optimize strategies algorithmically resulting in higher yield.

Conclusion

In conclusion, Coinchange has taken a proactive approach to protecting its users from DeFi hacks and cyber threats. Through advanced protocol Risk Assesment Frameworks, a dedicated team of Research Professionals, and other measures, Coinchange has gone the extra mile to ensure its customers are safe. This blog has provided a look into 9 DeFi incidents since August 2022, and how Coinchange has worked to protect its users from them. It is clear that Coinchange is committed to providing a secure environment for its users to safely earn yield through DeFi.

Here’s what Coinchange is doing to increase user confidence:

‍

• We are publishing monthly Asset Allocation Reports (Transparency Reports) which show how our users' funds are being used to earn yield. We openly provide our AUM breakdown, list the DeFi protocols and Blockchains we participate in, and inform you what the Coinchange team is working on next. 

• We have a robust risk assessment framework in place and will be working with one of the big 4 accounting firms to attest and verify that it follows financial industry evaluation standards. This consultation with the firm will also confirm that the framework is standardized in a manner that removes human discretion to the maximum, allowing anyone using it to derive the same final risk score that Coinchange uses internally.

• We are in the process of finalizing our financial audit and will do the attestation of assets  from Grant Thorton  in Q1 2023. 

• We are having concrete discussions with various DeFi cover providers to protect our user funds in case of black swan events (DeFi hacks, Governance attack, Smart Contract vulnerabilities, oracle attack, economic attack, de-peg event).

‍

Since the inception we have deployed user funds only in DeFi. We have never allowed any centralized counterparty to borrow our user funds directly. All the assets are strictly deployed on-chain. This causes our yield to be lower than some of our competitors but allows us to earn safe yield. While Coinchange does not have a dominant market share yet, we are adhering by the DeFi rules. The unapologetic nature of this industry means that unsustainable and poorly managed companies get purged in each cycle and only those with sustainable and diversified business models survive, and over time benefit from the adoption.

‍