White hack policy

Defining the problem

There is a debate in the blockchain security community about how to approach hacks made by researchers with good intentions. Observing space for years, we have seen this kind of situation, but also many cases where projects were hacked by black hats and blackmailed about bug bounty. Some of them, as a result of negotiations, pressure from state services, or others, suddenly start trying to change how they are perceived towards acts with goodwill.

Calling the $600 million hack a white hat action was really disappointing.

However, there are also cases where the intentions are really sincere and good. The problem is that there is always an element of surprise when a serious vulnerability is discovered in a living project. Quite suddenly, from a normal, relatively calm day, we move to a very dark forest in which we do not know how much time is left and we have to act quickly.

The pressure that appears on the shoulders of a security researcher is really hard to bear and not everyone is able to handle it.

Imagine for a moment that you found a way to steal over $100 million from thousands of users using a vulnerability you found while browsing a new attack vector you stumbled upon while eating breakfast. You know a few people who invested in this project.

Those figures on the screen weren't just numbers. They represented dreams and hard-earned savings. The weight of this reality, the enormity of this revelation, is crushing.

Panic tightens its grip. What if you're not the only one who knows? What if someone else discovered it too? What if they did it yesterday and are just finishing an exploit? Maybe you literally have moments to prevent this from happening?

If I manage to save these funds, not only will I become a hero, but I will probably get an award. A life-changing prize…

This is not the end.

You are trying to contact the team quickly. You send an email, collect contacts via EthSecurity, and join Discord. You do everything you can to join forces.

BUT

The team is in a different time zone, and no one responds. They do not work with any bug bounty platform. It doesn't look like anyone will be addressing this urgent issue anytime soon.

Time passes, tick tock tick tock tick tock…

Should I wait and risk user funds hoping someone in bad faith doesn't know about this vulnerability?

Maybe I'll exploit it myself and transfer funds to a multi-sig contract and give access to the team?

This is just a small cutout of dilemmas faced by a security researcher.

On the battlefield where knowledge and skills can be demonstrated in reality, any mistake is catastrophic and can cause a bigger problem than the chance someone else also knows about the existence of this attack vector.

But how do you calculate which scenario is more likely? Which decision is the right one?

It's a very difficult decision, but more importantly, it's not your decision.

Our position is quite firm:

We do not support any actions on your own without the consent of the project team in which the vulnerability occurs.

Acting alone, even in good faith, is not good. It encourages to act arbitrarily and bypass processes developed by projects and bug bounty platforms that specialize in defining whitehack's rules according to which researchers operate.

It is always up to the project and their community to specify how they want these situations to be handled. And for that, you need a white hack policy.

Proposed solution

The key aspect is to think about this issue before the situation arises.

To understand the options below properly, you need to know our definitions of hacks.

• WHITE HACK - A well-intentioned controlled attack carried out to save users' funds in cooperation with and with the consent of the affected team.

• GREY HACK - A controlled attack carried out with good intentions to save users' funds WITHOUT the cooperation, but with the general consent of the affected team.

• HACK - Stealing users' funds or intentionally causing damage.

The options you can choose from are:

1. Allow only WHITE HACKS and prohibit any other form of hacking. Including GREY HACKS, regardless of intentions.
2. Use a hybrid approach that allows both WHITE HACKS & GREY HACKS, but under strict rules that you define.
3. Fully allow researchers to act freely if they have good intentions and the knowledge necessary to save funds. (NOT RECOMMENDED)

Based on our experience, option 1 is the best because it gives the most control to the team. However, you have to realize that this is not always possible and not every team is able to be on standby 24/7 with a very good response time.

In that case, option 2 should also be considered. Especially if the project uses the services of the bug bounty platform. This allows you to not only limit the possibility of mistake, but also delegate triaging and be informed only about confirmed cases.

Include a policy covering the event of a white hat hack in the project security section and clearly define the rules that the researcher should follow.

White Grey hack policy template

In case of detecting a critical vulnerability in a production environment that threatens the security of the [PROTOCOL_NAME] protocol, please follow the steps below in the exact order:

1. Please report it through the bug bounty platform with whom we work [LINK].

    If you do not receive a response (and only then) within [DEFINED TIME], send a message through [SELECTED COMMUNICATION CHANNEL] with a description of the problem to [ADDRESS] encrypted with the following key [KEY].

    If you do not receive a response from us within [DEFINED TIME], please reach out to our trusted partners:
    * [TRUSTED PARTNER 1]
    * …

    If none of the above provided you with a response or instruction from the team and [DEFINED TIME] has passed since the vulnerability was discovered, you can proceed to point 2.

2. We consent to the grey hack ONLY after all the following conditions are met:
    a. You have the knowledge necessary to carry out a controlled attack (was a participant in at least 1 successful white hat hack) and are fully aware of the threats associated with MEV bots.
    b. You successfully launched an attack on your local fork.
    c. You have contacted SEAL 911 and your vulnerability has been confirmed by at least 2 people.
    d. You have performed steps a-c above and have not received ANY response for [DEFINED TIME] from the team.

In the event of non-compliance with our guidelines, any attempt to hack the protocol will be prosecuted.

Add the template to your GitHub repository, and when you do - tag @Composable_Sec on Twitter so we can reshare it and spread this approach together to other projects.

Let’s debate

This template is of course only a suggestion. Our idea on how to minimize the risk and conduct activities based on the project's decision, not the instinct or hunch of a researcher. Customize it to your needs and share your thoughts on it so we can improve it for other projects.

Remember about the incident response policies for which you can find guidance here:

and about the newly created group that you can count on during the worst.

The SEAL 911 is a Telegram bot made to be used during emergencies to get in touch with trusted members of the security community and their extensive network of contacts.

Read more about it here:

Over the past few days I've been working with a group of whitehats, auditors, and other security leaders to try and solve the hardest part of responsible disclosure: finding the right person to talk to.

— @samczsun.com (@samczsun) August 7, 2023

Be proactive in terms of security. Don't let other people make decisions about your project.

• Did you like this article? Share it on social media!

Composable Security 🇵🇱⛓️ is a Polish company specializing in increasing the security of projects based on smart contracts written in Solidity. Examples of projects that have trusted us are market leaders such as FujiDAO, Enjin, Volmex Finance, DIVA Protocol or Tellor. We are creators of the Smart Contract Security Verification Standard. Speakers at various conferences such as EthCC, ETHWarsaw, or OWASP AppSec EU. Authors of numerous publications on DeFi security. Experienced auditors operating in the IT Security space since 2016.

If you need support in the field of security or auditing smart contracts do not hesitate to contact us.