Fairyproof’s Suggestions on Prevention of the Similar Exploits that Happened to KLAYSwap
On February 3, 2022, UTC, a DeFi app KLAYSwap was exploited. The KLAYSwap team has publicly announced the incident and taken action.
On February 3, 2022, UTC, a DeFi app KLAYSwap was exploited. The KLAYSwap team has publicly announced the incident and taken action.
Fairyproof studied the incident and would like to share some practices that could be performed to prevent this exploit from happening.
The hacker infected a js file that the swap’s front-end depended on by injecting malicious code. If a user followed the swap’s standard procedure to approve his/her crypto assets to be spent when interacting with the swap, his/her crypto assets would be exploited.
The vulnerability that was exploited in this incident was not in its smart contracts but in a js file (more specifically the Kahao SDK) that was infected by malicious code.
We suggest that some practices be adopted to prevent this issue from the perspectives of both developers and users.
From the perspective of developers:
The first practice is to use local js files instead of external js files.
The second is that if external js files have to be used, validation for external js files should be executed.
Here is an example of how to add validation:
This will check whether or not the hash value of an external js file is the same as the expected one.
From the perspective of users:
Be extremely cautious about authorizing any third-party applications the approval for spending crypto assets when using a web3 wallet to interact with a DAPP.
For instance, when a user uses MetaMask to log in to a DAPP and is asked to approve spending of crypto assets, MetaMask will pop up a message with detailed information about the approval. In this case, users should read the information with great care and caution. If the approval is suspicious just reject it immediately.
In this occurrence, after the js file was infected, if a user still visited the swap’s site, he/she should firstly delete his/her browser’s cache and then check whether the approval he/she would authorize was proper or not. If these two practices were performed the risk of being exploited would be greatly reduced. In addition, if the swap’s site had validation for external js files, the probability of being exploited would be further reduced.