Lucene search

K
code423n4Code4renaCODE423N4:2023-09-CENTRIFUGE-FINDINGS-ISSUES-705
HistorySep 14, 2023 - 12:00 a.m.

Rouge ward can remove auth permission from other wards and then remove themselves

2023-09-1400:00:00
Code4rena
github.com
5
rogue ward
auth permission
protocol governance
centralized power
financial losses
reputation damage
decentralized system
time lock
mitigation
access control

Lines of code

Vulnerability details

In a protocol, the deny function is used to remove the ward permissions from an address. This is actually a serious thing to consider that can actually occur, if a ward contract or account is obtained and other wards are not aware, the rogue ward can actually remove the wards before they actually have a chance to pause the contract to stop the ward. Here’s a potential security scenario:

An attacker, Ben, either through compromising a private key or social engineering, becomes one of the protocol’s wards

With ward privileges, Ben decides to use the deny function to remove every other ward in the protocol systematically.

As Ben removes all other wards, the protocol’s governance becomes centralized around him. This means that Alice has full control over critical decisions

Ben can go even further by using his centralized power to enact decisions that disrupt the protocol’s intended functioning. This can lead to financial losses for users and damage to the protocol’s reputation.

After causing disruption, Ben can choose to remove himself as a ward using the same deny function. This effectively leaves the protocol without any governance mechanism or ward, rendering it useless

With no administrators or wards left, the project is effectively frozen and cannot be resumed or managed.
Users may lose access to their funds or be unable to transact within the project.
This example illustrates how an attacker with control over a contract that has permission management capabilities can potentially exploit vulnerabilities and disrupt a decentralized system.

Proof of Concept

 /// @notice removes the ward permissions from an address on a contract
    /// @param target the address of the contract
    /// @param user the address which persmissions should be removed
    function denyContract(address target, address user) public auth {
        AuthLike(target).deny(user);
        emit DenyContract(target, user);
    }

// @dev Remove permissions from the user
    function deny(address user) external auth {
        wards[user] = 0;
        emit Deny(user);
    }

as you can see, a rouge contract can carry out this attack with no problems, at a targeted time oblivious to other wards before the protocol can be paused

Recommended Mitigation Steps

The same way there’s a executeRely, there also should a TIme lock executeDeny, to give time to all wards in the protocol the time and appropriate time to respond and perform the necessary security actions to stop the rouge ward.

Assessed type

Access Control


The text was updated successfully, but these errors were encountered:

All reactions