Security Case

description of kord fi security event as you probably already know, kord fi tzbtc contract was attacked on the night of 11th december this page provides insights into how this happened and explains why new contracts no longer have the same vulnerabilities ad the old ones kord fi tzbtc contract serves two purposes tzbtc lending, which allows users to lend their tzbtc tokens to the kord tzbtc contract in order to earn a dynamic secure yield on them sirs leveraged farming with tzbtc loans, where users invest tez, borrow tzbtc from the lending pool (created through the funds provided by the lenders) and invest the proceeds to thesirs contract (thus providing liquidity to the tez/tzbtc liquidity baking/sirius dex) weaknesses the attacker used two weaknesses that neither kord fi team nor auditors were aware of, that mostly arose from the features of tzbtc contract itself firstly, we did not account for the tzbtc fa1 2 contract method peculiarity in the special case when the transfer is called from an account that is the same as the sender, the allowance is ignored so that self approval is redundant and will be ignored secondly, the previous iteration of kord fi tzbtc contract didn’t explicitly forbid it to interact with itself security event the attacker managed to use these two weaknesses to make kord fi tzbtc deposit tzbtc to itself namely, this was the transaction we are talking about ( https //tzkt io/ooui7tk5byv4zadptagekm2g4ffrlnghudbbn13lohzgpzvhxmb/42697841 https //tzkt io/ooui7tk5byv4zadptagekm2g4ffrlnghudbbn13lohzgpzvhxmb/42697841 ) that made the kord tzbtc contract deposit 18598160063179 18481227 tzbtc to itself this had a negative impact on the operation of the contract firstly, this led to almost zero utilization and zero lending and borrowing rates (as at least formally the sum borrowed now was of a microscopic size compared to nominal deposit size) secondly, kord tzbtc contracts' farming side became non operational namely, since the contracts’ entrypoints that operate farms (investlb, redeemlb) explicitly check that the amounts of tzbtc and dtzbtc (kord tzbtc deposits) match each other the discrepancy between the two numbers automatically caused an error as the huge amounts of dtzbtc were minted without actual tzbtc commited to that operation to the best of our knowledge, it was not possible for the attacker to anyhow withdraw users’ funds from the contract at the same time, the protocol users were also unable to open or redeem farms deposits from the contract, as the contract had inconsistent tzbtc deposits solution shortly after the attack, the ezner user withdrew a part of his deposit, which made it impossible to revert the attacker’s transaction with getbalance + callback redeem combination such an attempt was made by someone but failed to revert the contract to an operational state the solution we used to fix the issue and release the funds was made possible by the use of getallowance function we applied instead of getbalance to deposit or redeem arbitrary amounts of tzbtc from the contract to itself this helped us fix the tzbtc deposits and make the contract operational again https //tzkt io/op9egckiusvkmwyxuwhqdutzbswbfz8od6vbh3ywcwupncmyrqv/57678731 https //tzkt io/op9egckiusvkmwyxuwhqdutzbswbfz8od6vbh3ywcwupncmyrqv/57678731 the scenario described above together with many other potential attack vectors has been addressed by our joint security audit with the inference team this gives us the confidence in the new, extra secure kord fi protocol!