028.md

Flaky Merlot Parrot

High

Front-Running in modifyOrder Enables Unauthorized Order Adjustments, Leading to Financial Exploitation

Summary

The lack of anti-front-running measures in the modifyOrder() function enables attackers to exploit transaction sequencing, manipulating order parameters and achieving financial gain at the expense of legitimate users. https://github.com/sherlock-audit/2024-11-oku/blob/main/oku-custom-order-types/contracts/automatedTrigger/Bracket.sol#L216

Root Cause

Order Modification Vulnerability: The modifyOrder function directly modifies order parameters without mechanisms to prevent transaction sequencing attacks.

Public Visibility: Pending transactions are visible in the public mempool, allowing attackers to identify and exploit user intentions.

Internal pre-conditions

Public Function Access: The modifyOrder function is marked as external, making it callable by any authorized user.

External pre-conditions

Mempool Visibility: Pending transactions can be monitored, revealing order details.

Attack Path

Step 1: User A submits a transaction to modify an order:

• Updates takeProfit to 2,100.

Step 2: Attacker monitors the mempool and identifies User A’s transaction.

Step 3: Attacker submits a similar modification for their own order with:

• Higher gas fees.
• Slightly modified parameters to prioritize execution.

Step 4: The attacker’s transaction is processed first, gaining an advantage over User A.

Impact

User Loss: User A’s modification is delayed, resulting in missed opportunities or unfavorable conditions.

Market Integrity: Repeated front-running undermines user trust and disrupts platform operations.

PoC

Deploy the contract on a public testnet.

1- Simulate Order Modification: User A modifies their order:

modifyOrder(
    1,        // orderId
    2100,     // _takeProfit
    1900,     // _stopPrice
    50,       // amountInDelta
    tokenOut,
    recipient,
    50,       // _takeProfitSlippage
    50,       // _stopSlippage
    false,    // permit
    false,    // increasePosition
    permitPayload
);

2- Observe Transaction in Mempool:

• Use a mempool monitoring tool to identify the transaction.

3- Submit Competing Transaction:

• The attacker submits a competing modification for their own order with:
  • Higher gas fees.
  • Slightly more favorable parameters.

Result: The attacker’s modification is processed first, exploiting the intended market conditions.

Mitigation

Proposed Fix

Nonce-Based Validation: Introduce nonces to ensure transaction order integrity:

mapping(uint96 => uint256) public orderNonces;

function modifyOrder(
    uint96 orderId,
    // Parameters...
) external override nonReentrant {
    require(orderNonces[orderId] == expectedNonce, "Invalid nonce");
    orderNonces[orderId]++;
    // Modify order logic
}

Commit-Reveal Scheme:

• Use a two-step process to conceal modification details, similar to the createOrder fix.