Security incident

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.

Situation run down

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.

Response

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 (https://dateful.com/convert/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/0xc6c3331fa8c2d30e1ef208424c08c039a89e510df2fb6ae31e5aa40722e28fd6
07:13 PM
(T + 2 min) Attack Tx #2 Attacker made the second exploit transaction that transferred out user funds https://etherscan.io/tx/0x591d054a9db63f0976e533f447df482bed5f24d7429646570b2108a67e24ce54
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/0xac75adcc1cb3fef158c4f200c48fcbcbb9b6ce3250bdf3751d6231d41a9e604b
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/1747349422730813525
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/0x959e319bd9ccac8d567252bb732b6e2b15b2b598f5259253eac68bd65521bfa5

Vulnerability Analysis

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](<https://etherscan.io/address/0xCC5fDA5e3cA925bd0bb428C8b2669496eE43067e#code>) 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.

Screenshot 2024-01-17 at 4.51.07 AM.png

Recovery Attempt