• Trading
• Liquidity pools
• Collateralised loans

Some simplified examples explained how protocols could be manipulated in each scenario. Here we will look at some exploits that have occurred, their methodology, implications and subsequent measures taken by the exploited protocols.

The price switch - Synthetix XAG incident

Everyone has bad days at work. On the 21^st of February 2020, Synthetix, an Ethereum based protocol that allows for synthetic asset trading (gold and silver) reported an anomaly in the pricing feed for silver. An engineer at Chainlink had released an update which led to the oracle looking up the price of gold instead of silver. This effectively meant that silver was being quoted at the same price as gold. With gold trading at around 1645 USD as opposed to silver trading at 17.5 USD, traders had a huge arbitrage opportunity available.

By selling sliver for the price of gold, whilst simultaneously buying silver at its usual price via another avenue, traders could lock in a hefty profit. Some traders did so, generating $36,000 of profit. This profit was made at the expense of SNX stakers and was fully reimbursed by Chainlink.

This type of oracle exploit falls under the ‘human error’ category. Most exploits which have occurred and have been labelled ‘oracle exploits’ are enabled due to protocols depending on one data source for their pricing. Sergey Nazarov, one of the Chainlink oracle co-founders stated that:

“If a DeFi protocol believes its’ oracle implementation is secure as it sources price data from multiple exchanges, the protocol is wrong. All it is doing, is making the attackers life a bit harder.”

It also serves to highlight why one centralised source for an oracle by a protocol is still vulnerable in some manner, irrespective of how ‘good’ that one oracle is. In the above oracle exploit, despite Synthetix using the best oracle available, the use of only one price feed was their downfall. Other more complicated attacks simply require more steps to highlight the ‘human error’ which is present, and still unknown.

The amount of profit that could be made in this scenario was limited by a variety of factors:

1. The available capital that a trader possessed and could deploy.
2. The speed with which the trader could complete their trades/transactions prior to the oracle error being fixed.
3. The available liquidity against which the exploit can be used, also limits potential profit.

These three factors are common across all oracle attacks and play a key role in determining how oracle attacks are carried out.

Before we move on to our next exploit, let us understand how attackers address each of the above factors.

Available capital, Solution: Flash Loans

You have discovered a one-time use arbitrage opportunity that guarantees you a 1% profit, or otherwise $1 of profit for every $100 you trade. The liquidity for your arbitrage is near limitless. The only cap on your profits is the amount of capital you can deploy. At what point does taking advantage of this arbitrage trade become worth your time? If you had $100,000 lying around, you could pick up a profit of $1000. With $1,000 in available capital, you will only be making a profit of $10. In many cases it is important to not only find a great opportunity, but to fully take advantage of it as well.

When an attacker finds an exploit, they are aware they can only use it once. Once an exploit is carried out once, bots will copy the attack method by inspecting the attacks’ transactions on the blockchain and replicate it themselves. To fully take advantage of the exploit the attacker has found, the more capital that can be used the better. This is enabled by the attacker using flashloans.

A flashloan is an ‘instant’ loan. The capital is only borrowed for the duration of a transaction. The receiver of the loan only receives the loan, if they prove they can return the loan in the same transaction. It is like someone showing their working out in a maths problem. A flashloan can also be propositioned as:

“I will lend you 10 million USD for 15 seconds to do with as you will, as long as you return to back to me my 10 million USD in full after those 15 seconds. If whatever you did during those 15 seconds with my money results in you not being able to pay me back, then you were never given a loan. But if you used my money to make a profit during those 15 seconds then you can keep the profit as long as you return my money to me.”

In the above example I am dYdX or another DeFi protocol that offers flashloans, and the loan receiver could be anyone. Loans accrue interest based on the time that passes since the loan was taken out. The more time a loan is outstanding, the more interest is due. In the case of a flashloan, the time that passes from when the loan is taken to the time that the loan is repaid is effectively zero, as it loaned and repaid within the same ‘block’. As no time passes, there is no interest charged for taking out a flash loan.

If their exploit is successful, it will be using an increased amount of capital sourced from the flashloan, maximising the profit for the attacker, and the losses for the protocol. Alternatively, if the attacker has miscalculated their operations and the exploit fails, the flashloan will simply be void. There is no risk for the receiver of the flash loan, only benefits are offered to the attacker. This has made flashloans the first step in most oracle attacks, and in some cases have enabled certain attacks.

Exploit Speed, Solution: Miner Bribes

On blockchains such as Ethereum transaction speed is determined by how much the creator of the transaction is willing to spend on sending their transaction. When an attacker is looking to exploit a protocol, the fee they pay for transaction priority is extremely high, to try and ensure that they do not get front run by arbitrage bots or miners. To put it simply, attackers pay very high fees to ensure that their attack goes through and happens near instantly. The amount of profit they stand to make, offsets these significantly increased transaction fees.

Available Liquidity, Solution: High TVL targets

As outlined above, flashloans are used by an attacker to increase their available capital. However, there must be adequate liquidity to absorb this large amount of capital and enable the attacker to extract profit. For the attacker to make profit, sellers and buyers at scale are required. This leads to protocols with significant amounts of liquidity being targets. A protocol with a small amount of liquidity is not as attractive as the profit is capped by the protocol's available liquidity, and not the maximum flash loan which the attacker can take advantage of.

Methodology of an oracle attack

Most oracle attacks follow the same steps. Firstly, they aim to identify where a protocol is sourcing their pricing data from. Once this has been found a method to impact the price that the protocol is using has to be formulated by the attacker. Once the price can be manipulated, the attacker looks to extract the maximum amount of profit from the exploit they have uncovered. The attack will commence with the taking out of a flash loan. The oracle price that the protocol uses will then be manipulated, with the attacker using part of the flashloan funds to enable the price manipulation. In many cases, the attacker will use flashloan funds to clear out all the buy or sell orders on a specific pair's orderbook. Once the price has been manipulated by the attacker, then the protocol is exploited based on the manipulated prices which it is using.  The attacker extracts their profits from the exploited protocol, resets any prices which had been manipulated, repays the flashloan and pockets their profits. The attackers’ profits are taken directly from the protocols liquidity which is usually provided by users of the protocol via staking, making these attacks extremely damaging.

The bZx attack

The bZx protocol was exploited in February 2020, and the methodology of the attack follows the steps laid out above. The attacker identified a flaw in the price feed that bZx was using and incurring 620,000 USD of losses onto the protocol to extract 370,000 USD of profit for themselves.

The attackers addresses and contracts were new, and had never interacted with bZx, or any other DeFi protocols. All the attackers contracts, and the address used to carry out the attach were funded by Tornado Cash, shortly before the attack. The attacker has clearly attempted to stay anonymous and hide their identity.

The attack structure was the following:

1. A flashloan of 10,000 ETH is taken from dYdX by the attacker
2. 5,500 ETH is sent to Compound, and is used as collateral to borrow 112 BTC. This is 140% overcollateralization in USD, (5,500 ETH = 1,430,000 USD, 112 BTC = 1,009,000 USD). It is the same as a bank requiring a 100 USD collateral to borrow 70 USD. 4,500 ETH from the flashloan remain available.
3. 1,300 ETH is sent to bZx and is used as collateral to open a 5x short position on BTC. 3,200 ETH from the flashloan remain available.
   • bZx converts 5637 ETH to 51 BTC via Uniswap (5x leverage order), clearing out the orderbook on Uniswap and decreasing the price of ETH on Uniswap due to the huge sell volume.
4. With Uniswap offering the wrong price for ETH/BTC, due to the actions carried out in step 3, the attacker now sells 112BTC for 6,871 ETH on Uniswap. The attacker is taking advantage of the price manipulation they have caused in step 3.a. This can be observed from the ratio of ETH to BTC in transactions 2 and 4.
5. The attacker now repays the whole balance of the flashloan. They have 3,200 ETH from the flashloan which was never used, along with the 6,871 ETH which they recovered in step 4. 10,000 ETH are returned to dYdX fully paying off the flashloan, and thus enabling the whole transaction. You will notice that the attacker had 10,071 ETH (3,200 ETH + 6,871 ETH) available to repay the flash loan. The attacker was left with 71 ETH after repaying the flashloan. The attacker has also been left with a debt of 112 BTC due to Compound. Compound is also holding 5,500 ETH as collateral for the 112 BTC which it loaned the attacker. On the day of the attack this was an additional profit of around 400,000 USD.
   • +5,500 ETH as collateral in Compound (+1,430,000 USD)
   • -112 BTC debt owed to Compound (-1,009,000 USD)
6. Lastly the attacker has to repay their 112 BTC loan from Compound to release the 5,500 ETH which is kept as collateral. This is done buy buying BTC on the open market, repaying some of the owed debt to release some of the Ethereum being kept as collateral. The released Ethereum is then sold for more BTC, which is used to continue repaying the BTC debt, until the BTC debt is settled. The attacker's profit stems from the fact that if 11.2 BTC is repaid (10% of debt, 100,900 USD), that frees up 550 ETH (10% of collateral, 143,000USD). The USD value difference is the attackers additional profit, and is what allows them to repay their loan as long as enough funds for a first payment are available.

 

We have examined two separate real-life oracle exploits which occurred within the same month. The level of sophistication between each oracle exploit is drastically different. Most oracle exploits which have occurred are extremely similar in their methodology. In the bZx attack, dYdX and Compound were used to enable the attacker to have enough capital available to make a significant profit. The exploit in this case was the interaction between bZx and Uniswap cause by the huge sell order made by the attacker. An interesting fact is that this was the second attempt by the attacker to take advantage of this exploit. In their first attack they accidentally attempted to pay a ridiculously high gas fee due a typo in their code which caused their attack to fail. This is an example of the speed of execution having unintended circumstances. In another attempted oracle exploit, the attacker lost 40 ETH which was intended for the attacks gas fees without the attack occurring due to a coding error. In the bZx attack the attacker also left profit on the table which was taken advantage of by arbitrage bots. This occurred as the attacker did not make sure to reset the prices on Uniswap which were manipulated in step 3a of their attack. Even the attackers aren’t perfect.

Once a certain methodology of attack has been found, it becomes easier for protocols to protect against these attacks. Indeed, once a new method of exploit surfaces, it is necessary that all protocols stress test their smart contracts for vulnerabilities to the new attack methods.