On August 5, 2020, Beijing time, the Opyn ETH Put smart contract of the DeFi options platform Opyn was hacked, resulting in a loss of approximately US$370,000.

Opyn is a general options agreement, which was transformed into an insurance platform in February this year. It provides DeFi platforms with tradable ETH put options through oTokens, thereby anchoring the ETH market price and providing relative stability for the highly volatile DeFi market.

After learning that the Opyn platform was attacked, the PeckShield security team quickly located the key points of the problem:

The attacker found that the Opyn smart contract exercise (exercise) interface had some flaws in the processing of the received ETH, and its contract did not check the real-time transaction amount of the trader, so that the attacker could initiate a real transaction on himself After that, insert a fake transaction to deceive the seller's mortgaged digital assets, and then realize empty hands.

Simply put, because the exercise function exercise() in the Opyn ETH Put smart contract does not perform real-time verification of the trader's ETH. According to the business logic of the Opyn platform, the buyer of the put option transfers the corresponding value of ETH to the seller to obtain the digital assets mortgaged by the seller. The cunning attacker first initiates a disguised transaction to himself, and uses the reusable feature of this ETH to initiate a transfer to the seller's user again, thereby defrauding the seller of the mortgaged digital assets.

secondary title

Let me first talk about the business logic of the Opyn platform: when a user uses the Opyn contract to exercise, that is, to buy and sell futures (exercise), the buyer needs to transfer a corresponding amount of ETH or ERC20 Token to the seller, and then the contract will destroy the corresponding oToken of the buyer, and then The buyer will get the property that the seller has mortgaged.

image description

Figure 1. The list of vaults addresses passed in is looped in the exercise() function

image description

Figure 2. Reuse the ETH passed into the contract to obtain collateral assets

When the function handles ERC20 Token, like most DeFi projects, use transferFrom(), as shown in line 1882 of the code, to transfer money from msg.sender to address(this).

But when the asset processed by the function is ETH, the processing method is completely different. Because in Solidity, msg.value means the amount of ETH transferred to the contract by the caller of the contract when calling the payable interface, which is only a value, so in line 1879 of the contract code, check msg.value == amtUnderlyingToPay only ensures that the contract has indeed received the amtUnderlyingToPay amount of ETH, and will not have any impact on the value of msg.value.

But as mentioned above, the _exercise() function will be called cyclically in exercise(), which leads to the fact that although the contract actually only receives ETH once, it can be reused during the loop.

image description

Figure 3. Attack transaction analysis

In Figure 3, we show the attack process through the calling process displayed by the Bloxy browser. Since the attacker has consumed many orders, we will take one of the transactions as an example to show you the attack logic:

The PeckShield security team suggests that in Solidity, the contract can use a local variable msgValue to store the received ETH (ie the value of msg.value). In this way, by operating msgValue in the subsequent steps, it is possible to accurately mark how much ETH has been spent, thereby avoiding assets being reused. In addition, we can also use address(this).balance to check the contract balance to avoid the risk of msg.value being reused.