MIP64 - Bug Bounty Program for MakerDAO Critical Infrastructure

MIP64: Bug Bounty Program for MakerDAO Critical Infrastructure

Preamble

MIP#: 64
Author(s): @travinimmunefi
Contributors: @psychonaut
Tags: cu-is-001, bug-bounty
Status: Formal Submission
Date Applied: 2021-12-08
Date Ratified: <yyyy-mm-dd>
Forum URL: https://forum.makerdao.com/t/mip64-bug-bounty-program-for-makerdao-critical-infrastructure/12096

Sentence Summary

MIP64 establishes the bug bounty program for critical infrastructure of MakerDAO on Immunefi managed by the Immunefi Security Core Unit (IS-001).

Paragraph Summary

MIP64 is part of the ongoing fulfillment of one of the mandates of the Immunefi Security Core Unit (IS-001). The part which it fulfills is “Bug Bounty Program”, where IS-001 will orient its growing community of security researchers on the Immunefi bug bounty platform towards the Maker ecosystem. The program will attract whitehat hackers who find vulnerabilities and responsibly disclose them, so they are fixed before they can be exploited. Additionally, this provides an incentivized opportunity for disclosure of vulnerabilities instead of exploitation for blackhat hackers.

Component Summary

MIP64c1: Overview
MIP64c1 gives an overview of the Bug Bounty Program for MakerDAO Critical Infrastructure

MIP64c2: Scope
MIP64c2 defines the scope of the program (assets to be covered, impacts, out-of-scope vulnerabilities, etc.)

MIP64c3: Rewards
MIP64c3 establishes rewards by asset impacted and severity of the impact

MIP64c4: Rules and Eligibility
MIP64c4 defines the rules of the program and the elegibility criteria for participants

MIP64c5: Payment Process and Budget Request
MIP64c5 describes how payments are to be carried out

MIP64c6: Postmortems and Fixing of Bugs
MIP64c6 goes into some detail about the postmortem process and the fixing of bugs

MIP64c7: Bug Bounty Launch Process
MIP64c7 describes the PR efforts that will ensue upon the approval of this proposal

Motivation

With the extensive growth of the DeFi ecosystem, as well as crypto as a whole, comes greater threats. Though a significant increase in both community sizes and funds within the ecosystem indicates a maturing environment, the glitter of success also attracts nefarious individuals and groups seeking to damage the ecosystem in exchange for their own personal gains.

With MakerDAO not only being one of the largest ecosystems in the space but also a pioneer in the push for decentralization, it is a prime target for these nefarious people. Through this bug bounty program, in addition to its other activities, IS-001 aims to to prevent, or, at the very least, minimize the negative effects of their intended actions.

Specification

Note: The information presented in this section, and more, will be available as permanent documentation together with the Immunefi Security Core Unit at https://immunefi.makerdao.network as part of our transparency reporting. It will be kept up-to-date even after the publication and approval of this MIP.

MIP64c1: Overview

The Immunefi Security Core Unit will orient its growing community of security researchers on the Immunefi bug bounty platform towards the Maker ecosystem. Leveraging its expertise with bug bounty programs across the cryptocurrency space, especially the DeFi ecosystem, IS-001 will create and propose a bug bounty program to economically incentivize further investigation of the code.

The program will attract whitehat hackers who find vulnerabilities and responsibly disclose them, so they are fixed before they can be exploited. Additionally, this provides an incentivized opportunity for disclosure of vulnerabilities instead of exploitation for blackhat hackers.

In order to achieve this, IS-001 will:

  • Continuously coordinate with various Core Units in order to identify the scope of assets as well as impacts to ensure that bugs reported are those that are valuable to the ecosystem.
  • Maintain the program by incorporating additional content where needed, such as additional requirements for submissions, restrictions, and information; adding and removing scope as needed; and including various improvements from knowledge gained through the operation of the overall Immunefi platform. If necessary, IS-001 will create separate bug bounty programs for different areas, for example smart contracts vs. cloud infrastructure.
  • Triage all vulnerability reports together with ChainSecurity and escalate to the appropriate Core Unit as needed.
  • Publicly report all critical vulnerabilities after all fixes have been implemented and verified in the format of a postmortem, and respond to inquiries from the community.

MIP64c2: Scope

Assets to be Covered

The assets considered as in-scope of the bug bounty program will be those that are identified as critical infrastructure to the Maker ecosystem by IS-001. The Core Units that manage these assets would be regarded as stewards to their respective assets. Other assets that are created by Maker ecosystem entities that are not core units may be included in the bug bounty program at the discretion of IS-001. These modifications may be done during the lifespan of the bug bounty program, to account for changes in the Maker ecosystem.

Severity Classification and Accepted Severity Levels

All rewards for bug reports will utilize the Immunefi Vulnerability Severity Classification System as well as considering new standards proposed by Immunefi. Based on the feedback from the associated Core Units, customizations of this system may be adopted for particular assets.

In general, severity levels from Low to Critical for smart contracts and Low to Critical web/app assets will be accepted for the bug bounty program. Some levels may be unavailable for some assets depending on feedback from steward Core Units responsible for those assets. Other severity levels will not be considered by default due to historical data of those severity levels not being considered impactful enough for most clients of Immunefi and an overall greater expense on resources to address the vulnerability compared to an impact an exploit would create. However, the community would not be barred from communicating such reports directly to the steward Core Units or Core Units outside of the bug bounty program.

IS-001 may choose to adopt a new severity system if it deems it to be better for the bug bounty program.

Accepted Impacts

Only the following impacts would be considered as in-scope for the bug bounty program. All other bug reports of course may still be reported directly to the respective Core Units outside of the bug bounty program.

Smart Contracts

  • Loss of user funds staked (principal) by freezing or theft
  • Loss of governance funds
  • Theft of unclaimed yield
  • Freezing of unclaimed yield
  • Temporary freezing of funds for at least 5 blocks
  • Unable to call smart contract
  • Smart contract gas drainage
  • Smart contract fails to deliver promised returns
  • Vote manipulation
  • Incorrect on-chain polling actions (e.g., user votes yes but it’s registered as no)

Websites and Applications

  • Leak of sensitive user data
  • Deletion of user data
  • Redirected funds
  • Direct theft of funds
  • Site takedown
  • Accessing sensitive pages without authorization
  • Injection of text
  • Users spoofing other users
  • Gaining shell access on server
  • Vote or voting result manipulation, including display
  • Blocking access to users when they should have access

Out-of-Scope Vulnerabilities and Impacts

The following vulnerabilities and impacts will be considered out of scope of the bug bounty program and will not be eligible for a reward:

  • Attacks that the reporter has already exploited themselves, leading to damage
  • Attacks requiring access to leaked keys/credentials
  • Attacks requiring access to privileged addresses (governance, etc.)
Smart Contracts and Blockchain
  • Incorrect data supplied by third party oracles
  • Not to exclude oracle manipulation/flash loan attacks
  • Basic economic governance attacks (e.g., 51% attack)
  • Lack of liquidity
  • Best practice critiques
  • Sybil attacks
  • Centralization Risks
Websites and Apps
  • Theoretical vulnerabilities without any proof or demonstration
  • Content spoofing / Text injection issues
  • Self-XSS
  • Captcha bypass using OCR
  • CSRF with no security impact (logout CSRF, change language, etc.)
  • Missing HTTP Security Headers (such as X-FRAME-OPTIONS) or cookie security flags (such as “httponly”)
  • Server-side information disclosure such as IPs, server names, and most stack traces
  • Vulnerabilities used to enumerate or confirm the existence of users or tenants
  • Vulnerabilities requiring unlikely user actions
  • URL Redirects (unless combined with another vulnerability to produce a more severe vulnerability)
  • Lack of SSL/TLS best practices
  • DDoS vulnerabilities
  • Attacks requiring privileged access from within the organization
  • Feature requests
  • Best practices

MIP64c3: Rewards

The default rewards based on the type of asset impacted will be as follows:

Smart Contract

Severity Level Reward
Critical Up to USD 10,000,000
High Up to USD 100,000
Medium USD 5,000
Low USD 1,000

Critical smart contract vulnerabilities will be further capped at 10% of economic damage, which primarily takes into consideration the funds at risk. In cases of repeatable attacks, only the first attack is considered unless the smart contract cannot be upgraded or paused. However, there is a minimum reward of USD 150,000 such that the reward amount is above that of High. Additionally, a high minimum reward helps prevent hackers from sitting on a bug report while potential economic damage increases.

High smart contract vulnerabilities will be further capped at up to 100% of the funds affected. In the event of temporary freezing, the reward doubles for every additional 5 blocks that the funds could be temporarily frozen, rounded down to the nearest multiple of 5, up to the hard cap of USD 100,000. This is implemented in order to account for the increased relative impact based on the duration of the freezing of funds.

Websites and Applications

Severity Level Reward
Critical Up to USD 100,000
High USD 5,000
Medium USD 2,500
Low USD 1,000

Critical website and application bug reports will be rewarded with USD 100,000 only if the impact leads to a direct loss in funds or a manipulation of the votes or the voting result, as well as the modification of its display leading to a misrepresentation of the result or vote. All other impacts that would be classified as Critical would be rewarded no more than USD 50,000.

MIP64c4: Rules and Eligibility

Rules

All bug bounty hunters will be bound by the rules on Immunefi. Additionally, all bug bounty hunters must not perform any of the following, otherwise they lose eligibility for receiving a reward:

  • Any testing with live pricing oracles or third-party smart contracts
  • Attempting phishing or other social engineering attacks against our employees and/or customers
  • Any testing with third-party systems and applications (e.g., browser extensions) as well as websites (e.g., SSO providers, advertising networks)
  • Any denial of service attacks
  • Automated testing of services that generates significant amounts of traffic

Eligibility

Bug reports from compensated team members of any MakerDAO Core Unit will not be eligible for a reward. Employees and team members of third-party suppliers to Core Units that operate in a technical capacity and have assets covered in this bug bounty program will also not be eligible for a reward. All team members of IS-001, and its third-party suppliers, including Immunefi Services itself, are not eligible for a reward.

Bug reports from team members and third-party suppliers of businesses and organizations that are not a MakerDAO Core Unit but have assets considered as critical infrastructure covered under the bug bounty program are also not eligible for the bug bounty program.

Bug Report Requirements

In addition to the standard bug report information requested by Immunefi in its bug submission page, a runnable proof of concept (PoC) will be required for all smart contract bug reports. Exceptions may be made in cases where the vulnerability is objectively evident from simply mentioning the vulnerability and where it exists. However, the triaging team will make this determination and may at its discretion require a PoC from the bug reporter.

All website and application bug reports will require a PoC.

Triaging Process

Initial triaging will be provided by Immunefi Services through IS-001. The triaging team will not only filter out spam but also determine the likelihood of the bug report being legitimate enough for further consideration by an entity more deeply familiar with the Maker software. For smart contract vulnerabilities, the bug report would then be escalated to ChainSecurity to provide additional emergency triaging. Afterwards, and for website and application vulnerabilities, if the bug report appears credible, then it is escalated to the steward Core Unit.

Bug Validation Process

The steward Core Unit receives a credible bug report and determines whether there is a true vulnerability. If not then an explanation is returned to the bug reporter. Otherwise, the Facilitator of the Core Unit must accept the bug report and confirm its severity level in the bug report dashboard.

MIP64c5: Payment Process and Budget Request

The payment process is triggered once the steward Core Unit approves the bug report as valid, as IS-001 and ChainSecurity, if relevant, have already signed off on the bug report by that time. A fix does not necessarily need to be implemented before the payment is released. However, payment may be delayed if the announcement of a payout draws unwanted attention to the existence of a vulnerability.

All payments are paid out in DAI, assuming a full 1:1 ratio with the USD. However, if the price of DAI deviates from the USD value by more than 1%, the amount of DAI will be adjusted. All payments are made directly by executive spell proposed by IS-001 in accordance with the executive vote implementation process with no middleman involved to hold funds. Thus, the transfer is made directly to the bug bounty hunter. If any transfer results in exhaustion of the surplus buffer, then flop auctions will recapitalize the system. Therefore, no upfront budget allocation is required for this MIP.

In order to keep the amount of executive spells to be created to a manageable level, all verified bug reports eligible for a reward in one calendar month will be bundled into one executive spell in the first week of the next calendar month. Further exploration to optimize the payout process will be done by IS-001 in order to make the bug bounty program more attractive to bug bounty hunters and to reduce operational overhead in terms of payouts relevant to the size of the payout. Additionally, the format of the executive spell proposal will be the same with MIP14c2 in order to maintain clarity and uniformity.

For bug bounty rewards over USD 1,000,000, after the first million is paid out, the remaining amount is paid out over time with up to USD 1,000,000 per consecutive month until the determined amount for payout is reached.

As its standard fee, Immunefi will charge the DAO a performance fee based on the reward paid out to the bug bounty hunter, charged on top of the reward. Per vulnerability, the first USD 5m paid out would be charged with the standard 10% fee. Any amount over USD 5m paid out will be charged with a discounted 8% fee. For example, a bug report that pays out USD 9m would have a fee of USD 5m * 10%, which would be USD 500k, added to USD 4m * 8%, which would be USD 320k, resulting in a net fee of USD 820k. Immunefi will charge no onboarding or maintenance fees. The first payment to the bounty hunter and Immunefi will be sent in the same executive spell. In the event that the Immunefi fee is over USD 500,000, the first USD 500,000 will be paid in the same process with the bug bounty hunter and the remaining will be paid out in the next month.

MIP64c6: Postmortems and Fixing of Bugs

Postmortem Process

All Critical and High bug reports will have a postmortem written by Immunefi to be published on the Immunefi Medium blog and distributed on its social media channels after the payout is made and the fixes finalized. The identity of the bug reporter may be included, either with their real name or pseudonymously, if they choose to, or they can choose to remain anonymous. Contents of the postmortem will include details about the vulnerability, the fix applied, as well as the impact should the vulnerability have been exploited.

Fixing of Bugs

The process for fixes to be implemented will be determined depending on the asset impacted and the severity of the bug. For smart contract vulnerabilities, Chain Security will be consulted to verify if the fix addresses the vulnerability discovered. Implementations of fixes with spells will focus on overall security in order to prevent public leakages and inadvertent exposure of the vulnerability.

MIP64c7: Bug Bounty Launch Process

If this proposal is approved, a bug bounty program will be launched by the end of February 2021 replacing the bug bounty program currently on HackerOne. PR efforts will be performed by Immunefi on its own channels such as its Twitter account, Medium blog, Discord (refreshing invite link found on https://immunefi.com), and Telegram announcement channel. Additional PR efforts will also be performed by its PR team with appropriate PR work done in early February in order to maximize potential impact. Coordination with other Core Units will be done as needed.

6 Likes

Just a quick follow-up. Why is this important? DAI is DAI, all DAO members and most DeFi folks are in it for DAI—why is it important to provide a 1% slippage as a reimbursement coverage policy? Can you please explain the logic behind this incentive? Are you looking to recruit folks like hackerone who usually get paid in USD?

2 Likes

Suppose a whitehat earned a bounty while at the same time, for whatever reason, DAI was 2% below peg. These could be totally unrelated events. Maybe governance is trying to raise the DAI savings rate. So the idea is that the whitehat would be paid in the USD equivalent of DAI if DAI was off peg. It’s symmetric so the same goes for DAI being 2% above peg.

I don’t think this situation is very likely. We’re just trying to cover all the bases.

1 Like

More important though, is when it is related: if the bounty is denominated in DAI and the bug is likely to affect the price of DAI negatively, the hacker may be discouraged to submit the report because they will be paid in them.

General principle of not relying on the system that might be broken in these extreme circumstances.

8 Likes

Input and a critical look from the engineering core units will be highly appreciated for this MIP.

Please note that this bug bounty program will replace the current one on HackerOne.

@Protocol-Engineering @Oracles-Core-Unit @collateral-core-unit @dux-core-unit @sidestream-core-unit @starknet-core-unit @simonkp @dumitru @georgen

4 Likes

I want to submit my reports but I can’t see the program available on immunefi.

2 Likes

Yeah, this is just a proposal. We hope the program will be live next month.

1 Like

If you want to submit reports now, you can still use the current MakerDAO bug bounty program over at HackerOne.

Thank you for this MIP. A couple of questions on my side @TravinImmunefi , @psychonaut

  • How are amounts going to be decided/allocated? Up to $10mn for a critical security breach leaves quite some margin
  • Is there a plan to have a similar program on testnet? That would be interesting and would be a good complement to audits

In any case, I think that it makes sense in the context of the wormhole to have a bounty program that’s covering the entire scope of the wormhole (i.e., across all domains involved). It does not make a lot of sense for Starknet for example to have a bounty program in a vacuum of the other domains, because Starknet in a vacuum cannot perform the wormhole functionalities (fast withdrawal, teleportation).

1 Like

Thanks for the quick questions! Sorry for my late reply. Trying to catch up to things after some medical issues, though recovering :slight_smile:

Adding further to the other replies here

Why is this important? DAI is DAI, all DAO members and most DeFi folks are in it for DAI

Because this bug bounty program is also going to be targeted to those not within the Maker ecosystem, and actually, those who are heavy into DeFi, the desired determinant is in USD and not DAI, or any other coin. We want to make sure that this bug bounty program is not just open but also attractive to those who are outsiders. Other bug bounty programs on Immunefi as well that pay out in a stablecoin (usually USDC) have the amounts stated in USD, that way in case the peg with USDC breaks, the reward amount to the bug bounty hunters stay the same. It’s usually the same as well, though with some exceptions, with projects that pay with their own token.

Are you looking to recruit folks like hackerone who usually get paid in USD?

Yes. Among others that are on Immunefi who expect payouts based on USD amounts in most cases.

1 Like

Thanks for your questions Louis!

How are amounts going to be decided/allocated? Up to $10mn for a critical security breach leaves quite some margin

This will be calculated based on the impact that could be done, with a scaling rate of 10% of economic damage, which primarily takes into consideration the immediate funds at risk. For example, if someone could permanently freeze $50mn worth of funds, then their reward would be $5mn. Bug bounty hunters would be required to provide a runnable PoC, so this is generally quite objective in terms of calculating the reward.

Is there a plan to have a similar program on testnet? That would be interesting and would be a good complement to audits

It’s generally not recommended to have a bug bounty program while audits are running. This runs the risk of paying double for a discovered vulnerability. It’s not unheard of though to have a bug bounty program for post-audit stuff still on testnet, and we’ll definitely consider onboarding those that have finished the audit and are identified as critical infrastructure.

In any case, I think that it makes sense in the context of the wormhole to have a bounty program that’s covering the entire scope of the wormhole (i.e., across all domains involved). It does not make a lot of sense for Starknet for example to have a bounty program in a vacuum of the other domains, because Starknet in a vacuum cannot perform the wormhole functionalities (fast withdrawal, teleportation).

Definitely happy to take this discussion forward!

2 Likes

Thanks to everyone who’ve provided feedback so far!

I’ve now implemented the following changes:

  • More specific title, in case other bug bounty programs will be created for non-critical infrastructure.
  • Added flexibility for modifying the severity classification system, in case Immunefi discovers needed improvements as the space evolves.
  • Added flexibility for assets in the bug bounty program to account for the growth in the ecosystem.
  • Added information about the launch process and steps if the MIP is approved.
  • Added information about the process for implementing fixes.
1 Like

Thanks again to everyone for the continued feedback and support. I’ve now updated this with the following changes:

  • Modified the the MIP numbering to 64
  • Added further details with regards to the payout process
1 Like

How would we be determining the price of DAI relative to USD? Is there a reason we aren’t going DAI denominated for the payouts?

I agree that ensuring the payout is 1:1 ratio with the USD is confusing and potentially troublesome. Wouter is the main advocate.

Noticing a lot of chatter on TG saying the Polygon bounty payout to whitehat Leon Spacewalker for $2.2M was peanuts for an $18B exploit. Should have been somewhere around $180M and this “low” reward will only encourage whitehats to go blackhat — what are your thoughts—was it sufficient?

1 Like

This will be a work in progress, but we need to get the program started. Hence, we hereby formally submit MIP64 to the Jan gov cycle. @blimpa

1 Like

Hey ElProgreso,

Sorry for the delayed response.

It was quite interesting seeing that chatter, as usually people tend to focus on the part of someone breaking our all time high in terms of bug bounties rewarded. However, it’s not too surprising given that the funds at risk and the reward amount is quite far apart. The largest difference we’ve had until then was one where 60000 ETH was at risk and the reward was USD 800 000. There were other circumstances at the time though, documented in the linked article, that made things a bit more understandable, so there was less chatter about it.

It’s a bit difficult to say how much they should’ve been paid, as there are quite a lot of factors involved here, and given the size and potential impact beyond the direct funds that could’ve been stolen, opinions are going to vary widely. The factors I’m talking about that impact how much could be paid involve team budgets, ability of the project to pay, and how much the hacker could get away from it. With the first two, it becomes important to consider how much a project could pay without damaging itself too significantly. When the payout is in the project token, or something connected to the project, this becomes even more important, as it affects the final payout amount and the ability for the hacker to realize their reward.

As for how much the hacker could get away with it, we generally recommend 10% of the funds at risk, as we’ve determined this to be generally the amount blackhats end up getting away with, after all the difficulties of money laundering in crypto. (Note that putting it into Tornado Cash or something like that does not mean that the job is done!) This was further justified when some hackers blatantly asked to keep 10% or stated that they wouldn’t have stolen funds if they could’ve gotten a reward of 10% of what they could’ve stolen. However, the data that we have on this is incredibly smaller than the amount of funds that were at risk here that we begin to question whether the data still holds true. That Polygon bug represents about 90% of ALL possible economic impact damage prevented on Immunefi since we started operations in December 2020. To add on to that, all of DeFi combined lost about $14bn last year, $4bn less than this single bug. Because of this massive difference on top of the ability-to-pay problem, I cannot confidently say what would’ve been suitable.

Of course, it would’ve been great for us if it was fully scalable and then the hacker would’ve gotten $1.8b and Immunefi would’ve then gotten 10% of that, $180m as our fee. I would certainly have been very happy!

Overall, this is something we’re looking at closely and investigating more, but this isn’t easy. With $10m, MakerDAO would be our top bug bounty program by far, which I’m certain would attract a lot of whitehat hackers. As for blackhats though, we will definitely need to investigate further. It was already tough back in the day to justify the 10% after limited data on blackhat activity, so this takes it to not just another level but another league. We’ll continue to monitor these types of scenarios though, as well as activity on the MakerDAO bug bounty program, and make proposed amendments as necessary, with as much transparency on the data as possible so that the community can understand our justification.

2 Likes