Phishing via tx.origin in RocketStorage Contract

[txguard]

Phishing via tx.origin in RocketStorage Contract

Summary

The RocketStorage contract in its current implementation is vulnerable to a Phishing with tx.origin attack. The misuse of the tx.origin property in the onlyLatestRocketNetworkContract modifier exposes critical functionality to potential malicious actors. An attacker can exploit this vulnerability to gain unauthorized access to privileged functions, such as setDeployedStatus() or others, by deceiving the guardian address into interacting with a malicious contract.

---

Details

Affected Functionality:

The vulnerability resides in the onlyLatestRocketNetworkContract modifier, specifically during the initialization phase (storageInit == false):

modifier onlyLatestRocketNetworkContract() {
    if (storageInit == true) {
        require(booleanStorage[keccak256(abi.encodePacked("contract.exists", msg.sender))], "Invalid or outdated network contract");
    } else {
        require((
            booleanStorage[keccak256(abi.encodePacked("contract.exists", msg.sender))] || tx.origin == guardian
        ), "Invalid or outdated network contract attempting access during deployment");
    }
    _;
}

Root Cause:

The use of tx.origin in the condition:

tx.origin == guardian

allows any malicious contract to pass this check if the guardian address interacts with the malicious contract, as tx.origin retains the original sender of the transaction regardless of intermediate calls.

Exploitation:

An attacker can deploy a malicious contract and trick the guardian into calling a function on the malicious contract. The malicious contract then forwards the call to the vulnerable function (e.g., setDeployedStatus()), and since tx.origin matches guardian, the contract treats the call as legitimate.

---

Proof of Concept

1. Malicious Contract:
   The attacker deploys a contract like the following:

   pragma solidity ^0.7.6;
   
   contract MaliciousContract {
       address targetContract;
   
       constructor(address _targetContract) {
           targetContract = _targetContract;
       }
   
       function attack() external {
           (bool success, ) = targetContract.call(abi.encodeWithSignature("setDeployedStatus()"));
           require(success, "Attack failed");
       }
   }

2. Attack Execution:
   The attacker tricks the guardian into calling the attack() function, possibly through social engineering or by embedding the malicious call into a seemingly legitimate interaction.

3. Result:
   The condition tx.origin == guardian evaluates to true, allowing the attacker to execute the setDeployedStatus() function or any other restricted function protected by the onlyLatestRocketNetworkContract modifier.

---

Impact

The vulnerability allows unauthorized access to critical functionality during the deployment phase. Potential impacts include:

• Unauthorized modification of the deployment status.
• Execution of privileged functions, which could compromise the security and integrity of the system.

---

Remediation

Replace the use of tx.origin with msg.sender in the onlyLatestRocketNetworkContract modifier:

require((
    booleanStorage[keccak256(abi.encodePacked("contract.exists", msg.sender))] || msg.sender == guardian
), "Invalid or outdated network contract attempting access during deployment");

This change ensures that only the immediate caller is checked, preventing phishing attacks via intermediate contracts.

---

Recommendations

1. Avoid tx.origin: Do not use tx.origin for access control checks or any sensitive logic.
2. Enhance Access Control: Use msg.sender and implement role-based access control mechanisms.
3. Conduct Security Audits: Perform regular security reviews to identify and mitigate such vulnerabilities.

---

Conclusion

The use of tx.origin in the RocketStorage contract introduces a serious vulnerability that can be exploited via phishing attacks. Prompt remediation is required to prevent potential exploitation.