You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An Attacker Can Register New Hats for Arbitrary Signers to Abuse Safe Signatures
Summary
When claimableFor is set to true, an attacker can register new Hats for any legitimate signer, allowing them to abuse the Safe’s signature permissions by calling claimSignerFor or claimSignersFor.
In the HatsSignerGate contract, when claimableFor is set to true, there is no restriction on the caller of claimSignerFor or claimSignersFor, enabling arbitrary users to exploit these methods.
Internal pre-conditions
The contract variable claimableFor is set to true.
The signer _signer must wear a valid Hat (validated via HATS.isWearerOfHat).
The current Safe signature threshold is met (validated by _getRequiredValidSignatures).
External pre-conditions
Call claimSignerFor or claimSignersFor to register a new Hat for any signer.
Attack Path
The attacker calls claimSignerFor(_hatId, _signer) with a valid signer’s address _signer and Hat ID _hatId.
The contract invokes _registerSigner, validating the signer’s ownership of the specified Hat.
The contract adds the signer to the Safe via _addSigner.
The attacker repeats the process to register multiple Hats and signers.
Impact
Affected Party: Safe Signers
In this attack path, the Safe’s signature permissions are compromised.
Potential risks:
The attacker could register excessive signers, reducing the overall security of the Safe.
Malicious registrations could alter threshold configurations, disrupting transaction approval flows.
PoC
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract Exploit {
function exploit(address hsg, uint256 hatId, address signer) public {
HatsSignerGate(hsg).claimSignerFor(hatId, signer);
}
}
Mitigation
Add access control to claimSignerFor and claimSignersFor to limit their usage to specific roles.
Implement a whitelist mechanism to restrict which signers can be registered.
The text was updated successfully, but these errors were encountered:
Dizzy Tan Parakeet
Medium
An Attacker Can Register New Hats for Arbitrary Signers to Abuse Safe Signatures
Summary
When claimableFor is set to true, an attacker can register new Hats for any legitimate signer, allowing them to abuse the Safe’s signature permissions by calling claimSignerFor or claimSignersFor.
Root Cause
https://github.com/sherlock-audit/2024-11-hats-protocol/blob/main/hats-zodiac/src/HatsSignerGate.sol#L215
In the HatsSignerGate contract, when claimableFor is set to true, there is no restriction on the caller of claimSignerFor or claimSignersFor, enabling arbitrary users to exploit these methods.
Internal pre-conditions
The contract variable claimableFor is set to true.
The signer _signer must wear a valid Hat (validated via HATS.isWearerOfHat).
The current Safe signature threshold is met (validated by _getRequiredValidSignatures).
External pre-conditions
Call claimSignerFor or claimSignersFor to register a new Hat for any signer.
Attack Path
The attacker calls claimSignerFor(_hatId, _signer) with a valid signer’s address _signer and Hat ID _hatId.
The contract invokes _registerSigner, validating the signer’s ownership of the specified Hat.
The contract adds the signer to the Safe via _addSigner.
The attacker repeats the process to register multiple Hats and signers.
Impact
Affected Party: Safe Signers
In this attack path, the Safe’s signature permissions are compromised.
Potential risks:
The attacker could register excessive signers, reducing the overall security of the Safe.
Malicious registrations could alter threshold configurations, disrupting transaction approval flows.
PoC
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;
contract Exploit {
function exploit(address hsg, uint256 hatId, address signer) public {
HatsSignerGate(hsg).claimSignerFor(hatId, signer);
}
}
Mitigation
Add access control to claimSignerFor and claimSignersFor to limit their usage to specific roles.
Implement a whitelist mechanism to restrict which signers can be registered.
The text was updated successfully, but these errors were encountered: