Oracle Manipulation Attacks¶

Protocols sometimes require information from outside the blockchain to function correctly. Oracles supply that off-chain information, and are frequently smart contracts themselves.

The vulnerability appears where a protocol relying on an oracle executes actions automatically on an incorrect data feed. An oracle carrying deprecated or malicious content affects every process connected to it, and manipulated feeds cause damage ranging from unwarranted liquidations to malicious arbitrage trades.

Spot Price Manipulation¶

The classic on-chain price oracle vulnerability is trusting the spot price of a decentralized exchange.

A smart contract determines the price of an asset, for instance when a user deposits ETH into the system, and consults the corresponding Uniswap pool for price discovery. An attacker takes out a flash loan and drains one side of that pool. With no diversity of data sources, the protocol's internal price follows directly, to 100 times the original value for instance. The attacker then captures the difference, through an arbitrage trade on the newly created price gap or by taking an advantageous position in the system.

The problems are two-fold:

1. Using a single price feed source smart contract allows for easy on-chain manipulation using flash loans.
2. Despite a notable anomaly, the smart contracts consuming the price information continue to operate on the manipulated data.

The Visor Hack is a concrete example. The following code fetches the price feed directly from Uniswap on deposit:

1
2
3

// @audit the price is read from the pool inside the current transaction
uint160 sqrtPrice = TickMath.getSqrtRatioAtTick(currentTick());
uint256 price = FullMath.mulDiv(uint256(sqrtPrice).mul(uint256(sqrtPrice)), PRECISION, 2**(96 * 2));

currentTick() reads the current price tick straight from a Uniswap pool:

1
2
3
4

// @return tick Uniswap pool's current price tick
function currentTick() public view returns (int24 tick) {
    (, tick, , , , , ) = pool.slot0();
}

The price data comes from an on-chain dependency and is determined within the current transaction context, so the spot price is manipulable in that same transaction:

1. An attacker can take out a flash loan on the incoming asset A, and on the relevant Uniswap pool, swap asset A for asset B with a large volume.
2. The trade increases the price of asset B through demand and reduces the cost of asset A through supply.
3. When asset B is deposited into the above function, its price is still pumped up by the flash loan.
4. Asset B consequently gives the attacker an over-proportional amount of shares.
5. Withdrawing those shares returns equal parts of assets A and B from the pool.
6. Repeating the process drains the vulnerable pool of all funds.
7. The proceeds of the withdrawal repay the flash loan.

Off-chain Infrastructure¶

A data feed transporting off-chain information into a smart contract requires traditional software to run. From sensor hardware or manual entry through to authenticated APIs submitting data on-chain, a plethora of software is typically involved.

That surface admits attacks on access control, cryptographic implementation, transport, and database security, among others. Software providing oracle services therefore has to be hardened and to follow security best practices such as the OWASP Secure Coding Practices. The requirement is strictest for oracles without a community-driven dispute phase, where a compromise propagates directly into dependent applications.

1
2
3
4
5

Shayan Eskandari, Mehdi Salehi, Wanyun Catherine Gu, and Jeremy Clark. 2021.
SoK: oracles from the ground truth to market manipulation.
Proceedings of the 3rd ACM Conference on Advances in Financial Technologies.
Association for Computing Machinery, New York, NY, USA, 127-141.
DOI:https://doi.org/10.1145/3479722.3480994

The Synthetix sKRW incident is an off-chain component malfunction that reached an on-chain feed. Synthetix aggregates multiple related price feeds to price its derivatives accurately and surfaces the aggregate through a smart contract on-chain. One feed reported the Korean Won at roughly 1000 times its real value, and the aggregation did not suppress the outlier, so the on-chain price was reported far too high. An arbitrage bot exploited the gap and earned a profit of over 1B USD. On-chain aggregation and price reporting worked exactly as designed. The failure sat entirely off-chain. samczsun covers the incident and other price oracle failures in an article on the Paradigm blog.

Centralized Oracles and Trust¶

Projects also implement centralized oracles, where an onlyOwner modifier protects the update method and users trust the operator to submit correct data on time. Depending on the size and structure of the system, that concentration of trust incentivizes the authorized parties to submit malicious data and abuse their position of power.

Centralized systems carry the additional inherent risk of compromised private keys.

Decentralized Oracle Security¶

Decentralized oracles diversify the group of data collectors to the point where disrupting a quorum becomes infeasible for an attacker. The remaining security considerations stem from how participants are incentivized and which misbehavior goes unpunished. Participants providing valid data are rewarded economically, and maximizing profit pushes them toward the cheapest version of the service they can supply.

Freeloading¶

Freeloading is the simplest way to save work and maximize profit. A node reads another oracle or off-chain component such as an API and copies the values without validation. An oracle providing weather data expects its providers to measure temperature and wind speed at a specific location, while the incentive points toward pulling a public weather API and surfacing that instead. Beyond the data source centralization, freeloading at scale degrades correctness, most visibly when sampling rates diverge: the on-chain oracle expects a sample every 10 minutes while freeloading nodes relay an API updated once an hour.

In decentralized oracle data marketplaces, freeloading amplifies a price race to the bottom, since a simple lookup undercuts proper data provisioning and its computational overhead. With less competition in the cheaper price ranges, a handful of freeloading nodes take over a data feed. A commit-reveal scheme prevents freeloading for more complex feeds by stopping participants from peeking at each other's data. Simpler data provisioning calls for consistency checks that punish nodes copying from well-known public services, which disincentivizes the data collectors driving centralization.

Mirroring¶

Mirroring is a flavor of Sybil attack and goes hand in hand with freeloading. Misbehaving nodes save work by reading from a centralized data source, optionally at a reduced sampling rate. One node performs the read and replicates the values across other participants, who mirror the data. A single read then multiplies the reward by the number of participants. As the mirroring group grows, the weight concentrated on one data point deteriorates error correction. The same outcome arises accidentally when a large, uninformed part of a community settles on a single data source.

A commit-reveal scheme does not mitigate purposeful mirroring, because it does not cover private data transfers between Sybil nodes. That lack of transparency makes mirroring hard to detect in practice.

Mitigations¶

The most accessible answer to the oracle problem is a decentralized oracle:

• Tellor is an oracle that provides censorship-resistant data secured by economic incentives, ensuring anyone can provide data anytime and be checked by everyone.
• Chainlink is the largest decentralized oracle provider, and the Chainlink network can be leveraged to bring decentralized data on-chain.
• Witnet leverages state-of-the-art cryptographic and economic incentives to provide smart contracts with off-chain data.

Taking the median of multiple oracles raises security further, since attacking several oracles at once is harder and more expensive, and the contract still receives data when one oracle or API call fails.

A time-weighted average price feed is the other standard solution, averaging the price over several periods and multiple sources. It blunts oracle manipulation and reduces exposure to frontrunning, because an order executed immediately before has less impact on the reported price. The property does not hold for low-liquidity assets, which stay cheap to manipulate even over prolonged periods. Uniswap v2 provides a sliding window example.