FundsHandlerFacet Manual Review Findings

FHF-01M: Inexistent Validation of Token Type

Type	Severity	Location
Logical Fault		FundsHandlerFacet.sol:L43-L67

Description:

The depositFunds function permits an arbitrary caller to deposit funds available for a particular _sellerId with no form of validation on the caller or input arguments, thereby permitting elaborate phishing attacks to occur whereby a user invokes depositFunds with a malicious token to a particular user's account and when the target user invokes withdrawFunds with the automatic method on, the malicious token balance is automatically withdrawn to the user.

Impact:

By depositing funds to a particular seller prior to f.e. their withdrawal transaction being processed, it is possible to "inject" a malicious token balance the user will withdraw seemingly from the Boson Protocol which will make the funds seem "trustworthy" and potential "bonuses" provided by Boson. This in turn will render phishing attacks easier to execute for unsuspecting users.

Example:

Copy
43function depositFunds(
44    uint256 _sellerId,
45    address _tokenAddress,
46    uint256 _amount
47) external payable override fundsNotPaused nonReentrant {
48    //Check Seller exists in sellers mapping
49    (bool exists, , ) = fetchSeller(_sellerId);
50
51    //Seller must exist
52    require(exists, NO_SUCH_SELLER);
53
54    if (msg.value != 0) {
55        // receiving native currency
56        require(_tokenAddress == address(0), NATIVE_WRONG_ADDRESS);
57        require(_amount == msg.value, NATIVE_WRONG_AMOUNT);
58    } else {
59        // transfer tokens from the caller
60        FundsLib.transferFundsToProtocol(_tokenAddress, _amount);
61    }
62
63    // increase available funds
64    FundsLib.increaseAvailableFunds(_sellerId, _tokenAddress, _amount);
65
66    emit FundsDeposited(_sellerId, msgSender(), _tokenAddress, _amount);
67}

Recommendation:

We advise the function to either permit depositing to existing tokens in the token list of a seller or to utilize some other form of validation method as currently it will turn into a hot-spot for phishing attacks as funds transferred from the Boson Protocol to the user would appear more "trustworthy" than a phishing attempt by directly transferring funds to the user.

Alleviation (44009967e4f68092941d841e9e0f5dd2bb31bf0b):

The Boson Protocol team opted to not remediate the attack vector described at this time given that this relates to user-related activities and has no impact to the protocol. We would like to note that it is possible to completely halt the automatic withdrawal feature (which some external integrators may rely on) by injecting a malicious token that fails on all transfers and as such would cause otherwise expected protocol behaviour to fail. As a result, we retain the minor severity level and set this finding as acknowledged.