Multi-chain security vulnerability
OptimismPBC x Wintermute
Last weekend, an attacker was able to perform quite an ingenious attack on Optimism. They breached some Optimism addresses that were compatible with various Gnosis Safe multisig. The baffling thing here was that these addresses weren't deployed yet, on Ethereum.
So, how did that happen?
Allow me to take you back to the past for a moment. Let's go to May 2022.
Now, in May, the Optimism Foundation engaged Wintermute for liquidity provisioning services. This was before the OP token launch. Wintermute was to provide a smooth experience for users acquiring the $op tokens.
To carry out this task, a temporary grant of 20 million OP tokens went to Wintermute. This was from the Foundation’s Partner Fund.
Now, Wintermute provided an address to receive the borrowed tokens. The Optimism Foundation sent two separate test transactions. This was a test transaction which Wintermute confirmed. After Wintermute confirmed the transaction, the Optimism Foundation sent the remaining tokens.
Unknown to them, Wintermute had made a costly mistake.
Wintermute had provided an address for an Ethereum (L1) multisig. This address wasn't deployed to Optimism (L2) yet and so, they could not access these tokens.
When this issue became known, they began a recovery operation. The goal was to deploy the L1 multisig contract to the same address on L2. But unfortunately, the attacker was there before them. The attacker was able to deploy the multisig to L2 before the recovery process was over.
The attacker set up the address with different initialization parameters. This single act enabled them to take control of the 20 million OP tokens and to sell about 1m OP.
It is important to note that this incident was not because of any vulnerability in Optimism. Nor was it because of any vulnerability in Gnosis safe. It was because of some (reasonable) security assumptions made in an old version of Gnosis Safe. This was long before multi-chain became very popular.
So, on Older versions of the Gnosis Safe factory, anyone could deploy contracts, via non EIP-155 tx. This made it possible to replay these transactions on chains other than Ethereum.
This means that the same factory could deploy the same address to every chain. And that's exactly what happened to Optimism.
But it was unfortunate that at that this older factory contract was being used, the Gnosis Safe UI was using a separate function. It was using the function createProxy which created multisigs via CREATE instead of CREATE2.
Unlike CREATE2, the code used to create the contract doesn't define the address of a contract. The address is only based on the nonce of the creator’s address. This made it possible for the attacker to deploy the old Safe factory to Optimism. And then, begin to trigger the createProxy function. The attacker did this many times to create the multisigs on L2 that were not owned by them.
Not every address on Ethereum can also be accessible on other EVM-based chains. It is an assumption that almost everybody makes. This doesn't apply to all smart contract accounts but it is true for non-contract accounts.
Misunderstandings such as these can have serious real-world consequences. In the Optimism x Wintermute case, it resulted in the loss of funds. The attacker was a step ahead and deployed the multisig before they could.
This isn't the first time something like this has happened, and it won't be the last.
Yes, it is an unfortunate event but it is one of the growing pains of a multi-chain world. It highlights the importance of designing better systems for multi-chain users. It also highlights how deterministic deployment is critical, especially for contract wallets.
Currently, addresses generated by the factory use the factory's nonce. So, it starts at zero when deployed. An attacker only needs to trigger createProxy many times until they get to their target. The factory address is the same on Ethereum and Optimism (as well as any other EVM compatible chain).
Following the money trail
Today, by 12:26 AM UTC, the attacker sent 1 million $op tokens to Vitalik’s (founder of Ethereum) wallet.
Currently, those tokens are worth ~$848k.
The exploiter also delegated voting rights for the 1 million tokens to Ethereum Foundation security researcher Yoav Weiss. This happens to be the same researcher whom Buterin had also previously delegated his 1,746 OP tokens from the Optimism airdrop. This prompted Weiss to tweet that he was not the hacker but he also suggested that the person might be a white hat hacker.
Also, we have the regular exploit beggars.
These guys have made it their duty to beg exploiters for money.
Possible recovery?
Wintermute has asked the hacker to return the stolen OP tokens while offering a consulting role to the entity responsible.
I don’t know if this tone is what they should be using, but I know that the attacker has one week to respond to Wintermute’s offer.
Way forward
The Wintermute team has committed to buying back the tokens lost. They will track the address that holds these lost tokens and buy as the address sells. To find out more about how they would do it, check out their announcement. The tone of the announcement shows that Wintermute wants to protect the community and remedy the situation.
This is not the first time an error like this has occurred in crypto but it might be the first time for a company this big. The Optimism Foundation has made a second short-term grant of 20 million OP to Wintermute.
This is a temporary grant, as they need to continue with their work as things unfold. Also, it is important to note that these tokens would not take part in governance votes.
Normally, a network upgrade could take place, to halt the movement of those OP tokens. This would be to stop further selling of the exploited tokens. But the team has decided not to take that step due to the precedent it would set. Optimism is a permissionless network and they intend to keep it that way.
Crypto Defi brings a new set of paradigms over key management and safety, that is hard to maintain. But from this incident, we have some key lessons to note, if we want a better multi-chain strategy.
What are these lessons?
Take special care if you're using older smart contract wallets. These wallets may not take advantage of create2.
Ethereum is a “dark forest” – whatever can be front-run, will be front-run.
Move fast during rescue operations. You never know who is watching the chain.
Devs should think hard about the multichain context. Especially in the context of deterministic deployments, create2, and context-specific behaviors.
If you're using a multisig wallet, try to understand the security properties. Try to know if you can control that wallet on chains other than Ethereum.
When receiving funds on a new chain, make a test transaction first. Confirm that you have control of that account by transacting from it. Don't assume that you will have access everywhere. Make sure to confirm it!
Be careful when dealing with large balances. You can never be too cautious in the face of immutability.
NB: This issue is not specific to Optimism! The same thing could happen on any chain.
Honorable mentions: OptimismPBC, Wintermute, and Kelvin Fitcher
If you’d like to read lighter versions of these kinds of content, consider following me on Medium and Twitter. I’d appreciate it!