Highlights from Twitter Space: How to Prevent DeFi Oracle Attack
Experts in DeFi have discussed oracle-related risks and their mitigation strategies.
$403 million in 41 separate attacks; according to Chainalysis, this is the loss due to oracle manipulation in 2022.
In Feb, EigenPhi organized a Twitter Space discussing how to prevent Oracle attacks with industry experts, including:
@pmcgoohanCrypto, founder of ZeroMEV.
@yajinzhou, co-founder of @BlockSecTeam.
@KaihuaQIN and @lzhou1110: two highly influential DeFi security researchers at
0xpotato from @SlowMist_Team.
@jayantkrish, the core contributor of @PythNetwork.
Here are some of the highlights of this invaluable discourse. For the sake of clarity, We summarized the discussion.
Q1: Which oracle-related exploit has impressed you the most since the start of DeFi?
0xpotato @SlowMist_Team: This is regarding the liquidation event that occurred in 2020 for Compound. They used a single source price feed from Coinbase for their DAI token, liquidating nearly $19 million. This event emphasizes the importance of having multiple sources and Oracle to prevent such incidents.
Yixin @EigenPhi: I was first introduced to the concept of Oracle attacks through Kaihua and Liyi's paper written in 2021. They studied how attackers used flash loans to manipulate AMM Oracle's price, ultimately attacking the lending protocol bZx. This event became quite famous then, and I was impressed by their systematic approach and cleverness. More recently, the Helio arbitrage also caught my attention as it demonstrated a quick reflection on taking advantage of Helio lending protocols' inability to update aBNBc's market price. The entire arbitrage process was completed within an hour due to the token aBNBc being attacked. It requires extensive background knowledge and a brilliant perception of DeFi systems, which is why this event also left a lasting impression on me.
Jayant Krishnamurthy @PythNetwork contributor: I believe numerous other occurrences or issues involving Oracles may not necessarily be considered exploits but highlight concerns with their usage. For instance, an incident involving the Solend whale on Solana last autumn where an individual had deposited 300 million in Sol and borrowed against it. However, this amount of collateral was too significant for the protocol to liquidate reasonably. So as the position got close to liquidation, everybody freaked out because it would leave the protocol underwater. So that was probably one of the more interesting Oracle-related problems in the past year.
@Kaihua QIN: I would like to mention an Oracle manipulation attack I recently studied. It's on the MonoX platform. The MonoX protocol smart contract vulnerabilities have 40 implementations of access control. The attacker empties the liquidity of the Mono Swap, and then he can deposit a little bit more xtoken and try to manipulate the price by multiple swaps. And this attack is impressive because the price Oracle part is fine, but you can use other vulnerabilities like access control to realize the Oracle manipulation attack.
Q2: By analyzing the existing exploits, how many types of oracle attacks would you like to categorize?
Yajin (Andy) Zhou @Blocksec: I would like to put oracle attacks into two types: on-chain Oracle manipulation and off-chain Oracle issues. On-chain Oracle issues can be caused by the manipulation of on-chain data, which can be achieved through flash loans, vulnerabilities in the protocol, lack of access control, or private key leaks. Off-chain Oracle issues arise when price information is refreshed from data not on the blockchain and can be tampered with or untrustworthy. Synthetix and Luna's protocols are examples of off-chain Oracle issues.
Jayant Krishnamurthy @PythNetwork contributor: Just for completeness, I think we should add some operational security breach, like someone gets some sets of privileged Oracle keys. In many cases, I think they can basically publish whatever data they want. I can't think of a salient example of when this happened, but it's an attack factor.
Liyi Zhou: I want to approach this problem from a different angle. I have written an SoK studying DeFi attacks. And in that work, I'm trying to categorize different types of attacks based on which system layer they are attacking. So in the paper, I have like five different layers: the network layer, consensus layer, contract layer, protocol layer, and also auxiliary services.
At the network layer, attackers can congest the mempool, delay price oracle updates, or create a react attack. On the smart contract layer, vulnerabilities can arise from not verifying the authenticity of deployed contracts or coding errors. Protocol layer attacks involve on-chain price oracle manipulations and composability attacks. Auxiliary service attacks include stealing private keys. The on-chain/off-chain price oracle and hybrid price oracle mechanisms can be attacked from different system layers.
@Kaihua QIN: So what's your definition of a price oracle attack or oracle manipulation attack? That's a question for every speaker.
Liyi Zhou: Price Oracle manipulation attacks can be defined as attacks that involve manipulating the price of one protocol that another protocol relies on. Without this manipulation, the attack would not be possible. Therefore, this definition can be used to identify and classify such attacks.
But I don't want to define what is an attack or what is not. It's important to note that different people may have varying opinions on what constitutes an attack versus an arbitrage opportunity. Therefore, when reporting on Price Oracle manipulation events, it may be helpful to provide additional context and explanations to help people understand.
@pmcgoohanCrypto @zeromev: Regarding the question of Oracle exploits, the one that caught my attention the most is the AAVE attack.
The AAVE attack represents a new type of attack vector involving high-volume manipulation without exploiting any particular vulnerability in the code. It highlights the unintended outcomes that can arise from using the protocol as intended with high volume. The lack of regulation in the DeFi market is also a problem. The liquidations during the AAVE attack only happened when there was an arbitrage opportunity between on-chain and off-chain exchanges, suggesting that searchers doing liquidations are playing a meta-game. This game wasn't originally intended, revealing a weakness in game theory.
Yixin @EigenPhi: Oracle attacks in DeFi can result from design flaws or vulnerabilities or reflect market prices that attackers can exploit. Oracle attacks can be classified into design defects, liquidity manipulation, and token issuance mechanism exploitation. Risk events should be viewed from a broader perspective using a theoretical framework like the "Tokenomic Trilemma." The risk often exists between two protocols when there is a severe information bias, leading to different evaluations of tokens and possible exploits.
Q3: How to mitigate oracle-related risks? How to design an Oracle attack resist system that could help to build a healthy DeFi system?
Yajin (Andy) Zhou @Blocksec: DeFi protocols using price oracles should implement proactive risk control and isolation mechanisms. Isolation is a fundamental security mechanism that has been talked about for years in system security. Unfortunately, deFi protocols lack isolation or sandboxing mechanisms, and introducing isolation can reduce security consequences. Another means is implementing a corrective approach to monitoring the whole market, such as comparing prices in different DEXes or sources, to avoid security incidents related to price oracles. To defend against price oracle attacks, we need to implement these mechanisms.
Liyi Zhou: The lack of a confidence score in most price oracle updates is an issue. It would indicate how confident we can be that liquidity will be available to trade at a specific price after a certain time. Additionally, proactive defense mechanisms are necessary to address the possibility of mistakes and improve DeFi security. For example, a system is being developed to monitor the mempool and protect DeFi projects before an attack is executed. These measures would strengthen DeFi security overall.
Yajin (Andy) Zhou @Blocksec: A more proactive approach to monitoring the mempool is an excellent idea.
@pmcgoohanCrypto @zeromev: A confidence score is necessary to provide more reliable updates for price oracles. BonqDAO attack is an example of issues with the oracle and the protocol, where a stake of only $127 could publish price information. The protocol had also used multiple Oracle feeds but averaged them, leading to the Tellor price dragging down the better price feeds. There must be a cultural shift towards an expensive coding mindset and a focus on security in DeFi protocols rather than just exotic formulas.
The metaphor that comes to mind is scuba diving. Scuba diving seems simple initially, but training teaches you what could go wrong, such as running out of air or getting nitrogen narcosis. Similarly, in DeFi, the focus should be on protecting user funds, and a cultural shift toward this mindset is necessary. The primary focus of the work should be on protecting user funds.
Jayant Krishnamurthy @PythNetwork contributor: There are many ways an Oracle can malfunction, and I categorize them into three main problems: incorrect prices due to market manipulation, mistakes or collusion by price reporters, and oracles going offline for an extended period. There isn't a single solution that can prevent all these problems, so a combination of defense measures is required to guard against them. In addition, different techniques are needed to address each concern. A holistic approach to strengthen the security of DeFi protocols by using multiple strategies to address the issues that can arise with oracles.
@pmcgoohanCrypto @zeromev: The complexity of the DeFi space makes it challenging to find a single solution for problems related to oracles, and the composability of new financial primitives compounds the risks. This means protocols must take a more defensive approach to security and understand that their code will be part of a long chain of protocols with unknown effects. In addition to reading relevant material and implementing defensive measures, protocols must be vigilant and use monitoring tools. The enormity of the power of executing transactions brings an enormous responsibility and requires a more defensive mindset than traditional finance.
Jayant Krishnamurthy @PythNetwork contributor: To ensure the reliability of oracles, it is necessary to source prices from various exchanges, both on and off-chain, to make it harder for attackers to manipulate them. Trustworthy reporters and robust data aggregation are also needed to combine reports that outliers can't influence. Using a median rather than an average and measuring the dispersion between quotes can help defend protocols against abnormal market conditions. High-frequency and low-latency price updates are required to deal with attacks like high-frequency trading. Decentralized infrastructure is also essential to ensure that price updates are always available. Finally, auditing the op stack of oracle is necessary to identify any single important keys that can upgrade the program.
@pmcgoohanCrypto @zeromev: I recommend users move to audited protocols on first come, first serve L2 to address issues with oracles. Trustworthy oracle providers like Chainlink face a natural lag working with Ethereum L1, which is expensive and congested. By operating in an environment where transactions are cheaper and higher frequency, manipulation and bribery can be avoided. Ethereum layer 2 is where this kind of transacting should occur, and L1 should just be used as a rollup. Moving to L2 will also help the oracle update problem as oracles will be able to update more quickly. I urge people to move to L2 for more appropriate transacting.
Jayant Krishnamurthy @PythNetwork contributor: The Pyth network oracle on Solana, which has 2000-3000 effective TPS, has experienced issues with lending transactions during congested times, despite having ample transaction space. Recently, Solana added priority fee pricing, exacerbating the issue when people spam trades hoping to get a lucrative liquidation after an oracle update. When the whole chain is used up, the problem becomes a self-fulfilling prophecy. Therefore, adding chain space may not solve the problem of the oracle's inability to update.
@pmcgoohanCrypto @zeromev: A first-come, first-serve L2 system could solve the problem of spamming transactions to manipulate the Oracle. In such a system, transactions are hidden, and no public mempool prevents frontrunning or back running. I believe such transactions should be done on L2 and suggest using an encrypted mempool for pre-trade privacy. Even if 1st come, 1st serve L2 systems have built-in arbitrage, the benefits outweigh the disadvantages.
The above summary does not fully reflect the guests' insightful opinions. Click here to listen to the full recording. And please stay tuned for more!
Follow us via these to dig more hidden wisdom of DeFi: