Post-Mortem: Colluded Transmitters in Socket DL

In the continuous endeavor to ensure the security and robustness of blockchain systems, uncovering vulnerabilities remains a crucial aspect. A recent examination of the Socket DL revealed a potential exploit where colluded transmitters could bypass important validations. This post-mortem aims to dissect the identified vulnerability and suggest remediation strategies.

Reward: This vulnerability was found during socket surge, their bounty program & it led to me gaining $20.000 in bounties.

The Vulnerability

Overview:

Links to codebase:

This vulnerability essentially permits colluded transmitters to run malicious commands on any plug connected to Socket DL, completely bypassing switchboard validations.

Affected Components:

Switchboards impacted include FastSwitchBoard, but there are indications that other switchboards may be susceptible as well.

Detailed Impact:

At its core, this vulnerability could cause messages to be corrupted during transit. The Decapacitor may then find itself unable to validate the said message. This has repercussions for applications built atop Socket's DL.

Proof of Concept (POC):

  1. Proposal of PacketID: Start by proposing a random packetId with a differing remoteSlug. For instance, BSC (56) could be utilized on SocketDst.sol.

  2. Watcher Trip Path: As anticipated, watchers will trip the path, removing you as transmitters. This is consistent with expectations. However, if they trip the global path, further progression is impeded.

  3. Execution After Timeout: Once the timeoutPeriod surpasses the gap between the proposal time and the current block timestamp, you can invoke the execute() function. This function can be utilized with a msgId of your preference, corresponding with the random root proposed in the first step.

The loophole emerges as the transmitter can conveniently sidestep all validations. They simply need to introduce a random packetId and await the timeoutPeriod to elapse on the switchboard.

Primary Code Vulnerability: The absence of validation between the packetId's source chain and the msg id's chain is glaring. Moreover, the root is merely authenticated against the local state present on the socket contract.

Recommendations:

  1. Introduce Cross-Validation: Insert validation checks to corroborate that the packetId's source chain and the msg id's chain are consistent.

  2. Direct Reading from Switchboard: Instead of relying solely on the local state, retrieve the root directly from the switchboard. This alteration can preclude bypassing the Decapacitor validations.

  3. Additional Checks: Infuse further checks between the remoteSlug in both packetId and msgId. Intensify timeout validations in the fast switchboard.

Closing Thoughts:

Identifying vulnerabilities is a crucial step in advancing the security of any system. It's imperative to not only unearth these vulnerabilities but also act upon them swiftly and decisively. The above assessment and suggestions are presented with the sole intention of fortifying Socket DL against potential threats.

Stay informed, stay secure.

Subscribe to Sujith Somraaj
Receive the latest updates directly to your inbox.
Mint this entry as an NFT to add it to your collection.
Verification
This entry has been permanently stored onchain and signed by its creator.