ZK9: The glitch to fake user debt discovered in Binance’s Proof of Reserves - Bartosz Barwikowski

Transcript

foreign [Music] for now let's welcome Barto Bartos to the stage from hacking thank you okay perfect hello everyone so I'm Bartosh I work at hacken as web free auditor researcher and today I will be talking about the bugs I found in the binance zero knowledge proof circuit so about haken we are the cyber security company we are in web free since 2017 and right now we are doing all weekend to make a web free a safer place but

let's talk about binance proof of reserves so after the F takes collapsed everyone started to talking about proof of reserves probably remember that you know people were saying that the binance doesn't have all the coins they claim so they need to figure out something quickly so the solution for the problem was to to introduce proof of reserves the first version of proof of reserves was quite simple you just created a miracle tree you asked an auditor to to verify that you include every users and you let your users checked if they were included or not but actually there is a way better way to create a proof of

reserves without an auditor and it is by using zero knowledge proof so that's what Finance did they created the zero knowledge proof circuit which was Computing the Merkel tree and which was Computing all the assets all the depths for 130 cryptocurrencies they hold but the problem is it's quite hard to implement zero knowledge proof circuit for 50 million of users so they had to introduce some optimizations and and that's why they're when the problem started so so the first thing they did was to split the users into badges so instead of

calculating a proof for 50 million users they decided that they will create a proof for every 750 something like this users they will connect one patch to another and at the end they will receive the final final assets final Mercury so to connect every every batch they use the the hash of of total Equity total debt and base price for every token every cryptocurrency they hold and to connect to connect them they used an optimization because why would they use

the three numbers to connect one one batch to another they decided to create optimization and instead of using three numbers just use one Epic number so they actually did a bit shifting they create they created a one huge number uh using total Equity total depth and the price base price so whenever whenever they have those values they calculate this huge number they calculate Poseidon hash from it and move it from one batch to another but the problem is that actually you can abuse the system because there was no validation for the base price so

if you use a huge base price higher than 2 to the power 64. it will start overflow to other values actually modifying them it will be able to modify the depth it will be able to modify Equity but they didn't see this as the problem because because the base price the base of the price of the token is is public it's visible to everyone so everyone even if someone sets it to higher than 2 to the power 64. everyone would see this but but the problem is actually it was possible to make this change invisible the problem is that they decided to use batches so someone could only modify the

value of the base price only in one batch and how to do this that was actually pretty simple all someone had to do was to lower the total depth or lower to totaled equity and then it was possible to increase the base price of of this value so for example in this example someone is lowering the total depth by zero and it allows to modify to increase the base price to 2 to the power 64. only in one batch and it's not possible to detect to detect it by anyone so in this way you can abuse this to to fake the proof because when you get such high base price one token is now worth millions of dollars so you can

create an artificial tokens to completely fake the proof okay so we discovered approved we discovered that the issue and then then we generated a proof of concept of this I created I created a repository where I proved this issue I created effect proof which which I demonstrated to the binance team I also proposed the issue the the fix for for the for this issue which was actually pretty simple because all they needed to have was a validation that the base price wasn't too high

so we contacted with binance on telegram they answered pretty quickly they had some questions about this issue and after we answered all of them they accepted our fix and we released a press statement on the Twitter so what's the lesson lesson from this the the problem with with the zero knowledge proved the circuits everything in web free is that it's very easy to make a mistake really I've seen hundreds of them and right now whenever we create something new something complex something Advanced I think it's almost always necessary to have someone to

check your code to have a third pair of trusted third third trust part no trusted party to help you and I think it's becoming the industry standard right now so during the audit we also found a few other minor issues another Audi the technical assessment so if you are interested if you want to see the details what exactly happened what other issues we found feel free to scan the QR code and read it yourself thank you foreign