Backend Fails To Verify EventsEmitted From The Correct BridgeContract Addres

[yxsec]

Overview
In the current implementation of the getBridgeEvent function, a critical flaw exists in how event logs are processed and verified. The function is responsible for extracting events emitted by the smart contract based on transaction receipts. However, it lacks an essential security check: verifying whether the contract that emitted the event is the legitimate bridge contract deployed by the project team.
https://github.com/dl-tokene/bridge-core/blob/main/internal/proxy/evm/event.go

func getBridgeEvent(dest interface{}, logName string, eventIndex int, receipt *ethTypes.Receipt) error {
    abi, err := bridge.BridgeMetaData.GetAbi()
    if err != nil {
        return errors.Wrap(err, "failed to parse bridge ABI")
    }
    contract := bind.NewBoundContract(common.Address{}, *abi, nil, nil, nil)

    index := 0
    for _, l := range receipt.Logs {
        if l == nil {
            continue
        }
        err := contract.UnpackLog(dest, logName, *l)
        if err == nil {
            if index == eventIndex {
                return nil
            }
            index++
        }
    }

    return types.ErrEventNotFound
}

Issue Description
The vulnerability arises from the absence of a validation step for the contract address emitting the event. In the getBridgeEvent function, transaction logs are iterated over, and events are unpacked using the ABI of the expected contract. However, there is no verification to ensure that the address emitting the event matches the legitimate contract address of the bridge. This creates an exploitable security gap.

An attacker can exploit this flaw by deploying a counterfeit contract that mimics the legitimate bridge contract’s event structure. They can trigger an event by depositing tokens into the counterfeit contract, obtaining a transaction hash, and submitting it for further processing. Since the current logic does not validate the emitting contract’s address, the system will incorrectly trust the event as if it originated from the legitimate bridge contract.

Security Impact
This oversight in the event verification logic allows attackers to manipulate the system by submitting transaction hashes from fake contracts, leading to unauthorized actions such as fraudulent withdrawal approvals on the destination chain. The backend assumes that all events in the transaction logs are legitimate without ensuring that they come from the correct bridge contract.

Recommendation
To mitigate this issue, it is necessary to introduce a contract address verification step within the getBridgeEvent function. Specifically, when processing transaction logs, the function must ensure that the emitting contract address matches the expected address of the legitimate bridge contract.