Thread by @farazsth98

1/ I spent a lot of my time in the past 4-5 days analyzing the vulnerability exploited in the KyberSwap exploit, and it's lead me to one conclusion:

It is almost impossible for an auditor during an audit / competition to have found this vulnerability.

2/ First of all, SlowMist did a brilliant job analyzing the actual vulnerability. I wish I'd found out about it before I finished my analysis, it would've saved me a lot of time 😅 I highly recommend reading it: slowmist.medium.com/a-deep-dive-in…

3/ Because of the time-boxed nature of audits / competitions combined with the a predefined scope that auditors are generally constrained by, the amount of time allocated for an audit is generally just enough to audit and test all the code + functionality that is in scope.

4/ Auditors are also provided with documentation related to the code they are auditing.

In this case, the vulnerability was in the `calcReachAmount()` function, whose implementation matches the documentation perfectly.

5/ In a normal audit scenario, an auditor would very likely notice this, and then move on, with the assumption that the reach amount is calculated correctly. In fact, in normal circumstances, the reach amount does lead to a final `sqrtP` that is within the liquidity tick range.

7/ It would be very rare for an auditor to spend even more time attempting to understand how a different concentrated liquidity implementation handles a similar case (UniswapV3 for example), especially when KyberSwap implements a whole new re-investment curve functionality.

8/ However, the same cannot be said about a black-hat!

A black-hat has all the time in the world. They can spend a whole year just analyzing one protocol to find the one bug that will let them retire for life.

9/ In this case, the attacker found that when providing liquidity within a specific 400 tick range (some nearby tick ranges would work as well), and then moving from one end of the range to the other through a swap, `calcReachAmount()` calculates the reach amount incorrectly.

10/ In order to achieve this, the attacker needed to use a flash loan to get the pool to a state where only a small amount of liquidity was in use (provided by the attacker themselves) within a 400 tick range. It also needed to be a specific 400 tick range.

11/ Under normal circumstances, this is very unlikely to happen. Indeed, in an audit scenario, not only would the auditor need to fully comprehend everything that's going on, they'd have to be able to think up this specific scenario and test for it.

12/ Note that I said this would be "almost" impossible for an auditor to find. It is very normal for an auditor to test to make sure all the values returned by each of the functions used during the swap are correct over a wide range of ticks.

Well, I know I would :D

13/ The issue arises in the fact that an immense understanding of the code is required to even come up with a proof of concept that would allow for such a test to work.

14/ Indeed, even a slight change to the attacker's POC causes a revert. To anyone writing a POC to test for something like this, the constant reverts from not having just the right inputs to the swap function would lead them to assume that the code is correct.

15/ I believe this sort of understanding is only achievable over a long period of time, much longer than any audit / competition. Additionally, an auditor would need to experiment and test the code over a very long time to get invalid values from `calcReachAmount()`.

16/ I think it would be safe to conclude that an auditor could only stumble upon this bug by pure chance during a time-boxed audit. Only a black-hat with all the time in the world could figure out how to get this code to behave erroneously, and then escalate that to an exploit.

17/ Is there a solution to this problem? Well, one can argue that ImmuneFi projects with their massive bounty rewards encourage white-hats to audit and hunt for vulnerabilities the same way that black-hats do.

18/ The problem though, is that this assumes that those white-hats are hunting for bugs on ImmuneFi projects full time. There are very few white-hats who fall under that category. Everyone likes to have some form of a stable income after all!

19/ Also, I think it is safe to say that a majority of people are inclined to move on from a code base after they think they've gotten a great understanding of it. There are a very rare handful of people who would still stick to a project long enough to find a bug like this one.

20/ Correction: not only to find the bug, but also spend the multiple days (more likely weeks or months even) to come up with the proof of concept that showcases the exploit.

21/ After this hack, my honest opinion is that a project is required to have a well compensated bug bounty program at this point. It needs to incentivize white-hats to treat the project like a black-hat would, so that instead of losing 100m, the project rewards 1m instead.

22/ I'm not saying that the ratio of 100m TVL to 1m reward payout is right or wrong. I am however saying that without a well compensated bounty program, these types of bugs are forever destined to be exploited by black-hats before any white-hat will ever bother to look for them.

Anyways, all these opinions are mine and do not reflect that of my employer.