This vulnerability enables any entity with a comprehensive understanding of the storage slots of the Ethereum Virtual Machine (EVM) to illicitly extract the password stored within the PasswordStore contract.
The vulnerability originates from the EVM's storage structure, known for its predictability and transparency. Through an exploration of the storage slots, a malicious entity can identify the specific storage slot housing the password.
Following the deployment steps as documented. Notably, the deployment script initializes the password as "myPassword."
The order of declaration of state variables determines the position of these variables in storage.
The string s_password is stored in slot 1 of the contract storage with the owner address in slot 0.
After deploying the contract, we will obtain the contract's address, which we'll refer to as contract_address. This address is required for accessing the contract's storage.
To exploit the EVM storage and extract the password, the attacker can use the "cast" tool from foundry suite and the appropriate parameters to loacate the byte code in a specific storage slot in this case slot(1). Below is the command and its breakdown:
cast storage: This command tells the "cast" tool to retrieve data from the contract's storage.
<contract_address>: Replace this with the actual contract address obtained during deployment.
--rpc-url http://127.0.0.1:8545: Specifies the RPC URL for the Ethereum node in this case our ANVIL node
The result of this command will be a hexadecimal string representing the stored password:
The data obtained from the storage is encoded in bytes. To reveal the actual password, the attacker can use a decoding tool or script. In this case, the attacker can convert the bytes to ASCII using the cast :
The result will be the actual password we have deplyod our contract with:
-To decode this input data, w'll need to understand the structure of Ethereum function calls and the encoding of function parameters.
MethodID: The MethodID 0x290bb453 indicates the function being called, which is setPassword(string newPassword).
Function Parameters:
[0] is a placeholder for the location of the first parameter, which is the offset to the actual data.
[1] is the length of the string parameter (in bytes).
[2] is the actual data, which is the new password encoded as a hexadecimal string.
Decoding the String Parameter:
We will use [1] to determine the length of the string parameter, which is 0x000000000000000000000000000000000000000000000000000000000000000e. This indicates that the string is 14 bytes long.
We will use [2] to get the hexadecimal representation of the new password, which is 0x6e657750617373776f7264313233000000000000000000000000000000000000.
Decode to ASCII:
To reveal the actual password, we can use any tool or script of choice to decode the hexadecimal representation of the new password to ASCII characters. This will expose the new password set.
The impact of this vulnerability is High with a medium likelyhood of occuring.
It characterized by the compromise of the security of the password within the PasswordStore contract. Any malicious entity well-versed in the structure of EVM can flash out the password from its storage location, potentially leading to unauthorized access or disruptions to the protocol's operability.
Foundry's cast
Etherscan
-To mitigate this vulnerability, I strongly recommended considering alternative storage mechanisms for sensitive data like passwords and avoiding the exposure of private information through the EVM. The security and confidentiality of sensitive data should be a top priority when designing and deploying smart contracts.
Private functions and state variables are only visible for the contract they are defined in and not in derived contracts. In this case private doesn't mean secret/confidential
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.