Access Control Vulnerabilities in Smart Contracts

Access Control Vulnerabilities in Smart Contracts

Understanding access control in Smart Contract
Access controls define the restrictions around privileges and roles of users in an application. Access control in smart contracts can be related to governance and critical logic like minting tokens, voting on proposals, withdrawing funds, pausing and upgrading the contracts, changing ownership, etc.

OpenZeppelin libraries for access control 
The majority of the smart contracts use OpenZeppelin’s Ownership library. Openzeppline’s Ownable defines modifiers like “onlyOwner” that check if the user making a function call is the owner of the contract. Other libraries also check if the user has privileges to call the function using modifiers/functions like “hasRole”. Smart contracts can define custom Roles according to their requirements. These roles can be assigned to privileged users, and the Openzeppelin libraries help validate these roles.

Common vulnerabilities related to access control
The most common vulnerabilities related to access control can be narrowed down as below. 
1. Missed Modifier Validations — It is important to have access control validations on critical functions that execute actions like modifying the owner, transfer of funds and tokens, pausing and unpausing the contracts, etc. Missing validations either in the modifier or inside require or conditional statements will most probably lead to compromise of the contract or loss of funds.
2. Incorrect Modifier Names — Due to the developer’s mistakes and spelling errors, it may happen that the name of the modifier or function is incorrect than intended. Malicious actors may also exploit it to call the critical function without the modifier, which may lead to loss of funds or change of ownership depending on the function’s logic.
3. Overpowered Roles — Allowing users to have overpowered roles may lead to vulnerabilities. The practice of least privilege must always be followed in assigning privileges.

HospoWise Hack — A case scenario
Recently Hospowise was hacked because of an access control issue that allowed anyone to burn the Hospo tokens.

If we check the code here 
https://etherscan.io/address/0x952aa09109e3ce1a66d41dc806d9024a91dd5684#code
We will notice that the burn function is public and hence any user can call the burn function. Line 1348–1350

function burn(address account, uint256 amount) public {
        _burn(account, amount);
    }

Now an attacker could purchase any token and then call the public burn function to burn all the hospo tokens on UniSwap, creating inflation and hence increasing the worth of the token and then swapping it for ETH till the pool is exhausted.

This could have been prevented if the function had access control implemented like onlyOwner or the function was internal with correct access control logic. 
SolidityScan automatically detects such missing access control modifiers and validation in an automated manner.

Signup for a free trial at https://solidityscan.com/signup