On Jan 16th 2024, an attacker exploited a vulnerability on a newly added module under the Socket Aggregator system. The module was responsible for swapping tokens on behalf of users. The vulnerability in said module allowed the attacker to steal funds from users who had given infinite approval of tokens to the Socket Gateway contract. The attack was carried out through 2 malicious transactions on Ethereum. The total exploited value is estimated to be around $3.3m USD. The tokens transferred included USDC, USDT, DAI, WETH, WBTC and MATIC.
7:20 PM UTC - a few minutes after the exploit we noticed the following:
We quickly triggered our incident response scripts and were able to take actions across all chains pausing the vulnerable module.
Attacker made the exploit transactions within 2 minutes around 7:11 PM UTC. Within 14 minutes of the first exploit transaction, the affected modules were paused on all supported chains. Furthermore, a war room with some of the best security teams in crypto was established and we actively started working to negotiate recovery of user funds with the attacker.
<aside> 💡 Within an hour, we identified the root issue, paused all the affected contracts, setup a war room with top security researchers and ensured the bridge was live and safe to use.
</aside>
Timeline
| Time (UTC) | Event Description | Notes | Link |
|---|---|---|---|
| 07:11 PM | Attack Tx #1 | Attacker made the first exploit transaction that transferred out user funds | https://etherscan.io/tx/0xc6c3...8fd6 |
| 07:13 PM | |||
| (T + 2 min) | Attack Tx #2 | Attacker made the second exploit transaction that transferred out user funds | https://etherscan.io/tx/0x591d...ce54 |
| 7:19 PM | |||
| (T + 8 min) | First notice of incident | Team became aware of the incident from user complaints and hexagate | |
| 07:25 PM | |||
| (T + 14 min) | Pausing Contracts | Socket disabled/paused affected contract so that the exploiter can’t further transfer out user funds across any chain | https://etherscan.io/tx/0xac75...604b |
| 07:25 PM | |||
| (T + 14 min) | WarRoom Creation | Start of collaboration with security experts to investigate the incident further | |
| 7:29 PM | |||
| (T + 18 min) | Team identified the root cause. | wrappedTokenSwapperImpl module had an unverified contract call. Used to transfer users tokens. | |
| 8:05 PM | |||
| (T + 54 min) | External Comms | Initial communication to external parties about the incident | |
| https://twitter.com/SocketDotTech/status/1747... | |||
| 09:22 PM | |||
| (T + 131 min) | Initiated contact with Exploiter | Socket Admin wallet sent an on-chain message to the attacker to initiate contact for recovery of user funds | https://etherscan.io/tx/0x959e...bfa5 |
Socket Gateway hosts modules(Impls) that are external adapters, admin role has the ability to add new/attach modules to the Gateway. According to internal deployment process guidelines, developers first deploy these modules and then the admin “attaches” them to the gateway.
In our scheduled upgrade to add WrappedTokenSwapperImpl, we had an operational mixup between the module deployed pre-review and the one merged post review. This mixup resulted in an incorrect module being attached to the Gateway.
The vulnerability that was exploited in WrappedTokenSwapperImpl module stems from how a call was being made to external contracts without appropriately validating user inputs. Both fromToken and swapExtraData were taken as inputs and used to make a contract call. This allowed the attacker to call transferFrom function of token contracts that had granted approvals to Socket Gateway contract. To carry out the exploit, the attacker combined a zero amount swap along with this malicious swapExtraData.