What has happened SocketDotTech and why this is in fact the main problem we have to fight with in the web3 space?
Three days ago, the following contract was deployed:
https://etherscan.io/address/0xcc5fda5e3ca925bd0bb428c8b2669496ee43067e#code…
which was then used as implementation contract for the following proxy
https://etherscan.io/address/0x3a23f943181408eac424116af7b7790c94cb97a5…
the crux was that users have approved tokens to this proxy.
Now let’s take a look at the vulnerable code itself:
Three days ago, the following contract was deployed:
https://etherscan.io/address/0xcc5fda5e3ca925bd0bb428c8b2669496ee43067e#code…
which was then used as implementation contract for the following proxy
https://etherscan.io/address/0x3a23f943181408eac424116af7b7790c94cb97a5…
the crux was that users have approved tokens to this proxy.
Now let’s take a look at the vulnerable code itself:
If we now also take a look at the corresponding function selector:
Argh, there was no validation at all for these inputs, so the attacker could just trivially call this function with any fromToken/toToken, which does not revert on the transferFrom, with a balance of zero. Additionally, the toToken and the corresponding swapExtraData was provided, which was just the transferFrom selector with the corresponding victim address and the desired amount.
A corresponding attack contract could look like this:
We want to note that this was written in approx 30min, and it doesn't have any safety features like privileged access etc, so don't start auditing this snippet. However, you basically get the idea, this can of course be extended with a loop and different victims etc. Of course the parameters must be chosen such that the function does not revert on any state transitions, e.g. transfer 0 in, etc.
The only necessary thing left now was for the attacker to fetch all approvals for prominent tokens to that contract. This can be done via a simple web3.js script.
However, the main intention of this tweet is not even the technical part, as a lot of folks already shared this. The real intention is to understand how it was possible to deploy an unaudited contract and use it as implementation.
The harsh and important truth is that no one else is responsible for this incident besides the person that has set this contract as implementation without getting it audited. How are we supposed to create mainstream adoption if big players do not follow the most basic rules? We know nobody wants to hear this but this is in fact the real issue with web3.
This is a good opportunity to raise awareness for the need of experienced security researchers directly on the project side. Such upgrade audits can usually be done on a short notice and based on diff-checks.
