Cover Protocol Hack

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!

Cover Protocol

Cover protocol is a market for insurance, allowing you to protect your assets on other platforms against loss.

Except that the protocol itself got hacked, and there was nobody to insure it. Luckily, the firm which had conducted the breach owned up to it and gave the money back.

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

About Cover Protocol

Cover is "A peer-to-peer coverage market - A platform where you can buy coverage on anything." "COVER Protocol allows DeFi users to protect against smart contract risk. It stabilizes the turbulent DeFi space by instilling confidence and trust between protocols and their users. At the core of Cover Protocol are the fungible cover tokens. Fungible cover tokens are created when a user deposits collateral into a Cover smart contract. Each Cover contract specifies the protocol to be covered (ie Curve), the preferred collateral (ie DAI), the amount to deposit, and then the expiration date of coverage."

"The decentralized finance (DeFi) insurance project Cover Protocol was hacked earlier Monday in an infinite printing scheme, causing the price of the COVER token to plunge. Hours later, Grap.Finance, a “white hat hacker” claimed responsibility for the attack via their Twitter account, saying all funds had been returned."

"A hacker has exploited a bug in the incentives smart contract of Cover Protocol. This has allowed the hacker to get away with 11,761 COVER tokens, worth $3.62 million at press time."

"COVER (formerly known as SAFE) fell ~90% when an infinite mint loophole was uncovered and exploited, causing the total supply of tokens to increase by 48 quadrillion percent, from 84,477 to 40,796,131,214,802,600,000."

"The attackers managed to exploit a bug in the Cover’s incentive contract called infinite mining bug’." "They successfully discovered a process that gave them COVER tokens as rewards. They then staked, unstaked, and restaked LP tokens in rapid succession." "Nansen, an analyst group focused on Ethereum wallets revealed that the exploiter managed to carry on his exploits for over 2 hours and all of the $2 million stolen funds were minted token."

"Banteg, Yearn Finance’s core developer, commented on Twitter, saying that they are investigating the issue. Yearn Finance entered into a merger with Cover protocol on Nov.28. Binance has halted trading and deposits of Cover Protocol as well."

"“The 4350 ETH that has been returned by the attacker will also be handled through a snapshot to the LP token holders. We are still investigating,” according to the project’s Twitter account." "After claiming responsibility for the hack, the attacker sent a message telling Cover Protocol to “take care of your own shit.”"

"The Cover protocol has now come up with a compensation plan to refurbish those who were impacted by the exploit a couple of days ago. The team behind the defi insurance protocol released a medium post informing traders that the refurbishment plans would be based on the snapshot of block 11541218 which is the block before the first exploit took place."

"We will use the snapshot to calculate each user’s ownership percentage of all outstanding COVER-ETH LP tokens and distribute the ETH proportionally. We have received a total of 4,441.8 (4,350 + 1 + 90.8) ETH. The final distribution will be the total amount of ETH returned by exploiters to the dev multi-sig."

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 - Cover Protocol Hack

Date	Event	Description
December 28th, 2020	Main Event	Expand this into a brief description of what happened and the impact. If multiple lines are necessary, add them here.
December 28th, 2020 6:08:00 AM MST	Tokens Reported Burned	Twitter user banteg reports that the "The biggest exploiter has burned the tokens after cashing out 4374 ether ($3.2 million)."
December 28th, 2020 6:41:01 AM MST	Funds Returned	Funds exploited are reportedly returned, with a comment to "Next time, take care of your own [stuff]".
December 28th, 2020 8:47:00 AM MST	CertiK Announces Exploit and Return	CertiK announced the exploit and that all funds were returned.
December 28th, 2020 5:10:37 PM MST	CertiK Publishes Incident Analysis	CertiK publishes an analysis of the incident by their "leading security engineers" on Twitter.

Technical Details

On December 28th, 2020, there was an attack on the Cover token, involving an infinite minting vulnerability. The attacker exploited this vulnerability by repeatedly staking, unstaking, and claiming through the project's contract, leading to the unlimited minting of coins and a collapse in Cover token prices. The attack involved various functions within the project's contracts, including deposit(), updatePool(), and _claimCoverRewards(). The vulnerability allowed the attacker to gain a significant number of COVER tokens. After the attack, Cover officials migrated the blacksmith contract to a secure version to prevent further exploitation. Several hackers took advantage of this vulnerability, with one making around $4.4 million. Grap.Finance, another attacker, returned the funds via its Twitter account. CertiK is a leading audit company that performs security audits and protects crypto assets, offering CertiKShield for loss reimbursement due to hacks or exploits.

Grap Finance Exploiting:

CertiK Technical Analysis

CertiK published a technical analysis.

The attacker staked the Balancer lp tokens to the Blacksmith.sol contract in Cover Protocol.

The deposit() function shown in Figure 1 is invoked in the process of staking.

By invoking the deposit function, the attacker staked BPT and received LP tokens via the cover protocol. In line 118, the contract loads and holds the pool data in the memory by a given LP token. Later, it updates the pool data by invoking updatePool function shown in line 121 in figure 2.

Please note that the pool data which is stored in line 118 of figure 1 is in the Memory location of smart contract whereas the pool data stored in line 75 of figure 2 is in Storage location of smart contract. The difference is: Memory in Solidity is a temporary place to store data whereas Storage holds data between function calls. The value of lpTotal in line 84 represents the total number of liquidity proof tokens deposited in the current contract. Since the value of lpTotal is small, the value of pool.accRewardsPerToken will increase through the formula on line 84, and the updated pool.accRewardsPerToken is stored in Storage, which will not affect the value stored in the Memory in this case.

Next, deposit() calls the _claimCoverRewards() function, as shown in line 318 in Figure 3. This specific contract minted COVER tokens with the amount of minedSinceLastUpdate for the function caller (msg.sender). The formula to calculate the number of COVER tokens that was going to be minted is shown in line 316 in Figure 3. It is controlled by the value of the three variables — — pool.accRewardsPerToken, CAL_MULTIPLIER and miner.rewardWriteoff. The value of pool.accRewardsPerToken is adopted from Memory rather than from Storage which is updated in the update() function.

We can also observe that the value of miner.rewardWriteoff is updated in line 130 in Figure 1, which occurs after invocation of the _claimCoverRewards() function shown in Figure 3. The updated miner.rewardWriteoff value should have been used to calculate the amount of COVER tokens that needs to be minted. However, the formula in line 316 in Figure 3 used the smaller miner.rewardWriteoff value that has not been updated, which as the result minted more COVER tokens than it should be.

After staking, the attacker calls the withdraw() function in the blacksmith.sol contract to retrieve the staked BPT, and get the minted COVER tokens as rewards.

By comparing the token balance table after the deposit() and the withdraw() execution, the attacker gained 704 COVER tokens.

The attacker profits by using this loophole, repeatedly executing the deposit and withdraw functions to infinitely mint tokens, and transfer the hacked tokens to their own address.

Total Amount Lost

The total amount lost has been estimated at $9,400,000 USD.

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?

"$COVER is exploited to the max."

"Extremely high weight and rewards per token. Something went terribly wrong in the Cover contract."

https://twitter.com/apedeveloper/status/1343529821054382081|Jan 3, 2023

https://web.archive.org/web/20201228121121/https://twitter.com/apedeveloper/status/1343529821054382081|Nov 3, 2023

https://twitter.com/apedeveloper/status/1343533660088246272|Nov 3, 2023

https://web.archive.org/web/20201228122625/https://twitter.com/apedeveloper/status/1343533660088246272|Nov 3, 2023

Twitter Reactions

first SAFE, then SAFE2, after that SAFE3, finally COVER, OH NO! IT'S NOT OVER YET! what's their next name?

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

The total amount recovered has been estimated at $3,696,000 USD.

Returning Funds Transaction:

Ongoing Developments

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

General Prevention Policies

The decentralized finance space is still new and developing.

It is essentially impossible to prove that a smart contract is secure. More secure storage of funds involve multi-signature offline storage.

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.