XToken Function Access Control Exploit

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.

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!

xToken

xToken stored user funds in a particularly complex smart contract hot wallet. Through missing checks, an attacker was able to drain the wallet. xToken plans to compensate users, and retire the contract, which was already breached once in May.

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

About XToken

xToken is "a decentralized passive investing protocol," "a project which automates staking and liquidity strategies and wraps them into ERC-20 tokens." "xToken offers eight tokens, such as xSNXa and xBNTa, that offer exposure to returns from DeFi projects. They come in the form of Ethereum-based tokens that are wrapped around certain DeFi tokens, such as SNX and BNT. They give you some of the same benefits as the underlying token, such as staking rewards, but without having to leave the Ethereum ecosystem."

"On 29 August at 04:43 UTC, a vulnerability in our xSNX contract was exploited. We estimate the loss to holders at $4.5 million."

"That the attacker was able to call the callFunction function was the source of the vulnerability. This function should only have been callable from dydx’s SoloMargin flashloan contract that we had integrated to improve fund performance on rebalances. An erroneous require statement allowed the function to be publicly callable." "We mistakenly used require(sender==address(this) when we should have used require(msg.sender==soloMarginAddress)."

"Flash loan of 25,000 ETH from dydx. Borrow of ~1m SNX from a combination of Aave V1 and V2. Swap of 6.8k ETH to 519k SNX on Bancor. (Attacker now holds ~1.5m SNX.) Swap of 1.5m SNX on Kyber for ~6.5m USDC, lowering SNX price considerably. Swap of ~6.5m USDC for ~6.5m sUSD on Curve. Transfer of ~2m sUSD to xSNXAdmin contract (this is the contract that holds the assets managed by xSNX), with the intention of repaying the contract’s sUSD debt in order to unlock SNX. Call of the callFunction function on xSNXAdmin contract, burning outstanding sUSD debt and swapping ~614k SNX for ~811k sUSD debt at artificially depressed price." "Swap of ~811k sUSD for ~811k USDC, which remains in the contract." "The attacker then reverses all actions, swapping back to ETH and repaying loans. The source of the value extraction was that the attacker used xSNX assets to pressure SNX price and create profitable external arbitrage opportunities."

"Through the comments, we can know that [callFunction] is used to flash loan and then to return the debt. This function will first convert the loaned USDC into sUSD, the amount is the loanAmount (1) passed in by the attacker. Burn sUSD liabilities. Convert the SNX in the contract to sUSD, the swap amount is the snxAmount passed in by the attacker (about 614,240). Swap through Kyber/Uniswap/SUSHI/Curve, where slippage has been generated in the fourth step above. The 614,240 SNX should theoretically be exchanged for 6,756,640 sUSD. But the slippage was not checked, only 808,433 sUSD was swapped. After that, sUSD is converted into 811,078 USDC to return the debt. The loanAmount passed in before is 1. So the final check usdcBalance> loanAmount + 2 is 811,078> 1 + 2 is established and bypassed the check."

"We are incredibly disappointed in ourselves and deeply sorry to our community." "At this time, we believe it best to sunset our xSNX product offering. The current xSNX implementation is by far our most complicated product, with complex dependencies and significant surface area for vulnerabilities. More info later in the post about how users will be able to unwind their positions."

"We will no longer be staking SNX from the xSNX contract. We’re pushing a contract upgrade early this week that will allow us to swap all of the assets in the contract into ETH to allow for maximum value at redemption. There is currently a large quantity of USDC in the contract that is not counting towards NAV so we encourage you to wait to redeem until we’ve made this update. We will post in the #announcements channel in our Discord once this is complete."

"Once we’ve swapped the USDC for ETH, xSNX‘s sole holding will be ETH. You may redeem your xSNX for ETH at any time. However, we would note that starting in October, SNX from Synthetix staking rewards will begin to vest on our contract. As this SNX vests, we will swap it for more ETH. We do not have early access to SNX staking rewards so, put simply, the longer you wait to redeem, the more ETH you will receive."

"We are working this week to write accurate snapshot scripts to properly calculate investor losses. If you redeemed post-exploit, you will still receive compensation. We will need a few days to work out the details of this script and ensure accuracy."

"To compensate xSNX holders for losses from the August exploit, we’ve deployed an rXTK contract and funded it with XTK. As a reminder, we are a small project with a very limited treasury, so we’re forced to be creative with compensation plans. We are a dedicated team still very much focused on our goal of building a decentralized asset management stack, and we want to give our community an opportunity to recoup full value."

"We’ve funded the rXTK contract with ~4.04m XTK — a value derived by applying the same ratio of USD losses to XTK as we used for the previous exploit. We know that to some members of our community this resolution may leave something to be desired. Rest assured that we’ll be continuing to build, working to drive as much value as possible to the xToken ecosystem." "We understand that this is not an optimal resolution for all. We’re working to do the best we can with the resources at our disposal."

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 - xToken Function Access Control Exploit

Date	Event	Description
August 29th, 2021	Main Event	Expand this into a brief description of what happened and the impact. If multiple lines are necessary, add them here.

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?

Total Amount Lost

The total amount lost has been estimated at $4,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?

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?

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.