Introduction

Whitehacking is the process of exploiting a project’s vulnerable smart contracts with the intent of taking and returning all funds to their rightful owner(s).

For blockchain developers, whitehacking their own project’s smart contracts is one of the most stressful moments of their entire lives because of how much money and reputation are at stake. One wrong move, and they might permanently lose all project and user funds. It’s like walking on a tightrope over the Grand Canyon–with a time limit.

It is one of the most harrowing activities imaginable, given everything that can go wrong, and so we’re writing this article to make the claim that it’s unethical for whitehats to whitehack a project’s smart contracts without the explicit consent of that project. Further, not only is it unethical, but it could also open whitehats up to serious liability.

We’ll first discuss the reasons why whitehacking is used in the first place before diving into our claim.

From the perspective of a blockchain project, whitehacking comes into play for two reasons.

First, because a smart contract might be non-upgradeable. While non-upgradeability is a strong signal that a project takes decentralization seriously, it also introduces risk. What if the code isn’t completely free of critical bugs? Unfortunately, this happens more than anyone would like. Not even the giants of tech like Apple, Microsoft, or Google can avoid critical bugs.

If a smart contract is non-upgradeable, there’s usually only one feasible way to pull those funds out: the project has to exploit the vulnerability and then return the funds to users. Once the funds are safely returned (which itself is a monumental effort), the project then rebuilds the codebase and ships a new, more secure version of the smart contract.

Second, because even when a smart contract is upgradeable, sometimes a blackhat has already started exploiting the contract or a project may have knowledge that they are about to be exploited, and time is of the essence.

The project doesn’t have days or weeks to implement a permanent fix that works well with the rest of the codebase, and this is also true when upgrades have to go through governance. Instead, they have minutes or hours. This situation is far more dangerous because there’s little time for quality control checks on whitehack exploit code.

To date, we’ve written one of the most in-depth accounts of how stressful and intense a whitehacking war room is, and what it feels like to push the big red exploit button. In early 2021, we helped Primitive Finance save their non-upgradeable contracts through a whitehack. You can read the full story here, but it’s worth excerpting:

No one is ever fully prepared to whitehack their own protocol. The pressure and anxiety are enormous. Sure, the tests have been run, but when the red button has been pushed, there’s no going back. Whatever happens, happens.

“I was concerned to execute it from my own machine,” Alex told me. “I was prepared to do it, but realized that if something went wrong and we’re right in the middle of doing this, it could get really messy. Someone could see the transaction as it was happening, or a bot could find it in the dark forest.”

In another easily conceivable world, the whitehack could have failed, and all user funds would have been lost forever.

It’s one thing when the project executes the whitehack. It’s another thing entirely when a whitehat decides to take matters into their own hands without project consent. And with so much on the line, it’s inappropriate for whitehats to take that choice out of the project’s hands.

Now that we have some background on what whitehacking is, why it’s done, and an anxiety-provoking excerpt of the Primitive Finance war room, we’ll talk about the three reasons why unauthorized whitehacking is unethical.

Arguments Against Unauthorized Whitehacking

Whitehacking is still exploiting

Unauthorized whitehacking is an act of trespassing and theft. It is exploiting a project and stealing funds. The intentions might be good (to return the funds), but intentions are only a small part of the equation in determining whether an act is unethical. We’ve already covered why ‘Code is Law’ is no defense for blackhat hacking, so we won’t rehash those arguments, but here’s a more specific thought experiment.

Suppose you’re at a bank one day to make a deposit, and you realize that the safe technology they’re using to store customer valuables is vulnerable. So you return at night, break into the building, crack open the safe, and come back the next morning, announcing to the local branch manager that you broke into the bank and took all the valuables before anyone else could, and you’re here to pass the loot bag back.

What is the legal and ethical status of this act? It’s quite clear. You would be on the floor and cuffed before you could even pull out your phone to talk (or even brag) on Twitter about all the gold bars you saved.

The reason there’s confusion here is because it’s easy to avoid all the mental red flags that would ping your mind if you were actually about to break into a bank. When you’re operating in a dephysicalized environment of 1s and 0s, have good intentions, and can run an exploit very quickly from your keyboard without having to interact with anyone else, it’s easy to forget the enormity and magnitude of what it is that you’re actually doing, and what the consequences could be.

Whitehacking is extremely dangerous

At Immunefi, we see bug reports and PoCs submitted by the best of the best in the industry. In spite of their incredible talent, elite security researchers still often submit PoCs that don’t quite work and need detailed refining based on feedback from the project. But when it comes to whitehacking, there are no second chances. You either succeed, or you brick the smart contract and user funds are permanently lost. There could be systemic damage and contagion as a result of users thinking there’s an ongoing hack. Billions of dollars could be destroyed.

At best, a failed attempt notifies everyone who’s watching the chain that there’s a live vulnerability at play. Other blackhats, regular users, and MEV bots then jump into the fray, feasting on the carcass of the vulnerable contract.

In these cases, no amount of good intentions can eliminate that risk.

This is not a theoretical possibility. We have seen this happen when whitehacking goes wrong. It’s brutal, messy, and terrifying for everyone involved, especially for the whitehat acting on their own. The whitehat wasn’t supposed to do something like this in the first place without consent, and now what they’ve done has resulted in loss of funds because of what they didn’t or couldn’t know about how the projects works, their poor code, or because they notified the whole chain about this big vulnerability.

Unauthorized exploits, especially when they cause damage, could also lead to serious liability for whitehats, not just reputational harm.

The project might have their own solution in progress

Another reason why it’s important to talk with the project privately first and obtain consent for any proposed whitehacking is that the project might already be aware that a bug exists and/or that it is being exploited. They might have their own exploit code actively being prepared to whitehack the contract, or they might be working on tracking down blackhats or negotiating with them behind the scenes and don’t want outside interference. An unauthorized, solo solution could make things much worse, whereas the project’s solution might end up saving the day.

It isn’t right to jump in without any context or important background information and whitehack someone else’s contracts.

What You Can Do Instead

There’s a simple and straightforward decision-making process that you can follow when you you see a vulnerable piece of code out in the wild that’s being exploited:

Does the project have a bug bounty program?

They do: Report it via the bug bounty program. Do not post about it publicly. If you’d like, you can offer your assistance to help whitehack the smart contract in the bug report submission. The project may already be aware of the exploit and taking active steps to handle the situation, which is another reason why you do not want to act unilaterally, as you do not know all the relevant factors, and your solution may be much worse than the project’s solution. After all, projects sometimes are able to get hackers to return all stolen funds.

They don’t: Get in contact directly with the project directly. Inform them privately about the situation and offer your whitehacking assistance. We recommend you require that they execute the exploit, not you, to disclaim as much risk as possible.

They don’t, and the project isn’t reachable by any other means: send an on-chain message to the deployer address encrypted by the PublicKey of the deployer address. Explain the vulnerability and offer your whitehacking assistance.

If it’s impossible to reach the project after at least a week of attempting to do so via various channels, either do nothing, or make a public post notifying users that they should withdraw their funds. Do not make the vulnerability public before users have a chance to withdraw their funds. You will be relying on your security reputation here for users to trust that there is a real vulnerability, so this is not for newbies to the security industry who haven’t yet built a reputation. Do not abuse this trust. Alternatively, you can have another trusted security company or researcher review the vulnerability and make the announcement themselves.

Following this approach means that it may sometimes be too late to save the project or the funds, but it’s impossible to win every battle. That’s life in a permissionless world. We haven’t fully solved the problem of security in web3 yet.

Until we have, it’s important to stay on the ethical side and not own yourself when your intentions are good. Bug bounties are specifically designed to transform skill and good intentions into big rewards. Unauthorized whitehacks are traps to lure in the well-intentioned.

What About Successful Whitehacks?

It’s true that there have been some successful cases of whitehacking.

The whitehat exploits the contract, sends funds back to the project, and the project distributes them to the users. Everyone is happy. And yet, even if all parties are happy and the whitehack is successful, there is still serious liability that the whitehat is voluntarily taking on. Theoretically, anyone affected by the exploit could start a lawsuit against the whitehat and contact law enforcement.

It’s even worse if the whitehat tries to keep part of the funds for themselves as a makeshift ‘ransom bounty’, because that is the equivalent of theft. Moreover, those funds are often user funds, not protocol funds. Even if they wanted to, projects do not have authorization to give user funds away to hackers as a ‘ransom bounty’.

For example, let’s say you stole 10 cars from a poorly guarded parking lot. You couldn’t return 9 of them to the parking lot and claim 1 as your ransom, as those aren’t the parking lot’s cars to negotiate with! Additionally, even if the parking lot mistakenly said that the thief could keep a car as ransom, this doesn’t end potential legal liability from the perspective of the car owners.

It’s important to note as a final point that there isn’t extensive case law or legal precedent on whitehacking or smart contract exploits. We are operating largely in the unknown, but so far, things have not trended in the direction that unauthorized exploits are not theft.

For all of these reasons, it is clear that unauthorized whitehacking is unethical.

Whitehats who engage in whitehacking without explicit authorization from the project leave themselves open to tremendous liability and reputation loss.

There is a reason why almost all serious projects have a bug bounty program: because they don’t want unauthorized whitehacking. They want responsible, ethical disclosure. They want a PoC that forks a local copy of the blockchain, not an exploit on mainnet or testnet that notifies the whole world of a huge vulnerability and risks permanent loss of funds.

Whitehats become heroes through bug bounty hunting, code contests, and auditing–not unauthorized whitehacking.