Youtube Video

Playing the video that you've selected below in an iframe

Neptune Mutual to Close Cover Marketplaces

5 min read
Neptune Mutual Final

After much deliberation and careful thought Neptune Mutual decided to close the cover marketplaces.

After much deliberation and careful thought Neptune Mutual decided to close the cover marketplaces. Below the reasons for the decision as well as what it means for the community.

The marketplaces will be closed using an emergency withdrawal process whereby the liquidity provided to cover pools by LPs will be returned to the wallet addresses from which the liquidity was supplied. In addition to protecting cover pool LPs, there will also be refunds to all cover policy purchasers with an existing and valid policy who have paid over 10 USD in policy fees in one transaction.

For veNPM holders, please fill out this form to receive a refund for your veNPM to NPM conversion penalty.

From the end of June there will no longer be NPM emission incentives for LPs i.e. Epoch 3 of the liquidity gauge emissions will be canceled.

Unused funds raised from financial backers will be returned to those backers; this includes DEX liquidity that has now been removed from SushiSwap and Uniswap. A small amount of liquidity on SushiSwap Arbitrum has been left to enable a minimum amount of NPM trading.

The protocol will be open sourced, and become a true public good. Enabling the community to fork the code developed by the Neptune Mutual team such that others might use the existing resources to further our mission to make the blockchain space better protected against smart contracts and other risks.

There are numerous factors that have led to this difficult decision, some of which are external factors which are uncontrollable or unforeseeable. A few factors summarized below:

CEX Listing#

“Given Neptune Mutual’s Tier 1 backers, why have you not listed on a top CEX?”

This is perhaps one of the most frequently asked questions. In short, the answer is that for a variety of reasons Neptune Mutual was not able to achieve the diverse set of performance metrics (community size and engagement, marketplace user activity, DEX 24 hour trading volume, TVL growth etc.) required to list on top tier CEX. The CEXs that are prepared to list NPM token do not have the depth of liquidity or breadth of user-base to offer good prospects for NPM tokenholders.

Growth Performance#

The above point invariably leads to the question

“Why has Neptune Mutual not achieved strong growth?”

It is tempting to take a shortcut to answer this question by pointing a finger at one specific factor, but the reality is that there are many contributing factors. A few summarized below:

The DeFiInsurance Narrative#

Since the outset of engaging with the community we have endeavored to highlight the need for DeFiInsurance; Neptune Mutual built a comprehensive dataset of on-chain hacks available, anywhere, and each week we highlight the many millions of dollars that are stolen as a result of smart contract hacks. Despite this, we have consistently been confronted by projects unwilling to spin up cover pools in our marketplace because of the sentiment that audits of their code are sufficient to persuade their community that their protocol is safe. Less than 0.3% of all digital assets are protected with some form of DeFiInsurance, and yet despite all the media reports of hacks, the conference discussions about the importance of governance or CEX proof-of-reserves, it continues to be the case that it is extremely difficult to get media attention to focus on the need for a fast and efficient means of mitigating smart contract risk.

A variety of approaches have been taken by different DeFiInsurance protocols to address this, from attending multiple conferences throughout the year and significant marketing spend, to the leaner approach that Neptune Mutual took (in part as a result of the bear market in 2023). What can be said is that no DeFiInsurance protocol has managed to achieve significant growth over the last 18 months, sadly the overall TVL of the sector has shrunk a lot.

Continue to Invest in Growth, or Refund?#

For all the reasons above, at this moment the best course of action is no longer to double-down on investing in growth, but rather to refund unused capital and close the marketplaces.

The consequences are very tough for the Neptune Mutual team who have spent the past 3 years of their time on the mission to facilitate  safer environments within DeFi.  The team has delivered products according to the roadmap and the fact that the protocol was never hacked, despite attempts being made on the darkweb, is testament to the expertise, passion and absolute focus on security.  The team survived the FTX and UST crisis unscathed, and believed that the continued growth in hacks would lead to growth in the demand for a good solution to mitigate these risks, but sadly, as can be seen right across the DeFiInsurance category, this is not yet in sight. So we would like to thank the team for all the dedication, skill and passion invested into the Neptune Mutual project since the outset.

What's Next?#

The team will open source the protocol, including blockchain indexing protocol (subgraph alternative), frontend, middleware, database, and backend code, to make it a true public good. This will allow anyone to fork the code and create covers by defining parameters and premium ranges, potentially leading to innovative covers and organic usage.

The Discord channel will be closed to reduce the risk of phishing and other types of cyber attack, any questions / queries will be responded to in the Telegram channel.

We want to take this final opportunity to thank you all for your support.

Disclaimer:#

Neptune Mutual will contact only its financial backers, with whom a signed agreement exists, in relation to next steps (i.e. holding NPM tokens does not qualify you for any form of refund). Contact will be made only from a neptunemutual.com domain email address so please check the source of any email you may receive very carefully. Please ignore any messages from any other email or social media accounts in relation to token/cash refunds.

By

Unfolding the Wormhole Exploit

7 min read
Exploit Analysis

Learn about the hack on Wormhole and how the team counter-exploited the attacker.

TL;DR#

On February 3, 2022, Wormhole was exploited for 120,000 ETH, worth approximately $326 million, making it one of the top 5 largest cryptocurrency heists of all time.

Vulnerability Assessment#

The root cause of the vulnerability is a lack of proper validation of all input accounts, allowing the attacker to exploit it by spoofing the guardian signature and minting 120,000 ETH on Solana.

The Exploit#

Step 1:

We attempted to analyze the attack transaction executed by the exploiter.

Step 2:

The attacker called the `complete_wrapped` function of the contract, which requires a valid VAA account, which the bridge would accept. This requirement was satisfied when the attacker called the `post_vaa` function on the main Wormhole bridge as viewed from this transaction.

Step 3:

The attacker managed to bypass the signature checks that the "post_vaa` function performs by providing a `SignatureSet`, which ultimately called the `verify_signatures` function on the main bridge.

Step 4:

The `verify_signatures` function is meant to take a set of signatures provided by the guardians and pack it into a `SignatureSet`. However, it doesn't perform actual verification by itself but delegates that operation to the Secp256k1 program.

Step 5:

A `solana_program::sysvar::instructions` mod is meant to be used with a sort of precompile on Solana. However, the version of `solana_program` on Wormhole didn't verify the address being used.

Step 6:

This means that anyone could create an account that stored the same data that the instructions `sysvar` would have stored and substitute that account for the instruction `sysvar` in the call to `verify_signatures` in order to effectively bypass the entire signature validation.

Step 7:

The attacker created their account prior to conducting the attack, which contained a single serialized instruction corresponding to a call to the Secp256k1 contract.

Step 8:

The fake `SignatureSet` allowed them to generate a valid VAA and trigger an unauthorized mint of 120,000 ETH to their own account.

Step 9:

Out of the stolen funds, 93,750 ETH were bridged back to Ethereum over the course of 3 transactions, while the remaining assets worth approximately 36k whETH were liquidated on Solana into USDC and SOL.

Aftermath#

Following the exploit, an on-chain message was sent to the hacker by the team behind Wormhole Bridge, offering them a white-hat bounty of $10 million for returning the stolen funds.

Jump Crypto, a wing of Jump Trading involved in the development of the Wormhole protocol, tweeted that they replaced the 120k ETH to make community members whole and support Wormhole.

On February 16, 2023, the team was made aware of the possibility of the retrieval of the stolen assets after a group of white-hat hackers reached out to them with a proof of concept for the possible recovery.

The counter-exploit was successful mostly because the access design of the admin multisig had a flaw that no one had noticed earlier. According to the team, the design pattern was adopted solely to protect user assets in the event of a prospective attack, such as the referenced exploit, and would have allowed the team to respond quickly to patch any such vulnerability.

The Counter Exploit#

The Oasis team announced in a blog post on February 21, 2023, that they had been given permission by the High Court of England and Wales to pursue all required actions to recover the assets linked to the wallet address used in the Wormhole Exploit.

Jump Crypto, with the support of the Oasis team, was able to successfully counter-exploit the Wormhole exploiter by utilizing an upgradeable proxy contract on the Oasis protocol to secure approximately $140 million worth of the earlier stolen funds.

The exploiter had continuously shuffled the stolen funds through various dApps on Ethereum and held funds in two of the Oasis vaults: a wstETH vault opened on January 23, 2023, and a rETH vault opened on February 11, 2023. Both of these vaults used the automation services offered by Oasis.

In between the aforementioned time frames, the exploiter used these vaults to borrow DAI and long ETH staking derivatives and drew a total of $78 million worth of DAI debt against $220 million worth of collateral.

The wstETH vault, ID: 30100, held $219 million in wstET, while the other rETH vault, ID: 30179, held $6 million in rETH. The counter-exploit used was able to recover all of the funds from both of these vaults.

Following are the details of the wallets involved in the counter-exploit:

  • Oasis Multisig: A 4 of 12 multisig that owns the Oasis proxy contracts
  • Holder: Address that held the recovered funds
  • Sender: Address responsible for executing the counter exploit
  • Jump1: Address labeled as Wormhole Deployer 1 that funded the `Sender` with DAI to repay the debt and recover the collateral
  • Jump2: Address labeled as Jump Trading that received the leftover DAI from the `Sender`

What Had Happened?#

The Exploiter added a stop-loss trigger to vault 30100, 9 minutes after opening the vault. This instantly led to a backdoor for the counter-exploit to be successful.

The AutomationBot contract is given access to the vault when a user adds an automation trigger to an Oasis vault, enabling it to purchase collateral or take on debt if and when the trigger is hit.

The first automated transaction was triggered on February 13, in which the vault owner took no additional action, while 14.41 million DAI debt and 7,547 wstETH collateral were automatically added to the vault.

The Automated vaults need the ability to act on behalf of the user. However, the Oasis automation contracts use an upgradeable proxy pattern, meaning the contract logic can be changed by the contract owner at any time. The owner of the Oasis automation contracts was a 4 of 12 Gnosis Safe, which we earlier referred to as Oasis Multisig.

The Holder made its first transaction on February 20, one day before the event of the counter-exploit.

On February 21, the Sender was added as an eligible signer to the Oasis Multisig for a total of 1 hour and 53 minutes. The Sender executed five transactions to facilitate the counter exploit, but was subsequently removed as a signer from the Oasis Multisig after the counter-exploit was successfully executed.

Each of these five transactions by the Sender played a key role in the counter-exploit, but the major recovery took place with the third transaction. In this transaction, the Sender upgraded the automation contract to a new proxy that allowed the Sender to move the collateral and debt from the vault with ID 30100 out of the exploiter's control.

A few of the below parameters enabled the counter-exploit to become successful:

  1. The Sender first updated the change delay to 0 with the ServiceRegistry using its privileges on the MultiSig, allowing them to instantly upgrade the proxy contract address.
  2. The Sender deployed two new contracts; let's refer to them as Authorizer, and Executor. These contracts tricked the protocol into acting as the Sender’s commands.
  3. The Sender updated the Oasis ServiceRegistry to call the Authorizer and Executor contracts in place of two key Oasis contracts with the ability to bypass the time delay.
  4. The AutomationExecutor proxy address was updated to Oasis Multisig, giving the Sender complete control of the vault with ID 30100.

In order for the counter-exploit to become successful, the Sender must close the vault with ID 30100 and migrate its position to a new vault that is controlled by the Multisig.

  1. The Oasis Multisig is called in place of the AutomationExecutor, granting them full control of the vault with ID 30100.
  2. The Authorizer is called, which tricks the protocol into thinking that the vault with ID 30100 can legally be closed by the Sender. The Authorizer successfully got the Sender past the verification steps.
  3. The Executor is called to create a new vault with ID 30231, migrate the collateral and debt from 30100 to 30231, and transfer ownership of the vault with ID 30231 to the Oasis Multisig.
  4. The result moved approximately 120,695.43 worth of wstETH collateral and 76.39 million of borrowed DAI from vault with ID 30100 to vault with ID 30231.
  5. The Authorizer called again to verify that the vault with ID 30100 was closed, and finally the Sender restored the proxy contracts back to their original addresses.

The exploiter mistakenly gave access to the vault with ID 30100 to an upgradeable proxy contract controlled by a Multisig. The Authorizer and Executor played critical roles in the process, but the counter-exploit would not have been possible without the full control provided by upgrading the AutomationExecutor proxy. The final executions by the Sender delivered 120.7k wstETH and 3.2k rETH to the Holder.

As viewed from this transaction dated March 9, 2023, the Oasis team removed the ability to upgrade any of the contracts associated with Oasis Automation by setting the authorized address to 0x0 instead of the Oasis Multisig.

Reference Source Rekt, Blockworks

By

Tags

Exploit Analysis Wormhole Jump Crypto Oasis Blockchain Hacks Decentralized Insurance Parametric Insurance

Related Posts

More Related Posts

Analysis of the Curio Exploit

Learn how Curio was exploited, which resulted in a loss of approximately $16 million.

Exploit Analysis

Understanding the UwU Lend Exploit

Learn how UwU Lend was exploited, which resulted in a loss of assets worth $23 million.

Exploit Analysis

How Was Steam Swap Exploited?

Learn how Steam Swap was exploited, resulting in a loss of assets worth approximately $105,000.

Exploit Analysis