Zaros Part 1

Summary:

contract uses the delegatecall proxy pattern (which takes user-provided call
data) in a payable function within a loop. This means that each delegatecall within the
for loop will retain the msg.value of the transaction.
function can indeed be exploited to change or assign the tradingAccountId if an attacker can control or manipulate the data payloads

Vulnerability Details:

Use of delegatecall to Self-Contract: the contract uses delegatecall to call itself, typically indicated by address(this).delegatecall(...).

Calldata manipulation: situations involving the manipulation of calldata, common in functions like multicall

similar problem found in https://solodit.xyz/issues/use-of-delegatecall-in-a-payable-function-inside-a-loop-trailofbits-yield-v2-pdf

Impact:

The delegatecall function in Solidity allows a contract to execute code from another contract while maintaining its own storage context. While this feature can be powerful for various use cases such as proxy contracts and upgradability, it also introduces a level of complexity that can lead to vulnerabilities if not used carefully.

• Unauthorized State Changes:
  The attacker can change or assign the tradingAccountId in a way that affects the contract’s functionality or state.

• Potential Losses:
  This can lead to unauthorized access, data manipulation, or even financial losses if the payload performs actions such as transferring funds.

Proof of Concept:

Potential Exploitation via Payload Manipulation

1. Malicious Payloads:

   • If an attacker can craft payloads that are executed via delegatecall, they can use these payloads to perform actions based on the tradingAccountId.

   • For example, an attacker might create a payload that performs unauthorized actions or alters the state related to tradingAccountId.

2. Scenario Example:
   Suppose the attacker has control over the data array and can inject malicious payloads. They might craft a payload that manipulates the storage of the current contract, potentially altering the tradingAccountId.

   • Example Payload:

     // Example of a malicious payload function (hypothetical)

     function maliciousFunction(uint128 accountId, address targetAddress) external {

     // Assume this function changes the tradingAccountId or performs some malicious action

     // For example, changing account data or transferring funds to targetAddress

     // Example: `updateAccount(accountId, targetAddress);`

     }

3. Delegatecall Execution:

   • The attacker submits this payload via the data array to createTradingAccountAndMulticall.

   • The delegatecall executes this payload in the context of the current contract, which means it modifies the current contract's state based on the malicious payload.

Exploit Scenario:
Alice, a member of the team, adds a new functionality to the core protocol that
adjusts users’ balances according to the msg.value. Eve, an attacker, uses the batching
functionality to increase her ETH balance without actually sending funds from her account,
thereby stealing funds from the system.

Tools Used:

Manual review

Recommendations:

Input Validation:

• Validate Payloads: Ensure that the data payloads are from trusted sources and are properly validated before execution.

• Prevent Malicious Payloads: Implement checks to prevent unauthorized or malicious payloads from being executed.

Careful Storage Layout : Ensure that the storage layout is consistent between interacting contracts. This reduces the likelihood of misalignments that can be exploited.

Referance

• https://medium.com/@solidity101/100daysofsolidity-071-exploring-the-power-of-delegatecall-in-solidity-9a07da7547bc

• https://www.paradigm.xyz/2021/08/two-rights-might-make-a-wrong