Compound Finance Live Critical Vulnerability

Notice: This page is a new case study and some aspects have not been fully researched. Some sections may be incomplete or reflect inaccuracies present in initial sources. Please check the References at the bottom for further information and perform your own additional assessment. Please feel free to contribute by adding any missing information or sources you come across. 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."

About TrueUSD

"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."

The Reality

There was a vulnerability in the Compound Finance smart contract.

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

A critical vulnerability in the Compound Finance live smart contracts was patched, which could have been exploited for millions of dollars.

Key Event Timeline - Compound Finance Live Critical Vulnerability

Date	Event	Description
December 5th, 2021 11:11:15 PM MST	Original Audit Released	ChainSecurity releases an audit of the Compound Finance smart contract, which has information redacted for security. The audit contains no Critical-Severity Findings.
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.
March 21st, 2022	Updated Audit Released	ChainSecurity releases an updated audit with the redacted information included.

Technical Details

"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."

"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."

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?

"[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."

Ultimate Outcome

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

"The issue, with several millions at risk, has been mitigated by Compound and OpenZeppelin."

"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."

Total Amount Recovered

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

Ongoing Developments

TBD

Individual Prevention Policies

This case does not appear to have resulted in a loss to any individual.

Individuals can reduce their risk by ensuring that platforms they used are thoroughly audited by multiple platforms.

Avoid the use of smart contracts unless necessary. Minimize the level of exposure by removing or withdrawing assets whenever possible. Aim to choose smart contracts which have obtained third party security audits, preferably having been audited by at least three separate reputable firms. Pay attention to the audit reports, which smart contracts are covered, and whether the smart contract has been upgraded or modified since the report. Ensure that any administrative functions with the ability to remove funds from the smart contract are under the authority of a multi-signature wallet which is controlled by at least three separate and reputable entities.

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

Platform Prevention Policies

This case does not appear to have resulted in a loss to any platform.

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, there was no reason to have that function publicly accessible.

All aspects of any platform should undergo a regular validation/inspection by experts. This validation should include a security audit of any smart contracts, reporting any risks to the backing (of any customer assets, ensuring treasuries or minting functions are properly secured under the control of a multi-signature wallet, and finding any inadequacies in the level of training or integrity of the team. The recommended interval is twice prior to launch or significant system upgrade, once after 3 months, and every 6 months thereafter. It is recommended that the third party performing the inspection not be repeated within a 14 month period.

Losses can be minimized by structuring the smart contract such that most funds are secured in a proper multi-signature wallet.

All wallets, minting functions, and critical infrastructure should be implemented with a multi-signature requirement, with a recommended minimum of 3 signatures required. This means that making important changes or approving spending will require the keys held by at least 3 separate individuals within the organization to approve. The multi-signature should be implemented at the lowest layer possible, all key holders should have security training, and all key holders should be empowered and encouraged to exercise diligence.

An industry insurance fund can help ensure more effective validation and assist in the event of any breach.

Work with other industry platforms to set up a multi-signature wallet with private keys held separately by delegate signatories from seven prominent platforms and services within the industry. Establish requirements for contributions by all platforms and services, designed to be affordable for small platforms yet large enough to cover anticipated breach events. Any breach event can be brought forth by a member platform or a petition of 100 signatures for consideration by the delegate signatories. A vote of 4 or more delegate signatures is required to release any funds, which could partially or fully restore lost funds based on their assessment.

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

Regulatory Prevention Policies

It does not appear that any funds were lost in this case.

Risks can be reduced by ensuring more smart contract auditing is performed prior to a project launching.

All platforms should undergo published security and risk assessments by independent third parties. Two assessments are required at founding or major upgrade, one after 3 months, and one every 6 months thereafter. The third parties must not repeat within the past 14 months. A risk assessment needs to include what assets back customer deposits and the risk of default from any third parties being lent to. The security assessment must include ensuring a proper multi-signature wallet, and that all signatories are properly trained. Assessments must be performed on social media, databases, and DNS security.

An industry insurance fund can help ensure more effective validation and assist in the event of any breach.

Set up a multi-signature wallet with private keys held separately by delegate signatories from seven prominent platforms and services within the industry. Establish requirements for contributions by all platforms and services within the country, designed to be affordable for small platforms yet large enough to cover anticipated breach events. Any breach event can be brought forth by a member platform or a petition of 100 signatures for consideration by the delegate signatories. A vote of 4 or more delegate signatures is required to release any funds, which could partially or fully restore lost funds based on their assessment.

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