0xBhumii - Insufficient Cross-Chain Messaging Validation in InfernalRiftAbove

[sherlock-admin4]

0xBhumii

Medium

Insufficient Cross-Chain Messaging Validation in InfernalRiftAbove

Summary

The returnFromTheThreshold function validates the cross-chain message sender using the msg.sender address and checks if it matches the expected contracts (L1_CROSS_DOMAIN_MESSENGER and INFERNAL_RIFT_BELOW). However, this method could be improved by implementing a more secure challenge-response mechanism to ensure the authenticity of the cross-chain messages. Current validation might be vulnerable to certain attack vectors, such as spoofing or replay attacks.

Vulnerability Detail

The returnFromTheThreshold function relies on the msg.sender address for verifying that the message comes from the L1_CROSS_DOMAIN_MESSENGER and INFERNAL_RIFT_BELOW. While this provides some level of security, it is not sufficient to guarantee the authenticity of the cross-chain messages. Without a challenge-response mechanism, it is possible for attackers to send fraudulent or replayed messages from other sources that appear to come from valid addresses. This can potentially lead to unauthorized token transfers or tampering with cross-chain communication.

Impact

Spoofing: Malicious actors could potentially spoof the msg.sender address or find ways to bypass simple validation, causing unauthorized transactions or message handling.
Replay Attacks: Since there is no nonce or challenge-response in place, attackers could replay old valid messages to trigger unwanted actions, such as re-transferring tokens.
Cross-Chain Security Risks: The cross-chain bridge between L1 and L2 becomes vulnerable to tampering and manipulation, compromising the security of the entire system.

Code Snippet

https://github.com/sherlock-audit/2024-08-flayer/blob/main/moongate/src/InfernalRiftAbove.sol#L206C1-L242C1

Tool used

Manual Review

Recommendation

Implement Challenge-Response Mechanism: Introduce a challenge-response system where L1 and L2 contracts exchange cryptographic challenges and responses to ensure the authenticity of cross-chain messages. This mechanism can be based on nonces, timestamps, or other verifiable cryptographic proofs.
Use Nonce-Based Validation: Add a nonce or sequence number to messages that prevents replay attacks. Each message should be unique and processed only once to avoid duplication or unintended consequences.
Signature Verification: Use cryptographic signatures to verify the authenticity of the message. The L1 contract can sign the messages, and the L2 contract should verify the signature before processing any actions.
Improve Event Logging: Log events that capture the message details, such as sender address, message content, and other identifying information, to facilitate better tracking and debugging of potential security issues.