Rho Markets Incident
On July 19th, Rho Markets — a Compound V2 fork on Scroll — was involved in an incident that led to the creation of $7.5mil in bad debt. The root cause of the vulnerability was the misconfiguration of the oracle for ETH, i.e., setting the address to a wrong price feed, at initialization time, and not a bug in the code. The price mis-alignment was quickly exploited by an MEV bot that observed the opportunity.
Fortunately, lost funds were returned due to the quick and coordinated efforts between the protocol team and SEAL 911 (of which we are also part). That being said, the willingness of the MEV Bot operator behind the incident to co-operate with the protocol and return the funds significantly sped up the recovery.
One may also read Rho Markets’ official statement [tweet | blog] on the incident, which does a great job of explaining the circumstances that led to the loss of funds.
Technical Details
The misconfiguration
Quoting Rho Markets’ incident report:
This issue occurred due to the erroneous configuration of the ETH oracle price feed to the BTC price feed. Normally, such settings are validated before any changes are implemented. However, due to a human error in overseeing the deployment process, this validation check was missed in the case of the oracle price.
The on-chain misconfiguration of the PriceOracleV2 contract occurred in this transaction: https://scrollscan.com/tx/0x9d2388a0c449c6265b968d86f0f54e75a5b82e2b04176e35eefdff5f135547ec#eventlog
As can be seen from the emitted event, the transaction has the effect of erroneously setting the oracle for the underlying asset at address(0) to be the WBTC/USD oracle.
At the time of the transaction, the configuration for the rWBTC token ( 0x1d7.. ) had not been set inside the oracle contract:
This is also evident by the fact that no calls to the PirceOracleV2‘s setRTokenConfig function had been performed, prior to the oracle update on block 7580111 and after rWBTC ’s deployment on block 7579842
The problem with setting the oracle for the asset at address(0) is that, as stated before, this address represents the underlying token of rETH (ETH) [ configuration of rETH ]
Which is a notion inherited from Compound’s semantics:
Screenshot depicting the configuration of ETH in Compound’s UniswapAnchoredView contract — the second address in the tuple is the underlying address
The consequences of the misconfiguration
At this point we can note that no contract code was vulnerable or broken, since the setter of the price oracle functioned as intended.
However, this misconfiguration alone was enough to enable the arbitrage opportunity that an MEV bot exploited. Since all ETH collateral would be priced at the value of WBTC —a 20X increase in the actual value of ETH— this allowed the bot to borrow more funds than one should normally get when using ETH as collateral (which lead to the creation of bad debt).
The MEV bot performed multiple transaction like this one: https://scrollscan.com/tx/0x0a7b4c6542eb8f37de788c8848324c0ae002919148a4426903b0fb4149f88f05
As one may see, the bot mints ~84 rETH
But it successfully manages to borrow ~942 wstETH which is then swapped into ETH
The total amount of bad debt that was created by this method ended up being ~7.5 million.
Return of funds
The war room set up with the protocol team and SEAL 911 was quick in gathering information on the attack and the operator of the MEV bot. However, the bot operator acted in good will and contacted the protocol team for the return of funds:
https://etherscan.io/tx/0xab7bc87fca7df222000b870fbe55750c33b3ea0461a8ba8a8ddbe530a1934248
https://scrollscan.com/tx/0xd9c2e4f0364b13ada759f2dd56b65f5025e70cce4373e7c57ac31bf5226023e0
Hello RHO team, our MEV bot have profited from your price oracle misconfiguration. We understand that the funds belong to users and are willing to fully return. But first we would like you to admit that it was not an exploit or a hack, but a misconfiguration on your end. Also, please provide what are you going to do to prevent it from happening again.
Funds were successfully returned at: https://scrollscan.com/tx/0x15da6af0207d82d27ca20a542dae1b81580ca1cbfee7028c312229968e356446
Takeaways
The incident highlights the importance of rigorously reviewing deployment procedures. Even when there are no smart contract vulnerabilities, protocols must ensure that updates do not break any invariants posed by the protocol’s complex modules.
We’d like to thank Rho Markets for their quick action and transparency on the issue, as well as all the members of SEAL 911 who also participated in the war room with us.
