Full Report
IBC on Cosmos is a generalized way for crosschain communication. In the case of Comdex, they were using IBC to get oracle price updates from Band. The IBC protocol itself is trustless and identifies another chain based on a channel ID that cannot be set by the chain instead of the chain name. This trustless nature sounds great but has to be kept in mind when using IBC. Comdex did not allowlist a specific oracle update packet to the channel of Bandchain. Why is this bad? Any blockchain, including a solo machine (individual user with a private key) could have called this and set the prices of an oracle. Since the dex prices could be arbitrarily controlled, stealing all of the funds in the protocol would have been trivial. To me, the main takeaway is that if communication on IBC is expected with only a single chain then this logic needs to be added to the handler of the IBC packet. Otherwise, the trustless nature will cause problems in your chain.
Analysis Summary
# Vulnerability: Forgeable IBC Oracle Packets in Comdex Blockchain
## CVE Details
- **CVE ID**: Not explicitly assigned (Common in Cosmos ecosystem "silent" or internal fixes)
- **CVSS Score**: 9.1 (Estimated) (Critical)
- **CWE**: CWE-285: Improper Authorization / CWE-345: Insufficient Verification of Data Authenticity
## Affected Systems
- **Products**: Comdex Blockchain (Cosmos-SDK based)
- **Versions**: Versions prior to the February 2024 security disclosure.
- **Configurations**: Any deployment using the Inter-Blockchain Communication (IBC) protocol to receive price oracle updates from BandChain without channel allowlisting.
## Vulnerability Description
The vulnerability stems from an insecure implementation of the IBC packet handler for oracle price updates. The IBC protocol is trustless; it identifies external chains based on **Channel IDs** rather than human-readable chain names.
Comdex failed to implement an **allowlist** for specific IBC channels. Because the handler did not verify that incoming oracle packets originated specifically from the authorized BandChain channel, any entity—including a malicious blockchain or a "solo machine" (a single user acting as a chain via a private key)—could send a forged IBC packet. This allowed an attacker to inject arbitrary price data into the Comdex decentralized exchange (DEX).
## Exploitation
- **Status**: PoC available (demonstrated by CyberArk researchers).
- **Complexity**: Medium (requires knowledge of IBC packet structure and Cosmos-SDK message handling).
- **Attack Vector**: Network (Cross-chain via IBC).
## Impact
- **Confidentiality**: None
- **Integrity**: Critical (Complete control over oracle price data).
- **Availability**: High (Potential for total drainage of protocol liquidity).
## Remediation
### Patches
- The Comdex team has implemented logic to verify the source channel of incoming IBC packets. Users should ensure they are running the latest version of the Comdex binary (refer to official GitHub repository: `https[:]//github[.]com/comdex-official/comdex`).
### Workarounds
- For developers on other Cosmos chains: Implement strict validation in the `OnRecvPacket` IBC callback to ensure the `packet.SourceChannel` matches the expected, trusted provider.
## Detection
- **Indicators of compromise**: Unusual or extreme price fluctuations in assets that do not match global market rates; IBC packets originating from unknown or newly created channels.
- **Detection methods and tools**: Monitoring of IBC `MsgRecvPacket` events specifically targeting the oracle module; auditing of channel handshakes (`ChanOpenInit`) involving the oracle handler.
## References
- **CyberArk Threat Research**: `https[:]//www[.]cyberark[.]com/resources/threat-research-blog/the-hackers-guide-to-the-cosmos-sdk-stealing-millions-from-the-blockchain`
- **Cosmos SDK Documentation**: `https[:]//docs[.]cosmos[.]network/v0.47/learn/beginner/ibc`
- **IBC Protocol Sec**: `https[:]//ibc[.]cosmos[.]network/main/ibc/overview[.]html`