BGD. Retroactive bug bounties proposal (pre-Immunefi)

Development
1

TL;DR

Request for bounties pending from before the setup of the Aave <> Immunefi official bug bounty program, amounting a grand total of $86’500.


Context

Before the setup of the Aave <> Immunefi bug bounty program on September 25th 2023, security reports by white hats where evaluated in an ad-hoc basis, proposing bounties/rewards following an approach like on this proposal. That was not optimal, as there was no formal scope defined, or strict ranges of bounties depending on severity and impact.

Currently, every report is being processed via Immunefi and the rules of the Aave program, however, there were other reports submitted via other channel before that (usually security@aave.com). As these reports should be evaluated at time of submission for fairness, and outside of the Immunefi scope defined afterwards, we think it is a good idea to reward them separately and retro-actively outside the program.


Reports

First of all, we want to clarify certain aspects for the community:

  • The proposed rewards and evaluation metrics follow the ones we did ad-hoc in the past HERE, as we don’t think it is fair for the white-hats to apply the rewards ranges on the current Immunefi program and out-of-scope rules, as they were defined afterwards.
  • In one of the cases, we recommended the white hat to submit the report via Immunefi, in order to have access to the mediation procedure of the platform. As this mediation process was finally requested by the white hat, Immunefi charges the corresponding fee of 10% of the amount, which we think is legitimate.
  • At the moment, we are not disclosing the full details of some of the reports, because even if none of them create any risk for Aave now, one has dependencies with another report (not disclosed yet) and the other could increase risk to non-Aave entities.

1. Inconsistent validation on Aave v2/v3

When calling borrow() with stable rate mode on Aave v2 and v3, one of the validations is that not more than a percentage of the total available liquidity can be borrowed at once.

However, swapBorrowRateMode() doesn’t validate the same, which is unexpected and could lead to more stable rate borrowings than intended.

It is important to highlight that this is not possible at the moment, with minting of stable rate disabled.


Reported by: @StErMi

Severity: :large_blue_circle: Low

The issue didn’t create any immediate problem in the protocol, but overexposure to stable rate mode is not expected.

Likelihood: :red_circle: Certain

This problem was present on the deployed versions of Aave v2 and v3, on those assets with stable rate enabled.

Proposed bounty: 10’000 USD



2. Inconsistent HF (Health Factor) behaviour swap borrow rate mode

When swapping borrow rate mode, the HF of an user is not validated, as debt should remain the same. However, under edge scenarios, the HF of an user could slightly change (by ~1 unit of lowest asset’s decimals).


Reported by: @StErMi

Severity: :green_circle: No impact

This is not a bug or creates any exploit scenario, but it is unexpected behaviour.

Likelihood: :red_circle: Certain

This problem was present on the deployed versions of Aave v2 and v3, on those assets with stable rate enabled.

Proposed bounty: 5’000 USD



3. Price manipulation of asset listed on Aave

By executing a complex strategy (involving compromising the asset’s trusted infrastructure), it could be possible to inflate the price of one of the assets listed on Aave v2.

Even if this belongs more to the centralisation risk of the asset, and we don’t consider a bug of the protocol, it was taken into account for off-boarding consideration of the asset by risk providers of Aave, and we believe it is fair to reward retro-actively.

As this risk still exist on the asset itself and more protocols could be using it, even if we don’t really see any immediate risk, we will not be disclosing at the moment details of it, until the team applies extra measures.


Reported by: @RobertMCForster

Severity: :red_circle: Critical

Being a price manipulation, the impact on the protocol would hypotetically be important.

Likelihood: :large_blue_circle: Not likely

The attack involves compromising asset’s infrastructure (which would directly disqualify on the current Aave <> Immunefi program), together with extra techniques; so we consider it theoretically possible, but highly improbable.

Proposed bounty: 65’000 USD. Additionally, 6’500 USD as Immunefi fee.



Next steps

During the next days, we will create an ARFC Snapshot, for the approval of the rewards by the community. If positive, afterwards we will proceed with an on-chain governance proposal, releasing the funds to the corresponding addresses.

6 Likes
2

Hey all,

I’m on the team that found exploit #3 a while ago. I appreciate/accepted the recommendation but don’t believe $65k should be the full reward considering the magnitude of the exploit. I’ll be asking the DAO for $300k total but I’ve been told by BGD that I can’t give any information on the exploit to the DAO or they’ll instead suggest $0.

I reported the exploit long ago to any major protocol using the asset so it shouldn’t be any problem to disclose it (and probably a good thing at this point so new protocols know not to use the asset), but will not be breaking the rules set by BGD Labs.

Not sure exactly how to proceed since it’s hard to explain why I feel more should be paid out without disclosing the bug, but I feel I need to say something now or the DAO won’t be interested in the future after it’s already paid out.

2 Likes
3

For transparency with the DAO:

  • As reviewers of the Aave bug bounty program, our duty is to 1) follow the rules of the approved bug bounty program and 2) in special cases like #3, try to be fair with the white-hat reporting, in order to keep a high bar of quality on behalf of the Aave DAO.
  • #3 would be out-of-scope following the bug bounty program (as we commented, involves compromising a wallet of an asset’s trusted infrastructure), but given the report was submitted before the problem setup, our criteria is to still propose a reward. For extra context of the community, there has been reports of similar nature post-Immunefi, evaluated out-of-scope, so we firmly believe the reward is more than fair, and only justifiable due to the really special scenario.
  • We requested non-disclosure, because, 1) we still believe is not responsible to expose the details of an attack 2) same as we fairly evaluated the report based on time on submission, following some standard communication guidelines seems reasonable.
  • Same as we as reviewers should maintain the discussions with white hats on Immunefi private, we think it is totally inappropriate and unprofessional to try to use the separation between the Aave DAO and reviewer entities in the Immunefi program in order to negotiate bounties, and it sets a terrible precedent. For extra context, if this would happen with any current report or in the future, it would mean direct breach of rules.

As it is our responsibility to be objective, we will proceed with the originally proposed reward.
But given that this is not the first incident on this report, we will consider any further disclosure and/or discussion outside the Immunefi platform as a breach of rules of the Aave bug bounty program, with immediate disqualification to any kind of reward.

3 Likes
4

With the ACI we fully support this statement, to be honest @RobertMCForster this kind of behaviour is unacceptable and you’re quite lucky BGDlabs and not the ACI is leading this.

We will support initial proposal, any other proposal will receive a frank NAY vote from us.

2 Likes
5

What? I was told I could talk to the DAO if I disagree with their decision and BGD was explicitly aware I was going to.

[had screenshot here of those messages but I’m not sure if I’m allowed to send]

I’m trying to play by all the rules here. They did not want me to talk about the exploit yet so I am not doing that but I was under the impression this would be perfectly fine.

6

Frankly I’m a bit offended by how I’ve been talked to in this thread when this is the exact course of action I was told to take.

This is a prime example of why I was asking for the public to be able to verify what BGDLabs recommends is fair and how the DAO wants to approach bug bounties for the amount we helped Aave.

Because you’ve asked me not to, I’m not talking about the exploit, not saying anything about the ImmuneFi process or findings, and not negotiating anything about the bounty right now.

I just believe that since Aave is a real DAO it’s necessary for there to be a notice that I will be or else once BGD decides the DAO can be told it’ll already be long forgotten and I’ll have little to no ability to.

2 Likes
7

Following the plan, we have created an ARFC Snapshot for the community to pre-authorise the payment, before going to the on-chain AIP step.

Participate :ghost:

https://snapshot.org/#/aave.eth/proposal/0x67fa557b990018a7d438aca3991c01ff503d82f559db027c8dada969d4f149d4

8

The results of Snapshot for this proposal were the following:

  • [FOR] ~313’000 AAVE
  • [ABSTAIN] ~177’000 AAVE
  • [AGAINST] 12 AAVE

Even if not crossing 320’000 FOR (on-chain governance threshold), the support side was solid, with almost no opposition.
We understand that the Abstain votes are mainly on the circumstances around the third bounty proposed, but from our side, we still recommend the community to reward the white-hat contributions, especially given that lack of proper bounties setup/definition was an important factor here.

Consequently, we will proceed with an on-chain governance proposal for the payout of the 3 bounties. For clarification the two first will be transferred to the same address, as they were disclosed by the same white-hat, while the third will go to a different recipient.

4 Likes
9

It looks like the governance proposal doesn’t correspond to what passed on Snapshot and the 3rd bounty was excluded. Have you decided to do it in 2 separate votes rather than what people voted on with the Snapshot?

The reasoning given for splitting them up was because of “interdependencies”, but this exploit was fixed nearly 10 months ago now. I see no reason to deviate from the Snapshot?

1 Like
10

@RobertMCForster the other proposal has nothing to do with the rewards proposed here.

Given that technically the requirements on Snapshot have not been fullfilled, we are simply waiting some extra days for if there is any opposition from the community.
If not, we will proceed to create the proposal early next week.

As we commented previously, we are still (and from the beginning) supporting the community granting the reward, but please, respect that there are certain governance procedures and good practises that we need to follow.

3 Likes
11

(responded on the other thread but will also here)

Gotcha, sounds good. Was just a misunderstanding in that case since the 2 bounties were the same amount as the 2 bounties here and it was mentioned the governance proposal was being made soon.

1 Like
12

With the ACI, we strongly stand against settling precedence on not following governance framework rules.

A lack of 320k YAE votes quorum means a proposal has failed, that is definitive.

But we agree the two first bounties should not be collateral damage to the third one and would be supportive of a vote re-run.

We casted a abstain vote on this snapshot because we consider the third bounty and especially @RobertMCForster’s behavior to be controversial, as such, we are supportive of a reduced bounty for bounty 3 to 50k$ to send a clear message.

we’ll push another snapshot vote with 3 “YAE” options to allow governance decision granularity:

Option A : Payout Bounty Bounty 1 & 2 do not Payout Bounty 3
Option B: Payout Bounty 1 & 2 reduce payout of bounty 3 to 50k$; keep immunefi fee same.
Option C: Payout bounty 1, 2 & 3 as originally presented by @bgdlabs

With the ACI we’ll cast an Option B vote.

4 Likes
13

Following governance discussion, an ARFC Snapshot to modify the Retroactive bug bounties proposal (pre-Immunefi) has been published.

Vote will start tomorrow, we encourage everyone to participate.

1 Like
14

I’m sorry, what? Do you even know what the exploit is that you’re trying to lower payment for?

And can you explain what was wrong with informing the DAO I would later be asking for an additional reward once @bgdlabs allowed me to explain how Aave was affected?

BGD literally told me in the ImmuneFi conversation that if I didn’t think it was enough I should bring it up to the DAO, I confirmed I was going to do that once the thread was posted, and they acknowledged that.

From the beginning when I submitted this bug I trusted that Aave cared about security and would be generous with researchers to show future hackers that submitting a bounty rather than taking advantage of it would always be in their best interest.

Now not only have I been publicly insulted about behavior that I was told was the correct course of action, but the DAO is apparently now voting–with no knowledge of what the exploit was–to lower the reward that is already low for the magnitude of the exploit.

Is this really how Aave thinks the people taking risks to protect your protocol and users against threats should be treated?

1 Like
15

This is getting ridiculous and out of hand.
Please let’s all keep our cool and move on.

I would like to make a suggestion being added to the snapshot vote.
Let’s add more options to vote on like

The DAO will decide what will happen in the end. And if the snapshot vote passes, then whatever option wins will move on as an AIP.
And I urge all participants in this thread to respect each other. I think the whole conversation wasn’t good and everybody made mistakes in their communication, so please let us move on and present the DAO as we have been in the past, as a role model in governance.

3 Likes
16

Agreed, it’s getting very ridiculous. But adding another option to the vote only makes it more ridiculous.

This vote is apparently deciding on how much an exploit should be rewarded without the exploit even being public. There’s no way people can make an educated decision on rewarding it more or rewarding it less.

BGD and I are the ones who know the exploit, and we agreed on a $65k payout. I was under the impression it was fine if I asked for more, so I notified the DAO I was going to once I’m allowed to tell my side of the story.

I guess that wasn’t alright and if it’s not allowed I won’t ask for any extra in the future, but to try to lower the reward without even knowing how bad the exploit was because there was apparently a miscommunication in what’s allowed with your DAO is mind-blowing.

1 Like
17

Let’s be clear here.

You’re in this situation because you decided to bypass the program led by DAO-elected service provider @bgdlabs by pure greed because you decided 65k$ was not enough for you.

Doing this sets a terrible precedent, and allowing this kind of nonsense would result in every other guy showing up begging in the forum because their bounty or grant is not good enough for them.

When you were reminded that this DAO has rules, and a service provider already stated what the fair bounty was, you decided to make a drama about it.

As the DAO did vote to not approve your bounty on the first vote, we included the option in the new vote to teach you a 15k$ lesson with a reduced bounty.

If this DAO allows this kind of drama, and people considering themselves above rules to get their way, we’re cooked as a protocol and we’ll just deploy the red carpets to grifters looking for a quick buck.

Instead of learning from his mistakes, @RobertMCForster decided to go on social media and create even more drama. That is simply unacceptable; we don’t care if 100 gremlins are unhappy on X. We’ll vote what’s best for the Aave DAO, and the best option for the DAO’s future is to reduce his bounty.

At the ACI, we don’t take troublemakers kindly, and it seems fair that since we’re settling a precedent here, the precedence should be “Fuck around and find out” of what happens when someone tries to bypass DAO approved process in order to try to extract more money from the Treasury.

The actual bug report is 100% irrelevant in this, I’m not interested to know about it, and no one in this forum is, because we voted for @bgdlabs to handle this on behalf of the DAO and BGDlabs are the guys that wrote this aave protocol and the best suited on this pale blue earth to evaluate a bug bounty report relative to the Aave protocol.

5 Likes
19

I was given explicit permission:

[apparently not allowed to share these screenshots despite Aave saying they’re okay.]

And regarding greed: all of these funds are going to the protocols I work on for funding. We owe employees money for work they’ve done, such as spending time going over Aave’s security. It took us weeks of looking over your code to find the bugs I’ve submitted then months and months of discussion about the bounty. And there was a lot of risk that we wouldn’t find anything at all when deciding to look at your code in the first place.

Funds will also be going toward audits for the protocol we’re about to launch. If we get more than the $65k, we can afford more and higher quality audits. Ideally we’d have money after that as well to hire positions we’re currently lacking to give our dex focused on user safety (Goat Trading) the best chance possible at success.

And yes, of course I went on social media to tell people what I’m dealing with. If I feel I’m being treated unfairly there’s no way I’m just going to stay quiet and accept it. If you have a problem with these discussions being public, it may be worth thinking about why that is.

2 Likes
20

@RobertMCForster no, we stated that after full disclosure of the bug from our side, happening after this proposed payout you will be able to disclose anything you want, and ask for bonus.

It is fairly clear on the screenshots you share with : …timing at our discretion as reviewers, after your payout of course), you will be free to disclose however you prefer, including asking for any type of additional compensation from the DAO.


For the DAO, we re-iterate our stand: we stand with our initially proposed $65k reward, and same for the other bounties.

Afterwards, if the white-hat want to propose any extra bonus, it is not up to us to comment on, as anybody can create Aave governance proposals.
For consistency’s sake, we will stand on our suggested bounty now and in the future, again, as one-off given the circumstances.



P.S. Supposed-to-be private conversations on Immunefi are not to be shared in public. We have no problem in this specific case with the content @RobertMCForster shared, but same as we respect white-hats privacy rights, we would appreciate the same. In addition, this can become a pretty dangerous slippery slope.

5 Likes
21

Fully agree with you about private conversations and I didn’t want to share anything but felt I couldn’t defend myself against these attacks without sharing those.

And understood, that is also how I interpreted it. In my first post on this thread I made it clear that I am not asking now because you do not want me to disclose the details and the DAO can’t make an educated decision without the details being known.

I did feel I needed to make my intentions known with the DAO now though because there was no timeline on when a disclosure would occur, and if a request for additional compensation popped up out of nowhere months down the line it would have no chance at being approved.

Apologies if you meant for this notification to also not be allowed but I was under the impression I was following all of the rules you set.

1 Like