The Problem With Bug Bounties
A technically skilled individual who finds a bug faces an ethical decision: report the bug or profit from it.
This is nowhere more relevant than in crypto.
In this article, with the help of Ilan Abitbol from Resonance Security, I look at the recent debacle between Kraken and CertiK and use it to discuss some of the problems concerning bug bounties that have arisen over time in the computer industry in general and in the cryptocurrency industry in particular.
The bug
Back on 9 June 2024, a CertiK security researcher reported to the crypto-exchange Kraken that they had found a bug[1][2]. A significant bug — the equivalent of a re-entrancy exploit in a smart contract, but in the exchange’s web interface instead.
Re-entrancy bugs are exploits where you can withdraw cash or crypto, and then interrupt the system before the value of the withdrawal is subtracted from your balance. Or the reverse — start a deposit, wait for your balance to be increased in the system, and then terminate the deposit before it completes.
You can think of it like getting $400 out of an ATM and then turning it off before it reports back to the head office that your account balance should be reduced by that amount. Turn the ATM back on, and you can repeat the process until all the cash is drained from the ATM without your account balance decreasing.
It’s why competent smart contract programmers use a “checks-effect-interactions” pattern in their code:
- check the client has a sufficiently high balance to cover the withdrawal amount (the check),
- reduce the balance by the withdrawal amount (the effect),
- then, and only then, send the client the withdrawal amount (the interaction).
Or for the ATM — don’t pay out the cash until you’ve received confirmation from head office that the balance has been reduced.
From what I can tell from the tweets and articles concerning the recent CertiK/Kraken situation, a security researcher found a way to start the deposit of funds into Kraken, withdraw the funds from their account, and then cancel the deposit before it completed — very much like the ATM example I’ve given.
The law
If you are hired under contract as part of a “Red Team” testing exercise, which is where security experts try to hack into a corporate system with the blessing of company management, then the legal situation you are in is clear. You can’t be prosecuted under the various laws against computer misuse that every jurisdiction has passed, because access has been explicitly granted. You are authorized to do what you are doing.
If, on the other hand, you are an unknown person hacking into someone else’s computer and causing damage, deleting data, or extracting data and digital assets, then you are clearly in the wrong. What you are doing is criminal, and if you get caught the penalties can be severe. In some cases, we’re talking about years or decades of jail time[3].
Being a white hat hacker is more of a mindset than a status.
A problem arises in the gray areas, as there is no formal definition of what constitutes being a “white hat” hacker. What if, in the process of legitimately using a public interface to a computer system, you find a bug that allows you to access more than you are supposed to? Under standard prevention of computer misuse legislation even “poking” at the bug means you are breaking the law.
For example, in April 2024, a group of four University of Malta students found a security flaw in an application for students called FreeHour that allowed them to access student records as though they were system admins[4]. They reported the bug (a configuration problem in the underlying database), followed the usual white hat hacker rule of providing a three-month deadline to FreeHour for fixing the bug before disclosing it to the public, and asked if they could have a bug bounty for their discovery.
FreeHour claims they reported this to the authorities just to comply with GPDR legislation.
The police responded by arresting the students, strip-searching them at the station, and confiscating their computer equipment under Maltese law, which makes it illegal to access a computer application without proper authorization.
The students have stated they were acting in good faith, and I think they probably were. After all, they didn’t make any demands, or try to hold FreeHour to ransom. The company says they were following regulatory requirements. I couldn’t find a response from the Maltese police, but if pressed I’m sure they would claim they were merely upholding the law.
The upshot is that those four students will probably never report a bug to a company or government again.
Back to CertiK and Kraken — the auditing company certainly was not given permission by the cryptoexchange to withdraw nearly 3 million dollars in cryptocurrency as part of a “white hat” hacking exercise.
While we were working on this article that’s why Ilan said to me: “Being a white hat hacker is more of a mindset than a status.”
Bug bounties
Clearly, network computers are going to have vulnerabilities. From a utilitarian perspective, what we want to do is incentivize people to act as responsible citizens and report these vulnerabilities, rather than ignore them or worse, criminally exploit them.
The industry solution is the bug bounty: a legitimate way for independent computer experts to profit from their discoveries.
Companies provide a list of requirements and rules for white hat hackers, and if you follow those to the letter, then the company says it won’t prosecute you and may even give you a cash reward for your effort, on some scale proportional to the risk you have uncovered.
There are several problems with bug bounties:
- What if you accidentally break one of the (usually many) rules set out for the bounty program?
- Is the reward you get really going to be commensurate with the damage you have saved the company by reporting it? Will you even get one?
- As no explicit contract exists between the white hat hacker and the company, what about the fact that the authorities can still decide to prosecute and jail you, even though you did abide by all the bug bounty rules?
Kraken has a bug bounty policy[5]. One of the things that policy says is that to be considered a white hat hacker your bug bounty submission “can never contain threats or any attempts at extortion”. By holding the funds they extracted hostage, it can be argued that CertiK engaged in precisely that.
The rewards
In the cryptocurrency space, there are some extra problems. Holding a company to ransom by encrypting their data, or selling an exfiltrated database on the black market involves a lot of effort and risk. You need to find a buyer, and as your buyer is a criminal, you could end up not getting paid or even blackmailed into performing more hacking with no payment.
If you find a flaw in a smart contract or an exchange website, on the other hand, you can cash in without having to connect to the Russian mafia on LinkedIn. There are token mixers, and there are exchanges that are lax on their know-your-customer protocols, and so with a bit of research you can cash out anonymously.
If you find a way to drain an entire cryptocurrency exchange of its digital assets, that may be very tempting to some people. Especially since, for example, the Kraken bug bounty has a maximum payout of 1.5 million dollars, and the most ever actually paid appears to be 60 thousand dollars[5].
The ad-hoc ten percent bounty
A disturbing development has been the emergence of ransom-based bug bounties. The hacker steals a large sum, and then negotiates to return a significant portion of it (typically 90%) in return for the promise of no further repercussions[6][7][8].
This has become a very tempting response to make from the perspective of DeFi protocol companies. If all your liquidity is missing, it’s game over. If most of it is returned, it is almost business as usual. A one year or two year loss of profits is better than having to close up shop.
Unfortunately, this sets a terrible precedent. If a company or protocol has a maximum bounty of 1.5 million dollars, and stealing 150 million dollars and returning 90% results in a bounty ten times higher than the supposed top reward, this is going to push a significant number of white-hat hackers into that gray area.
Conclusions
Ironically, bug bounties and the cryptocurrency space have managed to somehow evolve a situation where the risks of following the bug bounty system are higher and the rewards gained are lower than turning to the dark side.
I would argue that companies should:
- set up a well-drafted and generous bug bounty scheme, and
- stick to it rigidly.
In practice, I don’t think think this will happen.
But one thing is for sure — bug bounties are in need of a serious rethink in this crypto-age we find ourselves.
References
[1] https://x.com/c7five/status/1803403565865771370
[2] https://x.com/CertiK/status/1803471653751423454
[5] https://www.kraken.com/features/security/bug-bounty
[6] https://www.dlnews.com/articles/defi/bitcoin-hacker-who-took-72m-usd-return-funds-to-victim/