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

Transcript

hey everyone I'm Bartosh I work at haken as blockchain layer 1 auditor researcher and during the last 10 months I found around 50 critical issues in various blockchain projects and today I would like to talk you about one of them a very interesting one a critical issue in binance proof of reserves but before talking about the bug let's talk about the proof of Reserves so as you probably know after F takes collapse everyone started to talk about proof of reserves the area of the proof work like this an exchange create a list of all the user assets they ask a trusted auditor to verify it

and later they release a service which allows you to check that your assets were included in the updated list this implement meditation works fine but actually there's a way to make it even better and it's by using zero knowledge proof by using zero knowledge proof we can automate the whole process we won't need an auditor and we can basically create a real-time system and that's what binance did a month ago they announced their own version of the proof of reserves which is using zero knowledge proof which allows them to create a proof that all user balances are correct there were no negative balances and all the users were included

and all of this without revealing any sensitive information about the users and their balances but there is one problem with zero knowledge proof and it takes a lot of computer power to compute it so in case of binance it was almost impossible to com so to create a proof of for 50 million of users so they decided to create an optimization in their optimization they decided to create batches of 864 users and later connect the batches and later connect all the batches to create the

final status of proof of reserves telling how many Equity how many depth they have and what's the base price of the tokens so they needed to connect all the batches with each other and to do it they use the following formula they used the following formula total Equity plus total depth plus base price in programming we call it a bit shifting it's just optimization to store all the information all the free numbers in one in one big number so for example in case of total Equity equal 10 total debt equal 5 and base price equal free will have the following

number which is used to connect one batch to another but there is a problem with this formula because actually you can use a trick to to create the same number from different Equity different depth and a different base price actually if you increase the if you set the base price the value of the token higher than 2 to the power 64. it all it allows you to create the same number also for different equity and a different depth and that's the issue which allows us to and to bypass the system and let me

explain you why okay but before this the problem with this is that okay if we set the Press of the token to a very high value to higher than 2 to the power 64. everyone will be able to see that one of the token is worth a million of dollars this is a problem because everyone will know that the proof was faked but there is a way to to hide it and let me tell you why how so actually because there are many batches used used to create the proof we can only change the base price in one of the batch and how we do it we do it but we do it by lowering the number of the total depth or total Equity by one and

when we do it then in the next batch we can increase the number the price of the token by Power by 2 to power 64. and it will give us the same number like like in the previous batch and only in this one batch the the price of the token will be very high one token will be worth millions which allows us to basic to fake the depth to to anything when it comes to depth and equity and then another batch we can restore the previous value and no one will be able to detect that the value was changed and faked okay and and later after finding this issue I

created a demonstration of this issue in our repository we contacted binance we shared the bug information about the bug and our reproduction test with them we also proposed the we also proposed how to fix this bug we created that pull request for the Repository and after some after some conversation with one of the developer they agreed that the issue exists and yes this is a Critic correct critical issue and I accepted my my fix for the solution and the fixed was to limit the price of the token to not be higher than 2 to the

power 64. okay and what's important from this later binance we released a press statement with a binance and they re-shared our tweet and this was quite successful uh tweet because we reached around 700 000 views which is which makes it one of the most important tweets from us okay and what's important from the story The problem is that in this case the bug was only in proof of reserves you could use this back to hack someone to steal the money but the thing is if this bug was

found in a smart contract probably it would allow to steal everything because it basically allowed to create a fake proof which which couldn't be detected that it is fake so in case of smart contract it would allow to steal everything but fortunately it was in the smart contract but anyway the thing is everyone makes the mistakes you know even the best one like the binance made a mistake it's very hard to avoid them right now the symptoms are so complex that it's almost impossible so it's always a good thing to have another third party an auditor to check your code you create it always helps and also during the during our technical

assessment we found few other minor issues and you are and you are if you are interested in details how exactly the bug works because it's a little bit complicated in the presentation feel free to check our final update of the binance proof of reserves thank you