Compound Finance Live Critical Vulnerability

Notice: This page is a freshly imported case study from the original repository. The original content was in a different format, and may not have relevant information for all sections. Please help restructure the content by moving information from the 'About' and 'General Prevention' sections to other sections, and add any missing information or sources you can find. If you are new here, please read General Tutorial on Wikis or Anatomy of a Case Study for help getting started.

Notice: This page contains sources which are not attributed to any text. The unattributed sources follow the initial description. Please assist by visiting each source, reviewing the content, and placing that reference next to any text it can be used to support. Feel free to add any information that you come across which isn't present already. Sources which don't contain any relevant information can be removed. Broken links can be replaced with versions from the Internet Archive. See General Tutorial on Wikis, Anatomy of a Case Study, and/or Citing Your Sources Guide for additional information. Thanks for your help!

Compound Finance

Compound Finance is a protocol which allows for decentralized lending. It operates with 18 separate markets including TrueUSD. A critical vulnerability was discovered during an audit. A public function can be used to sweep tokens accidentally sent to the smart contract, however this could also be used to empty the smart contract. Though funds could only ever be sent to the admin wallet, draining the wallet would significantly affect the value of TUSD to cTUSD. This could be exploited for significant profit (estimated at $3.1m) by an attacker. The vulnerability was patched before it could be exploited.

This is a global/international case not involving a specific country.

About Compound Finance

"Compound Finance is one of the most widely used protocols in the DeFi ecosystem. Deployed on Ethereum, its purpose is to issue automatic, permissionless loans of Ether and various ERC20 tokens. As of February 2022, the protocol held more than $10 billion in assets across 18 markets."

"To invest in Compound, users deposit Ether or supported ERC20 tokens into one of the protocol’s markets. In exchange, they receive cTokens for that market, with which they can redeem their investment. Compound’s cTokens are differentiated and denominated according to the underlying asset. For example, investors who deposit Ether (ETH) receive cETH tokens, which are redeemable for ETH. Similarly, investors who deposit USDC receive cUSDC tokens, which are redeemable for USDC, and so on. In addition to being redeemable for the underlying asset, cTokens can be traded according to their market value."

"The total value of each market increases as funds are lent out and repaid. As the value held in a market grows, the cTokens for that market increase in value and can be redeemed for more of the underlying asset. In this way, investors accrue interest. When the protocol operates as intended, the value of a cToken relative to its underlying asset should only increase, i.e., only positive interest rates should be possible."

"TrueUSD (TUSD) is a stablecoin on the Ethereum blockchain" "originally developed by TrustToken. It is tradable for assets and redeemable for fiat currency. It has very low volatility, and can be used as a hedge against market instability. All TUSD in circulation is collateralized on a 1:1 basis by U.S. Dollars held in escrow by banks, and these reserves undergo continuous attestations by a third-party. As of February 2022, $1.5 billion worth of TUSD was in circulation. At that time, approximately $88 million was invested in Compound, making Compound’s TUSD market its eighth largest. Investors who deposit TUSD into Compound receive cTUSD tokens, which have the properties outlined for cTokens above."

"Until recently, [TrueUSD] had multiple entry points, which could cause issues for various protocols." "In the case of TUSD, there were in fact two different contracts that both interact with the same balances. Essentially, the real implementation of TUSD is at the address 0x0000000000085d4780b73119b644ae5ecd22b376, and the secondary entry point 0x8dd5fbce2f6a956c3022ba3663759011dd51e73e simply forwards any calls to the primary contract. From an external point of view, this means that interacting with one of the contracts affects the balances of both. In most cases, this is not a problem, because you just supply one of the addresses to your contract and ignore the other. However, if you interact with both, you can run into issues."

"[A]n arbitrary address of a contract that implements the transfer and balanceOf functions can be supplied [to the sweepToken function]. Interestingly, this function was only added so that users who accidentally transferred their tokens to the contract could rescue them."

"[A c]ritical vulnerability in @compoundfinance live contracts was patched. It could have been exploited for millions of $."

"In the Web3 environment, it is possible for a wallet to send tokens to any smart contract, even if doing so has no purpose in keeping with the intended use of the smart contract. This can result in tokens becoming stuck. To address this problem, many smart contracts contain a function that sweeps stray tokens into a wallet so that an administrator can return them. All cToken smart contracts contain such a sweepToken function, which is configured to sweep stray tokens into the Compound Timelock described above. It is important to note that the function includes a check to ensure that the token address parameter to be swept is not the same as the underlying asset."

"First, [this function] make[s] sure that the token we are sweeping is not the underlying token of the CToken contract. Next, we check the balance of our contract and transfer any funds it might have to the admin. Recall that TUSD has two entry points — if the underlying token is the primary TUSD address, but we call this function with the secondary address, the require condition will pass. Hence, the contract will transfer its entire underlying balance to the admin address. Luckily, the developers had the foresight to at least transfer the tokens to the administrator, otherwise this exploit would have been far worse."

"Initially, it seems we can only transfer the underlying funds to the admin. This would effectively disable the contract, as no more funds could be borrowed or withdrawn, at least until the funds can be returned. While harmful, this is more of a griefing exploit and not profitable for the attacker."

"The exchange rate of TUSD / cTUSD is defined as (totalCash + totalBorrows - totalReserves) / totalSupply. Here, totalCash is the total amount of TUSD in the contract, totalBorrows is the amount of TUSD borrowed from the contract, and totalReserves is the amount that belongs to the protocol. Lastly, totalSupply is the total amount of cTUSD that have been minted."

"What happens to the exchange rate if all the underlying tokens are transferred away? It means that totalCash will be 0, the ratio of TUSD to cTUSD will drop and hence the value of cTUSD will suddenly precipitously drop. Later, when the funds are returned, the exchange rate will suddenly jump back to its initial value."

"It would be possible to return the swept tokens to the cTUSD contract, but deposits made before that could be done would cause irreparable damage. At the time TUSD deployed its patch, Compound’s TUSD market held approximately $88 million worth of TUSD, of which roughly half was redeemable and roughly half had been lent out. If exploited to the greatest extent possible, this vulnerability would have approximately halved the value of any redemptions made using cTUSD tokens issued prior to the exploit."

"Borrow TUSD, execute the attack, then pay back less TUSD." "At the time we discovered this exploit, [such an attack] would have yielded a profit of around 12% of the TUSD contained in the contract, which would have been around $3.1 million. Since then, the amount of funds in the contract has only increased."

"[G]reat care should be taken when calling into arbitrary contracts. If the caller can specify any contract that happens to conform to your required interface, you should expect that anything can happen."

"The issue, with several millions at risk, has been mitigated by Compound and OpenZeppelin." "[T]he secondary TUSD contract has been disabled, so the token now only has a single entry point." "In light of Compound’s Governance structure—which required that the fix would be publicly viewable for seven days before it took effect—OpenZeppelin noted that the planned “silent fix” posed certain risks. Seven days was potentially enough time for a skilled attacker to discover the vulnerability and exploit it."

"On February 4, the TUSD team initiated Proposal 84, which would have made updates to the TUSD market. OpenZeppelin had concerns. First, OpenZeppelin had not received sufficient prior notice of the proposal to assess the potential need for a security review. Second—and more important—OpenZeppelin was concerned that the proposal could draw undue attention to the cTUSD contract. Overall, the proposal created risks that were simply better to avoid. Therefore, OpenZeppelin recommended that the community wait to approve the proposal until it had been fully reviewed."

"OpenZeppelin also came to an additional unsettling conclusion: variants of the same vulnerability existed in other DeFi protocols. None of the variants that OpenZeppelin discovered were as severe as Compound’s, but their existence demonstrated that the “double entry” vulnerability was not Compound-specific. As TUSD is listed on as many as 30 DeFi protocols, it was certainly possible that other critical vulnerabilities existed in the DeFi ecosystem."

"To limit the duration of the exposure, OpenZeppelin would explain the vulnerability to the TrustToken team and give them 24 hours to commit to implementing a fix. Failing that, the Pause Guardian would halt Compound’s TUSD market, and Equilibria would propose its refactored cTUSD contract."

"OpenZeppelin presented this plan to the signers of the Compound Multisig at a meeting on February 22 at 12 PM U.S. Central Time (CST). They approved it and stood by for any indication that the Pause Guardian should halt the TUSD market." "TrustToken quickly came to a decision to take action while still in the meeting, committing to remedy the vulnerability within 18 hours. OpenZeppelin updated the Compound Multisig signers on TrustToken’s prompt decision."

"The two teams were in touch throughout the day on February 23. OpenZeppelin kept the Compound multisig signers apprised of the progress being made. The TrustToken team developed a patch that blocked calls from the legacy contract to the current implementation and deployed it at approximately 10 PM CST."

"The Security Research Team believes that this incident reached a successful resolution because all involved parties demonstrated high levels of technical skill, professional conscientiousness, and diplomatic ability. OpenZeppelin commends the TrustToken and TUSD teams on their expeditious business decision to remedy the vulnerability and their rapid and successful implementation of that remedy."

This is a global/international case not involving a specific country.

The background of the exchange platform, service, or individuals involved, as it would have been seen or understood at the time of the events.

Include:

• Known history of when and how the service was started.
• What problems does the company or service claim to solve?
• What marketing materials were used by the firm or business?
• Audits performed, and excerpts that may have been included.
• Business registration documents shown (fake or legitimate).
• How were people recruited to participate?
• Public warnings and announcements prior to the event.

Don't Include:

• Any wording which directly states or implies that the business is/was illegitimate, or that a vulnerability existed.
• Anything that wasn't reasonably knowable at the time of the event.

There could be more than one section here. If the same platform is involved with multiple incidents, then it can be linked to a main article page.

The Reality

This sections is included if a case involved deception or information that was unknown at the time. Examples include:

• When the service was actually started (if different than the "official story").
• Who actually ran a service and their own personal history.
• How the service was structured behind the scenes. (For example, there was no "trading bot".)
• Details of what audits reported and how vulnerabilities were missed during auditing.

What Happened

The specific events of the loss and how it came about. What actually happened to cause the loss and some of the events leading up to it.

Key Event Timeline - Compound Finance Live Critical Vulnerability

Date	Event	Description
February 22nd, 2022	Main Event	Expand this into a brief description of what happened and the impact. If multiple lines are necessary, add them here.

Total Amount Lost

The total amount at risk has been estimated at $3,100,000 USD. No funds were lost.

How much was lost and how was it calculated? If there are conflicting reports, which are accurate and where does the discrepancy lie?

Immediate Reactions

How did the various parties involved (firm, platform, management, and/or affected individual(s)) deal with the events? Were services shut down? Were announcements made? Were groups formed?

Ultimate Outcome

What was the end result? Was any investigation done? Were any individuals prosecuted? Was there a lawsuit? Was any tracing done?

Total Amount Recovered

There do not appear to have been any funds recovered in this case.

What funds were recovered? What funds were reimbursed for those affected users?

Ongoing Developments

What parts of this case are still remaining to be concluded?

General Prevention Policies

The smart contract vulnerability could have been prevented by carefully reviewing the functions and not providing public access to the sweep function. As returning funds requires the participation of an administrator, their participation is already necessary and they can be the one to retrieve the funds as well.

We recommend protocols get audits by at least 2 separate firms, with a third audit after 6 months. Protocols would become participants in the industry insurance fund, which would protect investors in the event of protocol failure. Platforms could reduce their insurance requirements by placing non-liquid funds in a cold storage multi-signature treasury wallet, which would limit the exposure to smart contract exploit risk. Once the protocol has sufficiently matured, third parties may be willing to underwrite the entire balance.

Individual Prevention Policies

No specific policies for individual prevention have yet been identified in this case.

For the full list of how to protect your funds as an individual, check our Prevention Policies for Individuals guide.

Platform Prevention Policies

Policies for platforms to take to prevent this situation have not yet been selected in this case.

For the full list of how to protect your funds as a financial service, check our Prevention Policies for Platforms guide.

Regulatory Prevention Policies

No specific regulatory policies have yet been identified in this case.

For the full list of regulatory policies that can prevent loss, check our Prevention Policies for Regulators guide.