Ecosyste.ms: Awesome

An open API service indexing awesome lists of open source software.

Awesome Lists | Featured Topics | Projects

https://github.com/paco0x/kyber-exploit-example

reproduce kyber-elastic exploit
https://github.com/paco0x/kyber-exploit-example

Last synced: 9 days ago
JSON representation

reproduce kyber-elastic exploit

Awesome Lists containing this project

README 

        
Here's the reproduction of the Kyber elastic exploit. For more details on the underlying issue, please see [this link](https://twitter.com/0xdoug/status/1727613541115429314).



This might be one of the most intricate DeFi protocol exploits to date, requiring highly accurate and specific parameters for successful attack transactions. A discrepancy as small as 1 wei could lead to different outcomes.



I was intrigued by how the hacker managed to determine the exact parameters needed for various Kyber pools.



At first, I tried using some random numbers to reproduce this attack. But it was unsuccessful and it turned out that obtaining the the correct parameters is difficult with a very low likelihood of success.



Eventually, I found that Foundry could be used to perform brute force testing to pinpoint vulnerable parameters. (Kudos to Foundry for executing Solidity code at blazing fast speeds!)



As of now, this repository only includes methods using brute force—is there a better approach?



## Reproduce the exploit in local test pool



This test setup a 1:1 pool and brute forcing to get a value to exploit the pool.



```bash

❯ forge test -vvv --mt testBruteForceExploit

```



It will take a while to run this test, since it's brute forcing.



A particle attack may leverage a forked network to pre-calculate necessary values, which are then utilized in the attack transaction.



## Fuzz test



Run fuzz to test if it can get an exploitable value (only 1 fuzz variable).



By default, foundry fuzzer only generate 256 cases, which is not enough to get a exploitable value. I've changed the config to 65535 so that the fuzz test can take effect on this simple case.



```bash

❯ forge test -vvv --mt testFuzz

[⠊] Compiling...

No files changed, compilation skipped



Running 1 test for test/Kyber.t.sol:KyberAttack

[FAIL. Reason: Assertion failed. Counterexample: calldata=0x0x6590d6450000000000000000000000000000000030303030303030303030363636390000, args=[64053151420411946063694050374803062784 [6.405e37]]] testFuzz(uint128) (runs: 8493, μ: 9713, ~: 9800)

Logs:

  Bound Result 67288735232761868185

  liquidity 67288735232761868185

  targetSqrtP 20693058119558072255662180724088

  nextSqrtP 20693058119558072255665665854997

  Error: a == b not satisfied [bool]

    Expected: true

      Actual: false

  ...

```



This test is expected to fail because the invariant cannot consistently be met in Kyber. I've simplified and focused on specific mathematical operations that impact the invariant for demonstration. In real production environment, we typically run fuzz tests on a higher-level swap functions, making the failure identification more challenging.



## Probability analysis



By utilizing the exceptionally fast foundry execution, we can evaluate the chances of getting a liquidity amount within a specified LP range that can be used for exploiting the protocol.



```bash

❯ forge test -vvv -mt testProbability

```



This runs a simple for loop to get the valid values(liquidity amount) found in a given LP range.



Some of the found numbers when setting liquidity to `[80e18, 80e18+1e8]`:



```bash

❯ forge test -vvv -mt testProbability

  ...

  liquidity 80000000000009325512

  liquidity 80000000000009325561

  liquidity 80000000000009325610

  liquidity 80000000000009325660

  liquidity 80000000000009325709

  liquidity 80000000000009325759

  liquidity 80000000000009325808

  liquidity 80000000000009325857

  liquidity 80000000000009325907

  liquidity 80000000000009325956

  liquidity 80000000000009326055

  liquidity 80000000000009326104

  liquidity 80000000000009326154

  liquidity 80000000000009326203

  liquidity 80000000000009326252

  liquidity 80000000000009326302

  liquidity 80000000000009326351

  liquidity 80000000000009326401

  liquidity 80000000000009326450

  liquidity 80000000000009326499

  liquidity 80000000000009326549

  liquidity 80000000000009326598

  liquidity 80000000000009326648

  liquidity 80000000000009326697

  liquidity 80000000000009326746

  liquidity 80000000000009326796

  liquidity 80000000000009326845

  liquidity 80000000000009326895

  liquidity 80000000000009326944

  liquidity 80000000000009326993

  liquidity 80000000000009327043

  liquidity 80000000000009327092

  liquidity 80000000000009327141

  liquidity 80000000000009327191

  liquidity 80000000000009327240

  liquidity 80000000000009327290

  liquidity 80000000000009327339

  found 1983 in 10000000



Test result: ok. 1 passed; 0 failed; 0 skipped; finished in 84.69s



Ran 1 test suites: 1 tests passed, 0 failed, 0 skipped (1 total tests)

```



When configuring the liquidity range to `[20282409603651670423947251286016, 20693058119558072255662180724088]` and initiating with a liquidity amount of `80e18`, it identified 1983 valid values out of 10,000,000 attempts. Adjusting the range and initial liquidity can yield varying outcomes for further analysis.