TL;DR#

On December 25, 2022, the Rubic protocol was compromised, resulting in a loss of over $1.4 million.

Introduction to Rubic#

Rubic is a cross-chain technology aggregator for users and dApps that aggregates various blockchains, different DEXs and bridges, and allows for the exchanging of a wide range of assets.

Vulnerability Assessment#

The root cause of the vulnerability is that the Rubic protocol incorrectly added USDC tokens to the Router whitelist, resulting in the theft of USDC tokens from the users authorized to the RubicProxy contract.

Steps#

Step 1:

Rubic is a DEX cross-chain aggregator, so users on their platform can swap tokens via a function call in the RubicProxy contract.

Step 2:

During this process, it will first determine whether or not the target Router of the necessary call passed in by the user is included in the protocol's whitelist.

Step 3:

The user-supplied target Router will be called only after the whitelist check, and the calling data will also be supplied by the user.

Step 4:

As USDC tokens were incorrectly added to the whitelist of the protocol, any user could arbitrarily call USDC tokens through the RubicProxy contract.

Step 5:

The perpetrator used this opportunity to call the USDC contract through a function call, in order to transfer the USDC tokens to their address from the users who had authorized to the RubicProxy contract.

Step 6:

In here, you can view one of the attack transactions carried out by the exploiter, in which USDC tokens from multiple users have been transferred to their addresses.

Step 7:

The attacker sent 1,100 ETH worth of the stolen funds to Tornado Cash.

Aftermath#

After the incident, Rubic issued a statement confirming the occurrence of the hack and requested users to revoke their access as soon as possible. The team will undertake audits with two independent agencies in the weeks to come, and approximately 49 affected users will be compensated for their loss.

The team further issued another statement to provide a brief summary of the incident.

Solution#

While performing smart contract audits can assist in identifying and addressing potential vulnerabilities, they are insufficient to fully prevent a contract from being hacked. Stringent tests should also be run in simulated scenarios to find any potential programming errors or weaknesses in order to guarantee the security and dependability of a smart contract to a greater extent. These tests ought to replicate a range of circumstances and situations that the contract might experience in the real world, including both anticipated and unforeseen circumstances.

We may not have prevented the occurrence of this hack, however, the impact or aftermath of this attack could have been significantly reduced if Rubic protocol had a dedicated cover pool in the Neptune Mutual marketplace. We offer coverage to users who have suffered a loss of funds or digital assets occurring as a result of smart contract vulnerabilities owing to our parametric policies.

Users who purchase our parametric cover policy do not need to provide loss evidence in order to receive payouts. Payouts can be claimed as soon as an incident like this is resolved through our governance system.

Neptune Mutual's security team would also have evaluated the platform for DNS and web-based security, frontend and backend security, intrusion detection and prevention, and other security considerations.

Reference Source Rubic