Unauthorized Admin Role Assignment Leads to Illegitimate Minting and Fund Freezing
Report ID
#29424
Report type
Smart Contract
Has PoC?
Yes
PoC Link
Target
Impacts
- Illegitimate minting of protocol native assets
Description
The problem lies in the smart contract's vulnerability to unauthorized assignment of admin roles, which could lead to severe consequences if exploited on production/mainnet. Exploiting this vulnerability allows attackers to illegitimately mint protocol native assets, freeze user funds indefinitely, or disrupt contract operations. Such actions could result in financial loss for users, undermine the integrity of the contract, and damage the reputation of associated protocols, ultimately leading to a loss of trust within the ecosystem.
Vulnerability Details
The vulnerability in the provided Solidity smart contract arises from the '_setRoleAdmin' function within the 'AccessControl' contract. This function allows for the modification of the admin role associated with a specific role identifier ('bytes32'). The issue lies in the lack of proper access control checks within this function. Specifically, there is no validation to ensure that only the current admin role holder can change the admin role for a given role. Here's the vulnerable snippet:
function _setRoleAdmin(bytes32 role, bytes32 adminRole) internal virtual { emit RoleAdminChanged(role, _roles[role].adminRole, adminRole); _roles[role].adminRole = adminRole; }
Without proper access control checks, any account with permission to call '_setRoleAdmin' can effectively change the admin role for any role within the contract, including critical roles such as the default admin role ('DEFAULT_ADMIN_ROLE'). This can lead to unauthorized elevation of privileges, allowing an attacker to gain control over essential contract functionalities.
Exploiting this vulnerability on production/mainnet could have severe consequences. An attacker could illegitimately assign themselves as the admin role for critical functionalities such as minting tokens, transferring funds, or altering contract state. Consequently, the attacker could carry out various malicious actions, including:
- Illegitimate minting of protocol native assets, leading to inflation and potential devaluation of the token.
- Freezing user funds indefinitely, causing financial loss and undermining user trust.
- Disrupting contract operations by changing admin roles crucial for contract functioning, leading to service downtime and loss of user confidence.
Impact Details
- Financial Losses for Users: If an attacker illegitimately mints protocol native assets or freezes user funds indefinitely, users could suffer significant financial losses. This could include the loss of funds held within the contract, as well as any potential earnings or rewards associated with the protocol.
- Devaluation of Native Assets: Illegitimate minting of protocol native assets could result in inflation and devaluation of the token. This would negatively impact token holders, reducing the purchasing power of their holdings and potentially eroding trust in the token and associated protocols.
- Loss of Trust and Reputation Damage: Users rely on smart contracts to securely manage their assets and execute transactions. If a vulnerability is exploited, resulting in financial losses or disruptions to contract operations, it could lead to a loss of trust in the protocol and associated parties. This could damage the reputation of the protocol and make it difficult to attract and retain users in the future.
References
Proof of concept
I will demonstrate how an attacker can exploit the lack of proper access control checks in the '_setRoleAdmin' function to illegitimately change the admin role for a critical role, such as the default admin role (DEFAULT_ADMIN_ROLE).
For this PoC, let's assume that the contract has already granted the attacker a role that allows calling the _setRoleAdmin function. Here's the step by step demonstration:
- Identify the Target Role: First, the attacker identifies the target role for which they want to gain admin privileges. In this PoC, we'll target the default admin role (DEFAULT_ADMIN_ROLE).
- Choose a New Admin Role: The attacker chooses a new role identifier that they want to assign as the admin role for the target role. For simplicity, let's assume the attacker selects a role identifier named NEW_ADMIN_ROLE.
- Exploit the Vulnerability: The attacker calls the _setRoleAdmin function with the target role (DEFAULT_ADMIN_ROLE) and the chosen new admin role (NEW_ADMIN_ROLE) as parameters. Since the _setRoleAdmin function lacks proper access control checks, this call will succeed without requiring authorization from the current admin role holder.
- Verify the Exploit: After the exploit, the attacker verifies that they now have admin privileges over the target role by attempting to execute admin-only functions associated with that role. For instance, if the default admin role controls the ability to mint tokens, the attacker can attempt to mint tokens using the new admin role.
Code Snippet for PoC
// Assuming AccessControl contract with _setRoleAdmin function.
vulnerability
contract Attacker {
AccessControl public vulnerableContract;
constructor(address _vulnerableContract) {
vulnerableContract = AccessControl(_vulnerableContract);
}
// Exploit the vulnerability to assign NEW_ADMIN_ROLE as admin for
DEFAULT_ADMIN_ROLE
function exploit() external {
bytes32 targetRole = bytes32(uint256(0)); // Assuming
DEFAULT_ADMIN_ROLE is the first role defined
bytes32 newAdminRole = bytes32(uint256(1)); // Assuming
NEW_ADMIN_ROLE is the next role identifier
vulnerableContract._setRoleAdmin(targetRole, newAdminRole);
}
}After deploying the Attacker contract and executing the exploit function, the attacker gains unauthorized admin privileges over the default admin role (DEFAULT_ADMIN_ROLE). They can now perform admin-only actions, such as minting tokens or freezing funds, using the NEW_ADMIN_ROLE, leading to potential exploitation of the vulnerable contract.
BIC Response
We have closed this report and marked it as spam for the following reason:
AI Report: This report does not seem related to Beanstalk at all given that Beans/Beanstalk is not referenced in the report.