Privacy Violation: Unauthorized Access to Blocking Status of Profiles

[code423n4]

Lines of code

https://github.com/code-423n4/2023-07-lens/blob/cdef6ebc6266c44c7068bc1c4c04e12bf0d67ead/contracts/LensHub.sol#L531

Vulnerability details

Impact

The smart contract contains a critical privacy violation that allows unauthorized users to access the blocking status of profiles. The isBlocked function, which is intended to check if one profile is blocked by another, lacks proper access controls and authorization checks. As a result, any user can enter the profile IDs of two other users and determine if they have blocked each other, even without explicit authorization or consent.

Proof of Concept

in contract have directly privacy vialotion of user anyone call blocked function and check different users blocklist without any permission This direct like unauthorized access to someone else profile details

In the contract, we have the following information:

_blockedStatus[profile1][profile2] = true;

This means that profile2 has blocked profile1.

Now, an unauthorized user, let's call them attacker, decides to exploit the lack of access controls in the isBlocked function. The attacker calls the isBlocked function with profileId = profile1 and byProfileId = profile2,

code https://github.com/code-423n4/2023-07-lens/blob/cdef6ebc6266c44c7068bc1c4c04e12bf0d67ead/contracts/LensHub.sol#L531C3-L533C6

function isBlocked(uint256 profileId, uint256 byProfileId) external view returns (bool) {
    return _blockedStatus[byProfileId][profileId];
}

Tools Used

Remix

Recommended Mitigation Steps

To address the privacy violation, implement appropriate access controls and authorization checks in the isBlocked function. Restrict access to authorized users only, such as the profile owner or users explicitly granted permission by the profile owner. Additionally, ensure that the function validates the caller's authorization before providing any information about the blocking status.

Assessed type

Access Control

[141345]

maybe by design it is allowed

QA might be more appropriate.

[vicnaum]

Having blocking on-chain assumes the data is public for anyone, even if we have access control for isBlocked function - you can still see the events, storage and transactions on-chain. So I would say it's "by design", cause there is no other way of making it private, even if you use ZK for that - you can still simulate a transaction on-chain and know that some profile reverts while interacting with other which reveals the blocking information.

[c4-sponsor]

vicnaum marked the issue as sponsor disputed

[c4-judge]

Picodes marked the issue as unsatisfactory: Invalid