Deus Finance (DEI Stablecoin) Burn 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' section 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.

DEI Stablecoin

About Deus Finance

"Deus Finance. Universal access to institutional-grade blockchain derivatives. Providing the framework for optimistic on-chain digital derivatives. Capital efficiency, cross-margin between exchanges and market makers, in addition to instant settlement, enables DEUS to offer an unparalleled alternative to TradFi."

"DEUS Finance is building an infrastructure layer for peer-to-peer, on-chain derivatives. DEUS v3 utilizes bilateral agreements, meaning both parties lock collateral into a trade, with every trade isolated, and settlements automated."

"DEUS connects traders and counterparties directly. Instead of the common LP-centric models, where liquidity providers take on the systemic risk, DEUS isolates risk per trade between the two parties. DEUS is currently primarily (majority of the liquidity) on the Fantom network, however, DEUS v3 can and will be deployed on multiple chains."

"The DEUS ecosystem has two tokens, $DEUS and $xDEUS, and an algorithmic stablecoin, $DEI." "Users interacting with this software do so entirely at their own risk"

DEI is "The global settlement currency of DEUS's Decentralized FIX" "Traders using DEI will enjoy better fee structures while trading derivatives on DEUS v3."

"DEI is an fractional reserve stablecoin, forked and inspired by frax.finance and can be used as a unit of account for derivative-based trading on protocols built on the DEUS infrastructure layer. Traders, Protocols and Market Makers utilizing and offering trading via DEUS v3 using $DEI as stablecoin will enjoy better Fee Structures, than when using $USDC."

"DEI has a 100% minting ratio and 9% seignorage. 100% USDC is required to mint $DEI (ie. $1 USDC is required to mint 1 $DEI). On mint, 9% is used to buy back $DEUS and deposited into the DEI redemption contract. On redemption, 9% is transferred out of the redemption contract. This figure adjusts constantly and can be viewed in the minter stats."

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 - Deus Finance (DEI Stablecoin) Burn Vulnerability

Date	Event	Description
Apr 10th, 2023	DEI Token Smart Contract Upgraded	The DEI token smart contract is updated on the BSC network.
May 5th, 2023 11:52:45 AM MDT	Exploit on Arbitrum	The exploit occured on the arbitrum chain.
May 5th, 2023 11:53:35 AM MDT	Exploit on Binance Smart Chain	The exploit occured on the Binance smart chain. This is reportedly by a white hacker. They reportedly paid a fee of 2.14321709105314 BNB.
May 5th, 2023 12:35:00 PM MDT	Hippo Potato Sounds the Alarm	The Twitter user Hippo Potato sounds the alarm on Twitter.
May 5th, 2023 12:47:00 PM MDT	AdamB Posts About Exploit	Twitter AdamB spreads the word further that there is free money to be made due to a "basic implementation error". The arbitrum transaction is provided.
May 5th, 2023 12:53:35 PM MDT	Exploit on Ethereum	The exploit occurred on the ethereum chain, which results in a transfer of 62,287.333509816711554912 DEI tokens to an exploiter.
May 5th, 2023 3:03:00 PM MDT	ProtoSec Publishes Analysis	0xProtosec publishes an analysis of the exploit on Twitter.
May 5th, 2023 3:53:00 PM MDT	Zellic Publishes Analysis	Zellic publishes a more detailed analysis of the exploit.
May 5th, 2023 4:32:00 PM MDT	Acknowledgement By DeusDAO Team	The DeusDAO team acknowledges the attack on Twitter and requests that users hold off on interacting with their smart contract for the time being. TBD expand and move to other sections.
May 5th, 2023 4:52:29 PM MDT	BSC Tokens Transfered	The exploited tokens are transferred to a different wallet address. This is reportedly by a white hacker.
May 5th, 2023 5:18:00 PM MDT	Peckshield Reports A Pubic Burn	Blockchain researchers at Peckshield report a "pubic" burn vulnerability and note the total losses at $1.3m in BSC alone. They note that the BSC funds were front-run by a white hacker and that the ARB/ETH deployments are also affected.
May 5th, 2023 5:31:00 PM MDT	PeckShield Reports Arbitrum Losses	Peckshield reports on losses exceeding $5m on the Arbitrum network, along with the related transaction.
May 5th, 2023 8:14:12 PM MDT	BSC Tokens Transfered	The BSC DEI is transferred again from the second wallet address to another wallet address.
May 5th, 2023 9:24:00 PM MDT	MetaSleuth Publishes Analysis	MetaSleuth publishes an analysis on Twitter, reporting that the tokens have been traced to Binance and TornadoCash.
May 6th, 2023 12:47:00 PM MDT	Rekt Publishes Article	Rekt publishes an article on the exploit.

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?

Exploiter address on Arbiscan:

"A simple implementation error was introduced into the DEI token contract, in an upgrade last month. The burnFrom function was misconfigured, with the ‘_allowances’ parameters ‘msgSender’ and ‘account’ written into the contract in the wrong order.

This created a public (or pubic, according to Peckshield) burn vulnerability, which an attacker is then able to manipulate and gain control of DEI holders’ approvals and transfer assets directly to their own address.

The mis-ordered parameters allow the attacker to set a large token approval for any DEI holder’s address. Then, by burning 0 tokens from the address, the approval is updated to the attacker’s address, who can drain the holder’s funds."

ProtoSec Analysis

0xProtosec was one of the first to publish a technical analysis of the exploit.

Problem: currentAllowance should be = _allowances[account][_msgSender()].

Process: I can approve max value to `account` and call this function with 0 as burn amount.

Result: 0 tokens are burnt and I am approved `currentAllowance` amount of account's tokens. I transfer them all

Zellic Analysis

Zellic published a more detailed analysis, attributing the problem to the burnFrom function.

First, there is a large approval. It's not important now, so we will get back to it later.

Instead, the crux of the issue lies in the burnFrom function:

At a first glance, the burnFrom function looks fine. But don't let your eyes deceive you—there's a critical issue lingering here.

In ERC20, allowances are mapped as _allowances[owner][spender]. But here, the it reads from _allowances[attacker][victim]. The order is flipped!

With the flipped ordering, the attacker is able to approve the victim but then use their own approval to burn victim's tokens. But it doesn't end just at the burn function...

The remaining approval (allowance - amount) is written back to [victim][attacker].

This is why the attacker did a burnFrom(victim, 0).

This resets the allowance to the corrupted value!

What's left is to just call transferFrom, and steal all of the victim's balance. And that's exactly what the attacker did.

This bug is so simple, yet so easy to make.

MetaSleuth Analysis

Technical details on tracing some of the funds were completed by MetaSleuth.

1) On Arb, the exploiter made a profit of over $5M. The initial funds was obtained from TC on BSC. The exploiter swapped most of the profits for 2529 ETH. Besides, they bridged 10k USDC to BSC via @MultichainOrg. Then the exploiter swapped all USDC for ETH and bridged it to ETH.

2) On BSC, the total profit amounts to around 1.3 million USD. Exploiter 4 obtained the initial funds from Binance. All the profits were transferred to exploiter 6 (0xdf61), then converted into DAI and remained at this address.

3) On ETH, the total profit is approximately 135,000 USD. The exploiter swapped all the profits for Ether but has not made the transfer yet.

Total Amount Lost

"According to BlockSec’s MetaSleuth, the losses were approximately $5M on Arbitrum, $1.3M on BSC and $135k on Ethereum." "Token holders lost a total of ~$6.5M on Arbitrum, BSC and Etherum, and the DEI stablecoin depegged over 80%."

PeckShield reported the loss at $1.3m on the BSC chain and exceeding $5m on the Arbitrum chain.

Ethereum exploiter address: 0x189cf534de3097c08b6beaf6eb2b9179dab122d1

Arbitrum exploiter address: 0x189cf534de3097c08b6beaf6eb2b9179dab122d1

Binance (BSC) white hack exploiter transaction: 0xde2c8718a9efd8db0eaf9d8141089a22a89bca7d1415d04c05ba107dc1a190c3 and address 0x08e80ecb146dc0b835cf3d6c48da97556998f599.

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

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?

"An official update mentions a recovery plan for users who lost out in the exploit, and Deus have reached out to the attacker on-chain.

But given the account was originally funded via Tornado Cash on BSC, it’s not looking good."

"Luckily, the exploit on BSC was frontrun, and an on-chain message to the Deus Deployer shows the intent to return the funds. Other whitehats also sprang into action, and over $600k in USDC has so far been returned to a recovery multisig."

"For all white hackers that were able to rescue funds during the DEI exploit from today 05/05/2023 We are confirming 0x7f5ae1dc8d2b5d599409c57978d21cf596d37996 As a DEUS team owned multisig on Arbitrum. Please get in touch with us if you have not already."

Total Amount Recovered

The total amount recovered is unknown.

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?

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

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.

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

Regulatory Prevention Policies

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.

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