Smart Contract Self Triaging

We recommend proceeding through each section outlined in text below, with questions for your review, to help navigate you through the smart contract self triaging process.

The end result of each stage of the self triage assessment should be either:

• valid (proceed to next stage)
• invalid (provide rationale in reply to whitehat + close submission)
• needs more information (reply to whitehat with questions)

If at any time you are in doubt, you are entitled and strongly suggested to contact the whitehat using the dashboard to request more information.

Assess the target

If it is a Github link, identify the deployed contract address using project deployer, list on the project website, provided tx ids, etc..

If it is an Etherscan link, it must be in-scope or damage an in-scope contract. It also must be verified on explorer. Doing so allows for the source code of the contract to be read. The source code, written in Solidity, Vyper, etc., is much more helpful as it is human-readable code. For a deployed smart contract to be trusted, its source code should be available for inspection. It is generally a best practice for projects to publish the source code for the contracts so that users/whitehats can examine the source code before using or testing it.

Assess the severity

The general question we are trying to answer in this assessment is:

What could the attacker achieve by exploiting the vulnerability?

The following is not the complete list of impacts every submission could lead to but instead, is a suggestion guide of how to assess impacts that could lead to the validity of the report.

To assess the base impact, consider the following questions:

• Can user funds be stolen?
• Can contracts be permanently locked or self destructed?
• Can contracts be temporarily locked?
• Can staking/farming rewards be stolen?
• Is it a DoS (unbounded gas consumption)?

During the drafting process, you will be able to decide what impacts fall under the scope of your program, and what severity they would be classified as. However, once the program is launched, we would expect both projects and security researchers to follow that classification for the bug bounty program.

 

 

We have a default Immunefi Severity System that we have compiled based on our experience with handling bug reports in the space. You are free to modify this if needed, but we highly recommend at least using our default as a reference and then making the required edits from there.

If the initially-assessed severity is not assigned a reward for your bug bounty program, close the report as invalid. (For example, a DoS/gas griefing vulnerability is reported Medium, but your bug bounty program only has rewards for Critical vulnerabilities) You will have an opportunity to reassess the severity later in the process.

 

Assess assets at risk

Look at the tokens held - if those tokens are wrapped, unwrap them, recursively, until you find something that has concrete value.

If they are a derivative or synthetic, determine the value based on the underlying asset, recursively.

Look at the typical size of deposits / swaps / withdrawals / etc..

Consider the TVL / market cap.

If your bug bounty program only accepts reports with a specific economic damage, you can reject the report as invalid if there is not enough economic damage. (see the reassess section, below)

Assess difficulty of exploitation

For assessing an exploitation properly, you need to take into consideration various parameters, which may change based on the type of submission you receive. For better assessing the exploitation, Immunefi collected a series of questions to ask yourself.

At any time, you need to match these questions with your own bounty rules and Immunefi general rules. This will help you assess the value of the report you received and understand how urgent it is to address the vulnerability and how to properly reward the whitehat.

Questions to consider:

1. Does it require particular market conditions?
1. Do those conditions currently exist?
2. Did they exist in the past?
3. If TVL/market cap grows, will they exist again?
2. Does it require particular user action?
1. Is that a common user action?
2. Is it an action that automated systems take?
3. Is it only exploitable by a privileged role?
1. Is that role held by an automated system?
2. Is that role held by an EOA or a multisig?
3. Is the role held by a DAO?
4. Can a privilege escalation vulnerability in another contract be abused to acquire that role?
4. Is the attack not profitable for the attacker (griefing)?
1. Include the gas costs of executing the attack
2. How long does the impact of the attack last? Does it need to be repeated to be severe?

All of the above attributes of a bug report could result in downgrading the severity. If the new severity is out of scope for your bug bounty program, you can close the report. (see the section below)

Read the contract source to verify that the vulnerability exists

After identifying the affected target, either on Etherscan or the Github repository, identify the affected properties of the target. Examples can include affected functions, inline assembly, bad signature verification patterns, DEX integrations, etc.

1. Follow the steps of the bug report and mentally simulate the attack
2. If PoC code is provided, execute the PoC code in a throwaway VM

Reassess severity, given the technical description

Based on the technical analysis, refer to the Immunefi severity system linked from the bug bounty page.

Immunefi classifies (5) levels of severity:

• Critical
• High
• Medium
• Low
• Informational

The potential impact of a successful exploit informs the initial severity of a bug. However, this severity may be downgraded for various reasons. Initially, the whitehat will select their identified severity level. However, if you wish to reassess the severity level using any of the reasons on this list. Reasons not on this list will invite additional scrutiny:

• uncommon or incorrect action must be taken by the victim
• uncommon or incorrect action must be taken by an user with escalated privileges
• attacker needs escalated/admin/controller/strategist/governance privileges
• attacker needs key compromise
• market conditions favorable to the attack do not currently exist
• attacker requires majority ownership of a scarce asset
• attack requires large gas consumption (millions)
• no funds at risk
• attack requires repeated interaction over a long period of time (project may notice)
• attack requires physical access to the victim's computer
• attack requires brute-force complexity of over 40 bits
• attack requires trust-ful collusion with a miner
• attack requires a deep reorg (>8 blocks on ETH mainnet)

We also provide a non-exhaustive list of reasons for downgrading the severity of the bug that are not acceptable:

• no reason
• my dev said
• this is just a trading strategy
• we never deployed that contract (then why was it in scope?)
• we intend to deprecate that contract (then why was it in scope?)
• the previous developer listed that contract, it shouldn't have been in scope

If at any time you are in doubt, you are entitled and strongly suggested to contact the whitehat using the dashboard for answering your doubts.

Example: The initially assessed severity of the bug report is "High" as "theft of yield", but in order to execute the attack, the attacker needs to send a transaction in every single block, spending a lot of gas. This downgrades the severity to "Medium".