One of the most important values for INLOCK is transparency and informing our clients about risks in a comprehensive way. For this purpose, we summarize our following incident involving the ILK token smart contract.
On the 20th of March, 2021, we started an investigation of a possible incident at night following independent reports. Someone initiated a large-scale market sale on the Liquid stock exchange. The volume of sales exceeded 30 million ILKs.
Since the sale completely emptied the order book, we assumed the seller could have gotten the tokens in some illegal way, as they were not very interested in how much loss they could sell them with.
First and foremost, the operations team performed a status survey on the INLOCK platform, on the basis of which it was possible to exclude that the alleged attacker had gotten access to the tokens through the platform. At this point, we first informed our clients (CET 22:41), indicating that the INLOCK platform and the client assets stored on it were not involved in the incident at any level.
The case of what happened is currently under investigation. Short background story: Today, there was a token sale on the Liquid Stock Exchange with such a large volume as we believe no one can have. Based on this, we suspect that there is a problem with either the stock market or the INLOCK token contract. In the coming hours, we will extensively investigate the case and keep you informed of the news. (https://t.me/inlock_hun/24788)
We were also able to exclude the Liquid stock market in a short time due to the potential source of the problem. We were left with only two ways to see it: someone had stolen more than 30 million ILK tokens at once, or there was some problem with the token’s smart contract. As there are very few clients who would actually have ILK 30 million token at all, and all of them also store it on the INLOCK platform, we immediately involved our colleagues who developed the smart contract for the INLOCK token in our investigation.
By 22:56, we activated a modification of the ILK token contract, suspending all token movements, therefore isolating the status and creating the opportunity to investigate the merits of the possible error.
At 23:10, we identified the bug and the way the attacker was able to take advantage of it. Basically, they were able to duplicate their existing tokens with a simple self-transfer, first making 2 million tokens from 123,751 ILK tokens with four iterations, immediately put them up on the Liquid market, and then doubling another 150,000 ILK tokens to 78 million ILK tokens through a number of iterations. They also tried to sell this amount all at once on the Liquid stock exchange, which resulted in an investigation for this incident.
Within a few minutes of identifying the bug, the error was completely fixed (https://github.com/IncomeLocker/ilktoken-contract/commits/fix), after which the repaired tokenLib contract was successfully deployed and upgraded the smart contract of the INLOCK token at 23:54 CET.
Following the correction, the code was thoroughly tested, and we announced that the ILK token contract could be used again at 0:11 CET:
#Update: The fixed ILK token contract is all set up. Token transfers are working again. We will start fixing things soon on Liquid. (https://t.me/inlock_hun/24806)
Since the perpetrator was clearly identifiable, we contacted them that night, who returned tokens that had not yet been sold, as well as all proceeds from the sale, as a sign of his cooperation. Thus our losses were limited to ILK tokens sold below cost in this case.
We created a full summary of the case in the following morning (on Sunday CET 7:46): (https://t.me/inlock_hun/24870)
As several questions were asked in connection with the summary, they were answered in the following statement:
Dear INLOCKERs, Here are some thoughts after the incident:
- auditors and pen-testers always try to get the best out of their work. The fact that auditors have reviewed the INLOCK token contract does not free us from any responsibilities, it only acknowledges that we have really done everything we can to avoid slipping on it.
- the bug with which they were able to duplicate tokens is completely banal. Most likely, they found it completely by accident. We looked back on the blockchain events and it had also happened before that someone had managed to duplicate a small number of tokens. Unfortunately, this mistake has been with us since the summer of 2018, compared to which it is especially surprising that only someone managed to take advantage of it only 3 times and yesterday was the only one that resulted in more serious material damage. We have the transaction records of duplication in all three cases, and we even know the exact identity of the parties involved.
- we will burn the extra tokens generated during the duplicates, so we will also restore the parameters according to the tokenomics.
- the perpetrator was cooperative and returned everything they could.
- in the next few days, we plan to restore the token exchange rate and markets. I’m afraid it will take a little longer to restore confidence in the token, but in any case, we will fully stand up for our model and the value of the token.
Has the token supply increased in connection with the case?
Since tokens that had previously existed were duplicated by exploiting the bug, the total set of ILK tokens also increased by nearly 80 million ILK tokens.
However, in the beginning of the project, we clearly declared that there could never be more than 4.4 billion ILK tokens, the decision was made about the extra generated tokens that would be burned within a deadline. However, the exact process of this is still under development, as the ILK token was not designed to simply burn any of it.
A part of the tokens that will be burned would be covered by the returned tokens, however, in connection with the tokens that were already sold, we made the following resolution:
I also find it important to note that about 60% of the tokens duplicated during the damage could be returned by the perpetrator (the rest have already been sold). Those who bought a token from the perpetrator can, of course, keep it as they paid for it. In the case of token burning, the INLOCK platform cannot be damaged either, so about 40% of the platform’s own stock will not be replaced. The decision was already made last night about the amount of extra tokens in question that would be financed directly by the founders’ own team share. (https://t.me/inlock_hun/24893)
The specific bug
The bug was in the tokenDB.sol code of the INLOCK smart contract, more precisely in its transfer function:
The transfer function read out the receiving and sending balances in advance incorrectly and then mistakenly treated them as two different addresses during their maintenance. Thus producing a state that the sent balance is doubled at the receiving address if the receiver and sender addresses are the same.
Fixing the bug
The bug has been fixed with a work-around currently, making it physically impossible to transfer an ILK token to the same address, thus obscuring the problem.
Since tokenDB.sol was also designed to be upgraded, the base bug in tokenDB.sol will be fixed later, but the protection found in tokenLib.sol (_from! = _To) remains even after.
Conclusion
This old proverb was clearly justified in connection with the incident:
“What doesn’t kill you makes you stronger!”
As a result of this specific incident, we succeeded in correcting an error that, if it had occurred only later, could have caused more significant damage. All this in such a way that we managed to eliminate and repair the damage shortly.
