Community rules

Loophole Collection Protocol

To standardize DVP community loophole collection procedure, BCSEC and PeckShield wrote this protocol to build community consensus, and this protocol will evolve according to community feedbacks.

Collection range

Type A vendors: Vendors on the DVP platform, loopholes would be claimed by vendors, or not.

Type B vendors: Vendors not on DVP platform yet. They have blockchain related products, including but not limited to, exchanges, cryptocurrencies, software/hardware etc. DVP community would claim loopholes before the vendors are on DVP platform. Caution: Type B vendors are not fixed, could be changed to Type C in some cases

Type C vendors: Non-relevant vendors. This types vendors are those that DVP foundation decides to be non-relevant , including but not limited to, information services or e-commerce sites (such as sites selling mining machines), etc, which are not relevant to blockchain, crypto currency, or vendors are not in normal operation (abandoned projects, Ponzi scheme projects, etc).

Explanation for Type B vendors

The following reward standards are for Type B vendors (Type A vendors have customized reward standard). Reward is not decided by the severity of the loophole, but the actual effect, such as exploitation difficulty, affecting range, hackers benefit or not, etc. E.g., a remote command execution to a less active exchange, the reward for this loophole would be low.

  • All loopholes or exposures must satisfy these three conditions: Not published, not fixed, and not submitted to other platforms.

  • If the target type is not in the reward range (tokens, exchanges, public blockchains …), but the target is somewhat important in the blockchain industry, please submit it as a exposure first, and the reward would be assessed according to loophole actual effects.

  • For loopholes that have some effects but not covered by reward rules, or rules that are not fair, we will improve them according to community feedbacks. The current rule is version 2.0, and it would evolve according to community feedbacks.

  • Loophole reward is assessed according to actual reality, the following table shows the highest possible reward, unit is ETH. After DVP tokens are tradable on exchanges, rewards would be DVP tokens converted from ETH according to ETH market price, before that, rewards would be ETH directly.

  • We defined the level of weak targets, when submit loopholes, please mark the target level if there is proof, otherwise DVP backend engineers would decide the target level. In the future, DVP would decide the target levels without referfing to external information.

  • If loophole/exposure cannot be classified by this protocol, they would be assessed according to CVSS loophole classification standard.

Reward standard

Token

SevereHigh riskMedium riskLow risk
Level 115 eth10 eth5 eth0.5 eth
Level 210 eth5 eth3 eth0.3 eth
Level 35 eth3 eth1 eth0.2 eth
Level 43 eth1 eth0.5 eth0.1 eth
Level 50.5 eth0.3 eth0.1 eth0.05 eth

Level classification information from:https://coinmarketcap.com/tokens/views/all/

Level 1: Market cap top 20

Level 2: Market cap top 100

Level 3: Market cap top 500

Level 4: Market cap below top 500

Level 5: Not in the list, but traded daily and has ICO

Severe:

• Can steal contracts or contract users’ digital asset unconditionally;

High risk:

• Can destroy or re-issue digital assets unconditionally;

• Can destroy or re-issue digital assets unconditionally;

Medium risk:

• Can destroy or re-issue assets to some users under some conditions;

• Can steal contracts or contract users’ digital assets under some conditions;

Low risk:

• Security risks in theory, including but not limited to, loopholes only can be exploited by owners.

Exchanges

Severe High risk Medium risk Low risk
Level 1 16 eth 8 eth 3.1 eth 0.5 eth
Level 2 3.1 eth 1.5 eth 0.8 eth 0.3 eth
Level 3 1.2 eth 0.7 eth 0.4 eth 0.2 eth
Level 4 1 eth 0.6 eth 0.3 eth 0.1 eth
Level 5 2048 dvp 1024 dvp 512 dvp 50 dvp

Level classification data from:https://www.feixiaohao.com/exchange/

Level 1: Trading volume top 10

Level 2: Trading volume top 30

Level 3: Trading volume top 100

Level 4: Trading volume below top 100

Level 5: Not in the ranking list but has daily trading volume (Note: To guarantee loophole quality, level 5 vendors’ loophole reward doesn’t have floating range )

Severe: Need proof of real exploitation, not issues in theory only.

• Can directly get system privilege;

• Severe design fault/logic loophole related to key business;

• Affect user/company asset, including but not limited to severe payment loophole, digital asset private key exposure, etc;

• Can lead to market manipulation, such as illegal operations that initiate buy/sell trades.

Can lead to market manipulation, such as illegal operations that initiate buy/sell trades

• Can directly get backend access privilege;

• Can directly get large amount of sensitive information, including but not limited to source code, SQL input etc;

• Loopholes that can directly, without interaction, steal large amount of users or backend employees IDs, including but not limited to user visible page storage type XSS, backend visible XSS (Need proof that can access backend information, otherwise would be classified as medium or low risk), etc.

Media risk: Need proof of real exploitation, not issues in theory only.

• Small amount of sensitive information exposure, including but not limited to SSRF internal network information exposure, partial user information exposure, etc;

• Design fault/Logic loophole that only affect user’s own account;

• Loopholes that need interaction, explosion etc to steal user IDs, including but not limited to non-typical page storage type XSS, backend invisible XSS;

• Denial of service loophole;

Low risk: No proof of real exploitation, issues in theory only

• Non-Sensitive information exposure, including but not limited to directory traverse, etc;

• URL jumping loophole;

• Short message interface abuse issues, etc;

• Loopholes that highly interactive, steal user iIDs, including but not limited to XSS, CSRF, etc;

• Loopholes that highly interactive, steal user iIDs, including but not limited to XSS, CSRF, etc.

These loopholes are not admitted for the time being:

• SPF mail forge loopholes

• Loophole steal user account name using Interface exhaust explosion

• Self-xss/Post type XSS loopholes that cannot be exploited

• Mail explosion

• Not sensitive operation CSRF issues

• Other low effect loopholes

• Loopholes of non-operative sites or Ponzi scheme sites

Public blockchains

Severe High risk Medium risk Low risk
Level 1 20 eth 15 eth 5 eth 1 eth
Level 2 10 eth 5 eth 3 eth 0.7 eth
Level 3 5 eth 3 eth 1 eth 0.5 eth
Level 4 3 eth 1 eth 0.5 eth 0.3 eth
Level 5 1 eth 0.6 eth 0.3 eth 0.1 eth

Level classification information from:https://coinmarketcap.com/coins/

Level 1: Market cap top 20

Level 2: Market cap top 100

Level 3: Market cap top 500

Level 4: Market cap below top 500

Level 5: Not in the list, but traded daily and has ICO

Severe: Need proof of real exploitation, not issues in theory only

• Can remotely get access privilege;

• Can directly steal digital assets;

• Severe sensitive information exposure, including but not limited to user private keys, passwords, etc.

High risk: Need proof of real exploitation, not issues in theory only

• Can lead to denial of services;

• Design faults/logic loopholes that affect large amount of users/exchanges

Medium risk: Need proof of real exploitation, not issues in theory only

• Can lead to local privilege upgrade;

• Design faults/logic loopholes that affect user’s own account;

• May lead to high risk loopholes indirectly.

Low risk:

• General information exposure;

• Low effect design faults/logic loopholes;

• Loops that can cause system resource abuse or user spam.

Wallets

Severe High risk Medium risk Low risk
Level 1 16 eth 8 eth 3.1 eth 0.5 eth
Level 2 3.1 eth 1.5 eth 0.8 eth 0.3 eth
Level 3 1.2 eth 0.7 eth 0.4 eth 0.2 eth
Level 4 1 eth 0.6 eth 0.3 eth 0.1 eth
Level 5 2048 dvp 1024 dvp 512 dvp 256 dvp

Classification data from:https://www.cryptocompare.com/wallets/#/overview

Level 1: Ranked top 10

Level 2: Ranked top 300

Level 3: Ranked top 80

Level 4: Ranked lower than top 80

Level 5: Not ranked but have some users

Severe: Need proof of real exploitation, not issues in theory only

• Can unconditionally remote get service/client access privileges;

• Can unconditionally lead to stealing of large amount of digital assets;

• Can unconditionally lead to severe sensitive information exposure, including but not limited to user private keys, passwords, etc.

High risk: Need proof of real exploitation, not issues in theory only

• Can unconditionally lead to large amount of sensitive information exposure;

• Can unconditionally lead to service/client denial of services;

• Can unconditionally lead to stealing of large amount of user IDs.

Medium risk: Need proof of real exploitation, not issues in theory only

• Can lead to malicious changes of user information;

• Can lead to malicious changes of user information;

• Can unconditionally lead to stealing of small amount of user IDs.

Low risk:

• General information exposure;

• Non essential bussiness design faults/logic loopholes;

• Non essential bussiness design faults/logic loopholes.

Mining pools

Severe High risk Medium risk Low risk
Level 1 15 eth 10 eth 5 eth 1 eth
Level 2 视实际情况 视实际情况 视实际情况 视实际情况

Reference data from:https://btc.com/stats/pool

Level 1: Top 20 ranking

Level 2: Not ranked but have proof of some computation power

Severe: Need proof of real exploitation, not issues in theory only

• Can unconditionally remote get mining pool all privileges;

• Can unconditionally remote control all mining pool computation power;

• Can unconditionally steal ming pool reward or wallet money.

High risk: Need proof of real exploitation, not issues in theory only

• Can unconditionally lead to mining pool essential business denial of services;

• Can lead to mining pool interest loss, such as block withholding attacks, forge computing power, etc;

• Can unconditionally lead to large amount of sensitive information exposure.

Medium risk: Need proof of real exploitation, not issues in theory only

• Design faults/logic loopholes that can lead to some effect.

Low risk:

• Can lead to small amount information exposure

• Loopholes can have real effect under some conditions

DApp

Severe High risk High risk Low risk
Level 1 15 eth 10 eth 5 eth 0.5 eth
Level 2 10 eth 5 eth 3 eth 0.3 eth
Level 3 5 eth 3 eth 1 eth 0.2 eth
Level 4 3 eth 1 eth 0.5 eth 0.1 eth
Level 5 0.5 eth 0.3 eth 0.1 eth 0.05 eth

Classification data from:https://dappradar.com/dapps?sortBy=index&order=asc&search=&tab=allDapps

Level 1: Ranked top 10

Level 2: Ranked top 50

Level 3: Ranked top 200

Level 4: Ranked below top 200

Level 5: Not ranked but has digital asset and daily trade

Severe:

• Can unconditionally steal contracts or contract users’ digital assets.

Can unconditionally steal contracts or contract users’ digital assets

• Can unconditionally steal contracts or contract users’ digital assets;

• Can unconditionally use contracts’ important functions or denial of services.

Medium risk:

• Can create or destroy some users’ digital assets;

• Can steal limited contracts or contract users’ digital assets.

Low risk:

• Security loopholes in theory, including but not limited to loopholes only can be exploited by owners.

Threat information

Severe High risk Medium risk Low risk
3 eth 1.6 eth 0.6 eth 0.2 eth

Severe:

• Concrete proof of large amount of blockchain related sensitive threat information exposure;

• Concrete proof of stealing of large amount of non-personal digital assets;

• Concrete proof of unpublished severe blockchain related loopholes;

High risk:

• Concrete proof of invasion of well-known blockchain related vendors;

• Concrete proof of large scale attacks to blockchain related industry;

• Concrete proof of existence of backdoor in blockchain related hardware/software;

• New attack approaches to blockchain related industry;

Medium risk:

• Clues of exploitation of blockchain related loopholes;

• Clues of unpublished hot blockchain related security events;

• Sensitive information exposure of blockchain related vendors.

Low risk:

• Blockchain related fake websites or apps, etc;

• Clues of attacks against blockchain related industry.

General rules

  • Loopholes per se don’t have value, their value derives from the harm they can bring, so the reward of a loophole discovery is decided by loophole information submitted by white hats, and its effect range and difficulty of its exploitation, If the triggering condition is very strict, including but not limited to, XSS loophole in some specific browsers, the reward level can be adjusted.:the auditors don’t speculate on the harm of a loophole can bring, all proof has to be in the loophole information submission, not effect only in theory!

  • For loopholes not covered by any classification rules, DVP may decide to or not to record them.

  • If a loophole can be found among different vendors at least three times, then it’s regarded as a general loophole, after that more submission would be recorded as repeated submissions, but the loophole will be kept for vendors to claim.

  • The reward objects (public chains, exchanges, etc.) in the reward criteria are limited to themselves. If they submit loopholes in other assets (official websites, APPs, etc.) of their manufacturers, they will be downgraded according to the actual business situation.

  • For general loophole submissions, please list vendors information or how to search them, and submit at lease five operating sites as case examples.

  • Loopholes come from the same source would be counted as one, such as multiple loopholes caused by same interface, multiple page security loopholes caused by same publishing system, framework causing whole site security loophole, security issues caused by DNS, or same file with different parameters, etc.

  • Third party product loopholes, including but not limited to, Wordpress used by companies, flash, or Apache components, OpenSSL, SDK, etc. Same loophole with different software versions is regarded as one.

  • Same loophole, but later submission has different way of exploitation, all submissions will pass, but part of the reward for later submissions will be given to the first submission.

  • Submitters cannot publish or submit loophole details to other platforms, otherwise their account and asset may be frozen.

  • If loophole exploitation need privileged account, or can only be triggered under certain conditions, the reward may be lowered.

  • Loophole grouping

    • For related loopholes, such as using weak password to get into backend system, or SQL input, auditors may increase the loophole level. Later discoveries can be added into the same loophole, and the reward may be increased.
    • For one loophole submitted as multiple, DVP may group them together as one, it would be classified using highest level, but rewarded by applying the lowest standard. If they are done on purpose, submitters account may be disabled.
  • Submitter’s account and asset may be frozen in the following cases:

    • For ordered loopholes, submit the later ones first. Such as, discovery of weak mailbox password, then use the password to get backend administrator password, submitting the backend password first, then mailbox weak password second.
  • Using testing loophole as excuse, using loophole to harm users’ interest, affect users’ business, DVP would not issue reward, but may disable its account and assets.

  • For vendors DVP decided not to record, loophole submissions would be returned temporarily. After vendors follow DVP recording standard, loopholes can be resubmitted, and reward will be issued according to submission time.

  • For submissions without clear explanation, they would be rejected immediately. Every loophole submission needs to include loophole’s URL, text details, complete graph, and clear explanation, such as:

    • Vendor and it’s website, if there is no IP address of the website, then need separate explanation.
    • Loophole details need to have all related URLs
    • Loophole proofs need to list all key steps, meaning auditors can reproduce it using these steps
    • Loophole related payload, need to be included in the loophole detail text, or as screenshot
  • For marginal or abandoned systems, the reward level would be lowered

  • Information exposure type loopholes, such as GitHub information exposure, memcache, redis unauthorized access, etc, level classification would be according to contents validity and sensitivity, and isolate and low risk exposures may be ignored

  • Backend explosion issues need to be have proof of successful exploitation, otherwise they would be rejected.

  • Weak password issues:

    • Different weak passwords in the same system discovered by same submitter would be regarded as one case.
    • Default initial password is regarded as on case.
    • For non-essential systems, only the first weak password submission will accepted.
    • For essential systems and key business, the first two week password submissions will be accepted.
  • For related loopholes, don’t submit as multiple cases, otherwise DVP may freeze submitters assets.

  • Don’t execute tests which may cause service disruptions, such as IIS denial service or slow_http_dos etc.

  • If a service has both the PC site and mobile app site, and they use same interface and source code, same loophole from PC and app sites would be regarded as the same one.

  • About information exposure loopholes, submissions with real exploitation examples would be regarded as severe or high risk; key service config or source code exposure would be regarded as medium risk, no exploitation example or not key business related, would be regarded as low risk or rejected.

Vendor protection

If there are more than three same type high risk loopholes found in one system (such as SQL input or execution etc), auditors may regard the system has no protection, and lsame type submissions later would be classified as lower levels.

Conflicts resolution

If there is any disagreement about the loophole procedure, level classification, reward, etc, please enter comments into loophole detail page or contact online customer service. DVP would coordinate among related parties to resolve conflicts, while giving priority to loophole submitters, and may introduce independent security professionals if necessary.

Reference

Some contents are referred fromXian Zhi loophole classification standard,Thank you here.