Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

QA Report #31

Open
code423n4 opened this issue Mar 31, 2022 · 2 comments
Open

QA Report #31

code423n4 opened this issue Mar 31, 2022 · 2 comments
Labels
bug Something isn't working QA (Quality Assurance) Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax

Comments

@code423n4
Copy link
Contributor

QA Report

Recommendations

  • Upgrade to 0.8.0 or above so that you don't need to use SafeMath and overflow/underflow is checked by default. This will prevent accidental, unchecked arithmetic expressions creeping into the code base.

Low: Don't use safeApprove since it has been deprecated

Impact

There is a use of safeApprove in LenderPool.sol on line 335.

OpenZeppelin have deprecated this function here. A deeper discussion of the issue can be found in this GitHub Issue.

Recommended Mitigation Steps

The general advice is to use calls to safeIncreaseAllowance or safeDecreaseAllowance instead. In this particular case one would need to determine whether the allowance was being increased or decreased by first calling IERC20's allowance function and comparing the result to the _amount parameter of function _accept.

Out of Scope: Outline of an attack that could be carried out even if smart contracts have no bugs

The attack I will outline is outside the scope of this audit competition. However, it could be carried out even if the smart contracts had no bugs.

As I understand it, Sublime relies on the linking of online identities to addresses. Examples of such online identities are Twitter/Reddit/Facebook accounts or email addresses. Verifiers will be tasked with performing the verification of identities off-chain.

The problem I see is that creating multiple false identities is not particularly hard. It is certainly much easier than creating a false identity that would be recognised in the physical world. e.g. by a nation's government.

One might counter this phenomenon by only lending small amounts of money to online identities that had not established much of a reputation. One would then expect that only those identities that developed a good reputation -- by paying back their loans -- would be given further loans by the lending community.

However, this immediately reminds me of a well-known Stock Pick Scam. I outline this scam in the next section.

An outline of the Stock Pick Scam

A large collection of email addresses is required. Let's choose 10000 for our example. Next:

  1. Choose a random stock
  2. To half the email addresses send them an email telling them you think the stock will go up. To the other half send them an email telling them you think the stock will go down.
  3. Wait a few weeks. Discard the half of the email addresses for which your prediction did not hold. For instance, if you sent an email to half of the email addresses saying the stock will go up but, in fact, it went down, then discard those email addresses.

We are now down to 5000 email addresses. Now repeat steps 1-3. You will now be down to 2500 email address. Continue this process for a few more steps. You will now have a much reduced set of email addresses for which you know the following is true: they will have received several stock pick predictions all of which came true.

For this small set of email addresses you now announce that they have received the limit of free stock predictions and they must now subscribe to your (expensive) Stock Pick Newsletter to receive more. The hope is that at least some of them, impressed by your track record, will hand over the money.

An analogous attack within a reputation-based lending community

Now that I have outlined the Stock Pick Scam I would like to suggest an analogous attack in a reputation-based lending community that uses online identities.

First cultivate many false identities for some period of time so that they have at least a semblance of authenticity. For each of these identities first get verified by verifier and then approach the lending community for a small loan.

With the money from each loan use it to gamble. Use a smart contract that allows you to gamble according to the rules of Roulette (e.g. https://crypto.games/roulette/ethereum).

For half of the loans put the money "all on red". For the other half put it "all on black".

You will win about half the time, and lose about half the time. Simply default on the half loans for those time you lost. And for the games of Roulette you won money on use the proceeds to repay those loans.

This will have the effect of increasing the reputation of those particular (false) identities. Now repeat the process several more times. You will be left with only a small number of identities with a good reputation but they will now have a significant track record of borrowing and paying back their loans.

It is likely that this will allow them to ask for even larger loans in the future which they can default on if they choose since the identity is, after all, false.

Recommended Mitigation Steps

I have not yet thought of a way to mitigate this problem.

The problem with loans that are only tied to online identities is that the only way to punish defaulters is to stop lending them more money. In the physical world, where it is much harder to create a false identity, the loss of reputation is much harder to escape. Further penalties such as jail time can be applied for serial offenders (or first time offenders that defrauded enough money).

Mitigating this issues in an online environment will require a lot of careful consideration.

@code423n4 code423n4 added bug Something isn't working QA (Quality Assurance) Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax labels Mar 31, 2022
code423n4 added a commit that referenced this issue Mar 31, 2022
@ritik99
Copy link
Collaborator

ritik99 commented Apr 13, 2022

Appreciate the scenario/example described! We agree that using online identities incurs the risk of impersonation/Sybil attacks. The architecture has been built to consider the possibility that different methods of verification might work for different sets of users. For eg, for a DAO trying to delegate a line of credit to its members, verifying their Twitter identities would provide a high degree of authenticity, while at the same for a fintech company trying to verify its lenders, simply using Twitter identities won't make the cut. At the same time, some others might wish to interact entirely anonymously (by creating a direct line of credit, the contracts for which weren't a part of this audit scope). We're working to onboard different kinds of verification/verifiers to provide diversity (including stringent KYC/AML checks too).

What we wished to accomplish is to provide options for both lenders and borrowers to finetune their participation to match their risk appetite.

@sseefried
Copy link

sseefried commented Jul 30, 2022

This was my first contest but I only just got to see this. Glad it was food for thought.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working QA (Quality Assurance) Assets are not at risk. State handling, function incorrect as to spec, issues with clarity, syntax
Projects
None yet
Development

No branches or pull requests

3 participants