Unraveling DeFi

Spreek is a researcher with broad experience in DeFi, particularly in areas of governance, threat detection, and on-chain analysis.

Spreek presented a deep-dive into the Platypus Finance hack during an internal Spearbit Seminar. Platypus Finance is an AMM protocol on Avalanche, and is primarily designed for exchanging stablecoins.

This article is a written breakdown of Spreek’s seminar delivered at Spearbit where he delved into a deep-dive into the Platypus Finance exploit.

Spreek is an experienced researcher with expertise in the DeFi space, particularly in areas of:

• governance,

• threat detection

• on-chain analysis.

Spearbit is a decentralized and industry-leading blockchain security services firm pairing protocols with top security researchers with deep subject matter expertise to identify vulnerabilities in an ever-evolving landscape.

This article is not meant to be a complete replacement of Spreek’s seminar and instead as supplementary material to support deeper understanding. We highly recommend watching the video seminar as well:

Spreek’s Seminar: https://youtu.be/oIw6DG75-z4

Context

In 2022, Platypus Finance fell victim to an exploiter attack, leading to a substantial loss of funds. This event served as a stark reminder of the necessity of robust security protocols within DeFi projects. An exploiter attack typically involves one or more individuals manipulating vulnerabilities in the smart contract code.

In this instance, the goal was to drain funds or otherwise harm the protocol and its users. The attack on Platypus Finance was particularly complex, involving a series of intricate steps and manipulations of the protocol's contracts.

Following the attack, the team behind Platypus Finance and the wider DeFi community worked collaboratively to determine the cause of the attack, mitigate the losses, and prevent similar future attacks. This is where the speaker's expertise in risk, governance, threat detection, and on-chain sleuthing proved invaluable.

Exploit Background

In February 2023, Platypus Finance introduced a new stable coin, USP, which shares similarities with how Curve USD is intended to function. Backed by the stable assets in the stable swap pool, the total supply of USP reached 3.25 million the day before the attack.

Funding and Initial Attack

The attack occurred on February 16, 2023. The attacker began by funding his wallet through FixedFloat, a tactic often used after the Tornado Cash sanctions. Attackers frequently utilize various funding sources, such as Fixed Float, ChangeNow, or different multi-chain or cross-chain bridges.

After multiple rounds of funding through Fixed Float, the attacker proceeded to deploy his first attack contract roughly 25 minutes later, which ultimately contributed to his downfall. The attacker named the attack function hello().

Further Attacks and Errors

Unfortunately, this initial attack was successful, and ~ 8 million USD in stable coins were drained from the protocol. However, due to an oversight in the attacker's contract, no withdrawal function was implemented, leaving the stable coins stuck in the contract indefinitely.

Recognizing the issue, the attacker tried again ~ 15 minutes later by deploying a second attack contract.

Once again, he called the "hello" function. However, this attempt was plagued by a different error where the proceeds were sent to Aave reserves rather than to his wallet.

Undeterred, the attacker made another attempt about 10-15 minutes later. This time, he deployed a third attack contract. This attempt was successful, and the attacker was able to withdraw about 250,000 USD and 14,000 AVAX.

Root Cause Analysis

Diving deeper into the technical aspects, it's important to note the root cause of the attack. As reported by @danielvf on Twitter, the solvency check was situated before the funds were withdrawn and before the user's balance was updated. This occurred due to a vulnerability in the emergencyWithdraw function of the MasterPlatypusV4 contract.

This function lets users remove their LP tokens from any pool without claiming rewards, and only verifies user solvency via the PlatypusTreasure.isSolvent method.

This solvency check just ensures the user's debt doesn't exceed their USP borrow limit. So, a user is solvent if they have enough collateral to cover their debt. But there's a flaw - using emergencyWithdraw, a user can extract all collateral LP tokens without repaying the borrowed USP, thereby causing protocol debt.

Consequently, the attacker could take out a large amount of debt, withdraw their collateral, and repeat the process.

Aftermath

Detection

The third attack became public knowledge approximately 40 minutes after it had been conducted. Spreek admitted he was slightly slow in noticing the attack, given his focus isn't primarily on AVAX. By the point of Spreek’s discovery, the series of events leading up to and including the attack were being widely discussed across online communities.

Actions Taken Immediately After the Attack

Following the third attack, there was approximately an hour's delay before Tether froze the USDC that was trapped in the first attack contract. This preventive measure was taken just in case the attacker found a way to extract the funds, even though the attack contract had a bug that prevented withdrawal.

Public Identification and Initial Recovery Steps

Seven to eight hours after the freeze, the attack was publicly identified and called out on Twitter by Zach_xbt. Roughly 12 hours after that, the Platypus team was able to upgrade their proxy and successfully recover the USDC that had been seized and trapped in the contract.

Arrest of the Attacker

In a somewhat rare occurrence in the DeFi hack landscape, about a week after the attack, the attacker was arrested in France. This was considered an unusually positive outcome as it's not often that funds are recovered and attackers are apprehended in such cases.

Identification of the Attacker

Curiosity might lead one to question how the attacker was eventually identified. As previously mentioned, the attacker's significant mistake was funding their wallet through three separate transactions from Fixed Float. This pattern significantly reduced his anonymity because the three suspiciously sized transactions could be traced back to their original deposit source. Compounding his error, the attacker used an address that had previously interacted with a Know Your Customer (KYC) account, as well as the DNS. This sequence of errors ultimately led to his identification and arrest by French police.

Recovery of the Stolen USDC

An important part of the aftermath was the recovery of the 2.3 million USDC from the original attack contract. Once the proxy contract for Platypus Finance was upgraded, a fake flash loan callback was utilized since the attacker had approved the pool contract to spend the funds. Thus, the contract was merely upgraded to transfer from the attacker contract back to Platypus Finance - thereby facilitating the recovery of the stolen funds.

You can view the decompiled proxy contract below:

Takeaways

Drawing from the case study, we can pinpoint three critical takeaways:

1. Functions like "emergencyWithdraw", which aren't often called upon, need meticulous testing to prevent errors like solvency checks being mispositioned.

2. After an exploit, it's essential to actively seek help from the public and the security community. Collective efforts can help mitigate the effects of the attack.

3. While attackers can be cunning, they're not infallible. The attacker in this case made multiple mistakes.

Best Practices

From these, we can suggest best practices for projects you're auditing, working with, or developing. These practices span across three stages: before the attack, during the attack, and post-attack.

Before an Attack

• Establish an internal notification system for relevant activities that could signify an attack, such as large Total Value Locked (TVL) changes, multi-stage transactions, or new governance votes. The faster you can identify an issue, the more effectively you can respond.

• Verify all contracts on Etherscan. This step, while seeming counterintuitive, doesn't deter a determined attacker but can aid researchers in understanding your project. It's also helpful to include your project name and contact info in all verified contracts to speed up response times.

• Ensure time zone coverage so that there's always someone on hand when an attack occurs. This tactic can be critical as attackers often strike when they believe the development team is unavailable.

• Have someone on call who can respond quickly to emerging threats. This can be facilitated by having community mods with direct contact to the developers.

During an Attack

When an attack is underway, knowing how to identify it, understand it, and respond to it is crucial. Here are some steps to take when you suspect an attack:

Identify Suspicious Activities

1. User Funding and Wallet History: One significant indicator of a suspicious activity is how the user funded their wallet an d their transaction history. If it's a newly minted account funded by suspicious sources such as tornado, change now, fixed float, or a cross-chain bridge, it's likely to be involved in malicious activities. Conversely, an old account with a multitude of transactions and interactions with a centralized exchange is generally less suspicious.

2. Deployed Contracts: If the user has deployed a contract, it's crucial to examine it. Look at the bytecode and the call data to see if it refers to any of your contracts. Check if they are using flash loans, as attackers commonly use them. Also, note the complexity of the contract. A long and complex contract generally raises more red flags compared to simpler ones.

3. Green Flags: If the decompiled code or bytecode contains references to block native's base, it could be an MEV bot, which is typically less harmful. If the EOA (Externally Owned Account) starts with '0x000', it's likely to be MEV as well. Although there might be exceptions, these are generally considered good signs.

Understanding Suspicious Transactions

Once a suspicious transaction is identified, the next step is to understand what's happening. Here's how you can do that:

1. Transaction Analysis: Openchain.xyz is a useful tool that decodes transactions and provides a clear overview of value changes. When a contract shows large negative values, and the suspected attacker's contract shows significantly large positive values, it's usually a sign that something has gone wrong.

2. Uneconomic Activity Patterns: Watch for patterns of uneconomic activity, particularly when routed through user-created contracts. For instance, if you see a user depositing tiny amounts like 0.1 USDC through a bridge via a user contract, it's likely to be an attacker testing a potential exploit in production. It's rare for real users to conduct such small transactions.

By being vigilant and alert to these signs, you can identify attacks swiftly and take necessary actions to mitigate them.

After Attack Confirmation

When an attack is confirmed, your response is crucial in mitigating the impact and securing your system for the future. Here's a detailed guide on what actions to take post-attack:

Establish a War Room

As a first step, set up a dedicated war-room. Gather key people such as developers, auditors, and security researchers to collaborate and respond effectively to the crisis. This can streamline communication and decision-making during a high-stress situation, making it much more effective than trying to coordinate through direct messages or scattered channels.

Limit Future Damage

Once you've assembled your team, your immediate priority should be to limit further damage. Depending on your governance structure and power, this could involve pausing contracts, halting trading or lending operations. This measure is aimed at ensuring that the current issue doesn't escalate further.

Communicate with the Public

Timely and clear communication with your community is crucial. Make a public statement outlining the situation as soon as possible, including any necessary action items for users. For instance, if your governance token has been manipulated, advise users not to purchase it. If there's a risk of deposit theft, warn users against making further deposits. Engaging with your community can not only protect them but also potentially aid in marshaling resources to thwart the attacker, hinder money laundering, and potentially even apprehend the attacker.

Reach Out for Support

It might be beneficial to reach out to affected parties or offer a bounty for assistance. This can sometimes yield positive results as we've seen in various historical cases. There's little downside to this approach and it can potentially contribute to resolving the situation.

Contacting third parties who can impede the attacker's efforts to launder stolen funds could also be beneficial. This could include exchanges, wallet services, or other platforms where the attacker may try to move or exchange the stolen assets.

Conduct a Root Cause Analysis

While there might be an instinctive desire to immediately understand how the attack happened, it's essential to first focus on mitigating the ongoing impact. Once immediate action items are addressed, carry out a detailed root cause analysis to understand how the exploit was carried out. This will help you identify:

1. Whether your other products or contracts are vulnerable to similar exploits.

2. If other projects in the market are vulnerable to the same exploit.

Understanding the root cause can help prevent similar attacks in the future and improve your overall security posture.

Consider Future Actions

Based on the root cause analysis and the current situation, you may need to evaluate whether you need to completely restart certain aspects of your project.

For instance, if the attacker has possession of a significant amount of your project's tokens (such as governance tokens or LP tokens), you might need to consider creating a snapshot of the token holders before the attack and reissuing the token. Alternatively, if your project has sufficient governance powers, you may be able to exclude just the attacker. However, these decisions need to be made on a case-by-case basis, considering the specifics of your project and the nature of the attack.

The response to an attack is a crucial phase and can significantly influence the future trajectory of your project. It's important to approach it with care, clear communication, and thoughtful decision-making.

Questions

Q1: How do you typically get alerted or notified about suspicious activity like the one with Avalanche?

A1: I often get alerts for specific suspicious activities. However, for the Avalanche incident, I didn't get a notification as I don't spend much time on it. Usually, I learn about these incidents through channels like Lobster DAO on Telegram. My primary focus is on deployed contracts, as attackers often deploy contracts at some point. Catching these early can sometimes allow us to alert the project's developers and halt the attack.

Q2: How do you think these attacks will evolve in the future?

A2: We might see more instances where attackers' plans are preemptively executed by someone else, thus neutralizing their attack. Also, attackers might get better at minimizing the response time between revealing their plans on-chain and executing the attack. Despite the challenges, there's still a lot we can do while attackers are making mistakes. For instance, a white hat system capable of generalized front-running could be useful, although there are legal concerns to consider.

Q3: What tools or resources would you recommend for someone wanting to investigate these issues on their own?

A3: EtherScan is an invaluable tool and is widely used by on-chain investigators. Other advanced tooling like OpenChain or Tenderly can also be helpful. Getting accustomed to the intricacies of different on-chain block explorers and APIs is crucial. It helps to develop a sense for distinguishing between regular and suspicious transactions.

Q4: How did the Platypus team manage to recover the funds?

A4: The attacker's contract was giving approval to the Platypus pool contract (an upgradeable proxy) to spend its USDC. The Platypus team upgraded this contract to redirect the funds from the attacker's contract back to themselves. This was possible because the attacker had already approved the spending.

Q5: Will all the lost funds be recovered?

A5: Potentially, the frozen USDT can be reissued and recovered, but the exact status is unknown. It is anticipated that most of the funds will eventually be recovered, reducing the overall loss for the Platypus Finance team.

Looking for a Security Review?

Please contact us below via our submission form:

https://airtable.com/shrkxrtMKYJkLaXhT

You may also reach out to us via our Twitter:

https://twitter.com/SpearbitDAO[:](https://twitter.com/SpearbitDAO:)

For a brief overview of what Spearbit is and what we have to offer please see: https://twitter.com/SpearbitDAO/status/1656786350601846787?s=20