Pizza DeFi EOS Spiderman Hack Incident

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!

Pizza DeFi Homepage

On December 8, 2021, eCurve, a DAPP deployed on EOS, experienced a severe attack. The hacker, identified as itsspiderman, exploited a vulnerability in eCurve to mint an infinite number of TRIPOOL tokens and deposited them as collateral in the PIZZA platform, draining valuable assets. The attack resulted in losses estimated at $5 million worth of tokens. The way the EOS network works, it's possible for block producers to vote to freeze accounts or return funds. However, the hacker moved the funds to 1.37M different accounts, and threatened to send all the funds to normal accounts if a $3m bounty was not paid. Through negotiations, a $500k bounty was agreed upon, and the rest of the funds were returned.

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

About Pizza DeFi

"A Decentralized Financial Gateway" "EOS Based. Efficient, instant transaction, more diversified." "Decentralized Trading. No registration, no deposit/withdraw." "Trusted Transaction. On-chain, transparent and traceable." "PIZZA smart contract audit by SlowMist & PeckShield"

"eCurve was launched by the DAD DAO proposal number 64 as an Ethereum port of Curve. Ethereum uses unsigned parameters for this action and as a result does not require a positive value check on the EVM side."

The Reality

"The DAD DAO decided not to audit the code due to a lack of consensus on the DAO funds to be spent for eCurve. Previously the DAD DAO contracts were audited by Sentnl and no critical issues were found. The community debated many times whether to audit the remaining code but due to a lack of available funds and consensus, the DAO did not go ahead with the audit."

What Happened

On December 8, 2021, eCurve, a DAPP deployed on EOS, experienced a severe attack. The hacker, identified as itsspiderman, exploited a vulnerability in eCurve to mint an infinite number of TRIPOOL tokens and deposited them as collateral in the PIZZA platform, draining valuable assets. The attack resulted in losses estimated at $5 million worth of tokens.

Key Event Timeline - Pizza DeFi EOS Spiderman Hack Incident

Date	Event	Description
December 4th, 2021 8:50:00 PM MST
December 8th, 2021	Main Event	Expand this into a brief description of what happened and the impact. If multiple lines are necessary, add them here.
December 9th, 2021 3:17:00 AM MST	SlowMist Tweet	SlowMist publishes a tweet on the situation and notes they are actively analyzing.
December 9th, 2021 6:57:23 AM MST	U Today Article	U Today reports that the EOS DeFi platform Pizza was hacked, resulting in the theft of $5 million in users' funds. This hack marked the first such incident on the EOS blockchain. The attacker, known as itsspiderman, exploited eCurve to mint an unlimited amount of Tripool tokens, which were then used as collateral. These tokens enabled the hacker to open over-collateralized positions, drain valuable assets, and withdraw them to their own wallet. The platform is attempting to recover the stolen funds, and security experts from SlowMist Blockchain Ecosystem Security are actively analyzing the situation to assist in fund retrieval. However, the stolen funds are already in the hacker's private wallet, presenting a significant challenge for recovery compared to previous DeFi hacks like PolyChain.
December 9th, 2021 8:36:00 PM MST	Appreciation Tweet	The Pizza DeFi team tweets that they "[a]ppreciate everyone who offer[ed] help and care. Your supports make everything different at this very moment. The situation is still tough, the light is faint, but together we see the path to the future. Thank you."
December 12th, 2021 3:09:00 AM MST	Verbal Settlement Announced	The Pizza DeFi team tweets that they have reached a verbal settlement with the hacker for $500k in exchange for the 5,000 private keys where the funds are held.

Technical Details

This section includes specific detailed technical analysis of any security breaches which happened. What specific software vulnerabilities contributed to the problem and how were they exploited?

The exploit involved depositing stablecoins (USDC, DAI, and USDT) into the ecurve3pool1 contract, receiving TRIPOOL tokens, and then exploiting bugs in the staking and withdrawal mechanisms. The attacker repeatedly staked and withdrew these stablecoins until they managed to obtain a significant number of TRIPOOL tokens. These tokens were then used as collateral in the PIZZA application to borrow a variety of cryptocurrencies, totaling around $10 million.

The attack revealed vulnerabilities in the eCurve contract, such as the lack of positive balance checks and validity checks for assets, which allowed the attacker to pass negative amounts and exploit the system. Additionally, the absence of positive balance checks and non-positive balance assertions contributed to the contract's exploitation.

Ultimately, the hacker deposited 12 million TRIPOOL tokens as collateral in PIZZA, yielding a substantial loan, and created 1.4 million EOS accounts, incurring unrecoverable RAM costs.

"On December 8, 2021, eCurve, a DAPP deployed on EOS was attacked." "12/8, 8pm, hacker itsspiderman used exploit in eCurve to mint infinite Tripool tokens and deposit as collateral in PIZZA platform, drained all valuable assets." "The hacker attacked eCurve and minted infinite LP tokens called TRIPOOL. Beside using the TRIPOOL tokens to withdraw all liquidity in target eCurve pools, the hacker also collateralized them in PIZZA Lend, and borrowed all tokens with value." "PIZZA losses $5 millions worth of tokens. We are working with slowmist, BPs, and other projects to manage to retrieve." "By using a large number of Tripool tokens, the hacker was able to open over-collateralized positions and drain real valuable assets and withdraw them to his or her own wallet. The lost tokens are valued at $5 million."

"The eCurve hack revolved around not requiring a positive balance of stable coins to be passed to the ecurve3pool1 contract. This issue existed in tandem with only requiring that positive amounts trigger an inline action for a transfer of a stable coin." "The hack begins with the attacker depositing USDC/DAI/USDT to receive an initial TRIPOOL balance." "This TRIPOOL balance is then transferred back to the ecurve3pool1 contract which is immediately followed by a call to the withdrawimbl action. In this action, a negative amount is passed for 1 of the 3 stable coins which as stated previously does not trigger an associated inline transfer which would have failed."

"The attacker made a deposit of 3.66853 USDCs, 3.669928 DAIs, and 55.1576 USDTs to ecurve3pool1 and obtained 62.103274 TRIPOOL tokens. The attacker converted 46.205931 TRIPOOL tokens to 248 DAIs and 248 USDCs. Bugs that existed in the implementation of staking and withdrawal were exploited by the attacker."

"The attacker repeatedly staked and withdrew USDCs and DAIs and eventually staked 900,000 DAIs and 900,000 USDCs. The attacker withdrew 900,000 DAIs and 900,000 USDCs, obtained 28.22 million TRIPOOL tokens and cashed out the TRIPOOL tokens. The attacker cashed out 14.72 million TRIPOOL tokens to 20,000 USDCs, 1.05 million DAIs and 1.85 million USDTs. The attacker converted 1.50 million TRIPOOL tokens to 134,000 USNs in eCurve’s USN pool. The attacker staked 12 million TRIPOOL tokens to the Pizza application as collateral and borrowed 330,000 EOSs, 130,000 DFSs, 3,933 BOXs, 1655 YFCs, 35900 TAGs, 660,000 USDTs, 78.81 million TPTs, 454,000 KEYs, 10.55 million DAPPs, 3.5679 PBTCs, 4.61 million CHEXs, 1.24 million OGXs, 39.629223 ETHs, 0.4584 USNs, 1.99 million USDCs, 8.79 million IQs, 1.374 BTCs, 2.07 million USDBs, 520,000 OUSDs, 2346 BOXAIs, and 0.6914 PETHs. The total exploited assets were valued at around 10 million USDs."

"The stable coins appear to be rotated so as to not deplete the contract of one stable coin before the hack may be completed. The result of passing this negative amount allows the hacker to receive a return of TRIPOOL as well as the positive stable coins. The limit on how many stable coins that can be entered is dictated by the TRIPOOL amount." "[T]here is no positive balance check for the minamounts parameter. What we do see is a check to ensure that the asset exists in the tokeninfo2 table and that the symbol matches." "The hacker then repeats this process of depositing the received stable coins, receiving more TRIPOOL tokens, then using those TRIPOOL tokens to withdraw larger and larger amounts of stable coins until the contract is depleted of all stable coins."

"One validation check that would have saved the contract would have been the addition of a positive balance check as well as a validity check (as seen in the eosio.token smart contract)." "Another would have been to assert if a non-positive balance was sent."

"The hacker then deposited 12,000,000 TRIPOOL for collateral to pizza for a massive loan which yielded 331,044.7153 EOS as well as several other tokens. Some of these tokens were converted to EOS as well. The hacker created 1.4M EOS accounts. RAM used to create EOS accounts is not recoverable."

Total Amount Lost

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

Immediate Reactions

SlowMist Analysis Tweet

We are actively analyzing. The specific information is subject to the @PizzaProFi.

U Today reports that the EOS DeFi platform Pizza was hacked, resulting in the theft of $5 million in users' funds. This hack marked the first such incident on the EOS blockchain. The attacker, known as itsspiderman, exploited eCurve to mint an unlimited amount of Tripool tokens, which were then used as collateral. These tokens enabled the hacker to open over-collateralized positions, drain valuable assets, and withdraw them to their own wallet. The platform is attempting to recover the stolen funds, and security experts from SlowMist Blockchain Ecosystem Security are actively analyzing the situation to assist in fund retrieval. However, the stolen funds are already in the hacker's private wallet, presenting a significant challenge for recovery compared to previous DeFi hacks like PolyChain.

"We received the alert and immediately verified that a hack incident has just happened. The first reaction was to contact both the eCurve team and the producing block producers. Confirm the hack and find out the basic cause of it. Confirm the hacker accounts, especially the ones that store the stolen tokens. Contact with the top 21 BPs, host a zoom call that the BPs can join (so you can explain to them what happens, provide them with on-chain evidences and how you want them to help)."

"The token recovering is unprecedented tough, we are trying the best and will update with the community if there is any progress." "The classic way of dealing with hacking incidents since 2018 was to ask all 21 BPs to blacklist the target hacker accounts. If all 21 BPs ban the target accounts, the transactions from the target accounts will all be rejected. And the problem is it’s almost impossible to ask all 21 BPs to keep the black list."

"We took both approaches but made the second one our main direction, because as mentioned above, it’s almost impossible to get all 21 BPs to add certain accounts to a blacklist. From 9pm to 00:30, it took three and half hours to actually draft the proposal that could limit the target accounts’ actions. In order to make it happens, it requires 15/21 approvals from the producing BPs. All BPs were being extremely helpful, we spent one more hour to explain and review the ongoing situation and the proposal itself. At 01:47 am, eventually, we got the approvals from 15 block producers (check the image below for a detailed list)."

Ultimate Outcome

"However, the hacker created 1.37 millions EOS accounts over the past 4 and half hours and sent 98% of the stolen tokens to these accounts. In average each account got around $6~7. Also, as a revenge for the PIZZA team to call the BPs, the hacker airdropped many tokens to random accounts. So basically here was a “you call the cop and the robbers kill several hostage as a warning” situation."

"[W]ell, some accounts were not so random, “gaotiancheng ” for example, this account was created right before his huge airdrop, with suspicious initial EOS transaction and suspicious KYC info in both Huobi and Alipay. However, in the next day we managed to collect the list of the 1.37 millions hacker accounts, we didn’t include the “gaotiancheng” because 100% confirmed."

"12/11, continued to verify the target accounts, tested the proposal. Contact with BPs and provided them with review methods. Set target action time to 12/12 night. 12/11 Midnight, the hacker asked for $3 millions ransom and threat to send all stolen funds to normal users if BPs attempt to restrict his accounts."

"12/12, 2 am, fight or flight. Evaluated the cost of resource the hacker had to take to transfer all tokens. Decided to bring the plan forward. Set target action time to 12/12, 10 am. Contacted all 21 BPs. 12/12, 10:30 am, proposal voting started. 12/12, noon, hacker saw the proposal and threaten to send all tokens to normal accounts. 12/12. afternoon, negotiations. Between PIZZA and hack, and also among the BPs. 12/12, 4 pm, 15 approvals received. Hacker agree with the $500K ransom."

"Exchanged 500K DAI with itsspiderman's 1.37 millions accounts. We also asked for a temporary access to the active permissions of both "itsspiderma1" and "itsspiderman", in order to make clearing more efficient. We will return these two keys back to Mr.Spider when things settles."

"Under this circumstances, we snapshot the current prices of the target tokens, and will compensate the depositors with equivalent USDT tokens. Snapshot time: 12/15, 08:15pm, UTC+8. Thank you." "Regathering tokens from a millions accounts back to one account is 10x more difficult than sending them from one account to one million accounts. Damaging is always easier than building/fixing."

"12/23, all services on PIZZA Lend Resumed. PIZZA started to work with ENF to design a recovering framework to provide a more convenient and standardized process to resolve similar incidents in the future." "After this hack, PIZZA will only open a very limited list of collaterals. The truth is that we have too many collateral choices that really qualifies, and this is obviously not an excuse to set a lower standard."

"There is also a patch that introduces a lending cap to the PIZZA platform, it will filter out most of the unexpected extreme price movements or infinite inflated tokens like what’s in this eCurve hack. In the end, there will also be a new ENF working group: Recover+. PIZZA team will work with the EOS network foundation to design a crisis management framework to help EOS projects coping with hacking incidents. The phase one work is expected to be done by the end of April."

"We are minting a NFT series to honor this great recovering. The NFT is for all parties who help to get back the money. Including those who voluntarily return the lost tokens. Leave comment if you have any ideas or suggestions. Thank you!"

"Thanks everyone who help in this incident, without your kindly support PIZZA might have just been crashed and never be able to continue contribute like it was. We can’t thank you more enough, it’s only hard work and contribution to the community can repay the debts we owe you. Let’s together go for a better future."

Appreciate everyone who offer help and care. Your supports make everything different at this very moment. The situation is still tough, the light is faint, but together we see the path to the future. Thank you.

A bounty of $500,000 USD was paid for the discovery.

Total Amount Recovered

The total amount recovered has been estimated at $4,500,000 USD.

Ongoing Developments

TBD

Individual Prevention Policies

Individuals have a responsibility to review and research all smart contracts which they are planning to use. Minimizing the use of smart contracts and storing most funds offline can limit the potential for losses.

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.

Store the majority of funds offline. By offline, it means that the private key and/or seed phrase is exclusively held by you and not connected to any networked device. Examples of offline storage include paper wallets (seed phrase or key written down and deleted from all electronic media), hardware wallets, steel wallet devices, etc...

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

Platform Prevention Policies

The primary issue in this case was that the Pizza DeFi smart contract underwent an upgrade and introduced new code without any further audit being performed. Since any modification can introduce a vulnerability, it is recommended that an audit should have been performed in this case. Limiting the funds in the smart contract, or the minting ability of the smart contract through a multi-signature requirement would have prevented the losses. An industry insurance fund can help assess validators and in the event of a smart contract breach.

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.

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.

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

The primary issue in this case was that the Pizza DeFi smart contract underwent an upgrade and introduced new code without any further audit being performed. Since any modification can introduce a vulnerability, it is recommended that an audit should have been performed in this case. Limiting the funds in the smart contract, or the minting ability of the smart contract through a multi-signature requirement would have prevented the losses. An industry insurance fund can help assess validators and in the event of a smart contract breach.

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.

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.