How I searched (and found!) The bugs in the kickico smartcontract
In August, I unexpectedly participated in the bugbounty of the Kickico project. I already talked about this at the Atlas Blockchain mitapaphone last Friday. The article is a text version of this report with a supplement and a small Friday contest :)
Kickico is a crowdfunding platform, kickstarter with reception of cryptocurrencies.
I already knew about the project. Somewhere, perhaps in the chat, I saw a link to the github with the source code of the contract and it became interesting for me to look at the code that rolls in millions.
Then I still did not know anything about smart contracts and solidity, as well as the fact that I didn’t just update the loaded contract, and immediately created my search for using magic numbers with the proposal to replace dividents.length.
')
Also, when reading for the first time, the calculateDividends function struck me, it was implied that when called with a task number from the dividend calculation plan, it would charge interest on the accounts of tokens holders. It’s only after the accrual that the next stage is not deactivated and if you call the function again, the dividends will be charged again.
Even within the framework of the first review, I saw that the Approval event was not triggered, not at all a bug, and, as I understood, now it doesn’t affect anything at all, but I sent it anyway.
After that, I threw off AntiDanilevski links to ishews, so as not to get lost in the confusion of preico, I received a promise to check and forgot for a while Kickico. After 2 weeks, I received a notification from the githab about a new commit, all of my accounts were fixed. I wrote Anti and got my reward in tokens.
After another 10 days, Anti wrote to me by himself, reported on a large renewal of contracts, and offered to look for more bugs. The part in the token contract that was responsible for dividends and the freezing of tokens was well reworked, preventing potential vulnerability, when there might not be enough air to pay for dividends.
After sitting for a couple of hours, I sent another 2 ishes. The first, though critical, was immediately noticeable. Percentage of dividends did not coincide with the Whitepaper. Apparently, they planned to change, but then remade.
The second search was again connected with the possibility of re-accruing dividends, but not for everyone, but for the particularly tricky ones who would have found this bug. This bug is a combination of factors: the ability to cause the accrual of dividends to any user, the introduction of the ability to charge dividends not on all accounts at once, but on a part (due to the gas limit).
These bugs were fixed on the same day and I received another reward.
On the same day, the kickico team commented on the support of the bankor protocol and Anti again suggested that I look for bugs. At once, I saw only that the call to the NewSmartToken event was not implemented, but again this is not critical.
The next evening I looked at the code again and saw that in the issue method, there was not enough adding the address for which tokens were issued to the list for calculating dividends. I immediately informed Anti about this, but it turned out that the auditors hired for money had already reported about this bug.
What was done well?
----- Bonus part -----
The other day kickico released an updated version of the token, in which, among other things, the epic criticized a bug that I did not see before the ICO, or third-party auditors. That confirms the fact that if you have a less complicated contract, then no one can give a guarantee that there are no bugs in it. You should always have a plan B for this case. A good option for this is the mechanism for updating the code without changing the address.
Well and actually competition: who the first will describe this bug, will receive 500 KICK from the kickico project. On the githabe version with a bug, look diff with the current version unsportsmanlike :) Description of the bug please hide under the spoiler.
Kickico is a crowdfunding platform, kickstarter with reception of cryptocurrencies.
I already knew about the project. Somewhere, perhaps in the chat, I saw a link to the github with the source code of the contract and it became interesting for me to look at the code that rolls in millions.
Then I still did not know anything about smart contracts and solidity, as well as the fact that I didn’t just update the loaded contract, and immediately created my search for using magic numbers with the proposal to replace dividents.length.
')
Also, when reading for the first time, the calculateDividends function struck me, it was implied that when called with a task number from the dividend calculation plan, it would charge interest on the accounts of tokens holders. It’s only after the accrual that the next stage is not deactivated and if you call the function again, the dividends will be charged again.
Even within the framework of the first review, I saw that the Approval event was not triggered, not at all a bug, and, as I understood, now it doesn’t affect anything at all, but I sent it anyway.
After that, I threw off AntiDanilevski links to ishews, so as not to get lost in the confusion of preico, I received a promise to check and forgot for a while Kickico. After 2 weeks, I received a notification from the githab about a new commit, all of my accounts were fixed. I wrote Anti and got my reward in tokens.
After another 10 days, Anti wrote to me by himself, reported on a large renewal of contracts, and offered to look for more bugs. The part in the token contract that was responsible for dividends and the freezing of tokens was well reworked, preventing potential vulnerability, when there might not be enough air to pay for dividends.
After sitting for a couple of hours, I sent another 2 ishes. The first, though critical, was immediately noticeable. Percentage of dividends did not coincide with the Whitepaper. Apparently, they planned to change, but then remade.
The second search was again connected with the possibility of re-accruing dividends, but not for everyone, but for the particularly tricky ones who would have found this bug. This bug is a combination of factors: the ability to cause the accrual of dividends to any user, the introduction of the ability to charge dividends not on all accounts at once, but on a part (due to the gas limit).
These bugs were fixed on the same day and I received another reward.
On the same day, the kickico team commented on the support of the bankor protocol and Anti again suggested that I look for bugs. At once, I saw only that the call to the NewSmartToken event was not implemented, but again this is not critical.
The next evening I looked at the code again and saw that in the issue method, there was not enough adding the address for which tokens were issued to the list for calculating dividends. I immediately informed Anti about this, but it turned out that the auditors hired for money had already reported about this bug.
What was done well?
- Bagbaunty. Few projects carry out bugbacks.
- Laid out the code on the githaba. For example, I didn’t intend to participate at all at bugbaunt, went to see the code out of curiosity, but how did it happen :)
- Work with the participants of bagbaunty. Anti informed me about all the updates and asked to search for more.
- Hiring third-party auditors.
----- Bonus part -----
The other day kickico released an updated version of the token, in which, among other things, the epic criticized a bug that I did not see before the ICO, or third-party auditors. That confirms the fact that if you have a less complicated contract, then no one can give a guarantee that there are no bugs in it. You should always have a plan B for this case. A good option for this is the mechanism for updating the code without changing the address.
Well and actually competition: who the first will describe this bug, will receive 500 KICK from the kickico project. On the githabe version with a bug, look diff with the current version unsportsmanlike :) Description of the bug please hide under the spoiler.
Source: https://habr.com/ru/post/338960/
All Articles