Mass Adoption Hurdle: Web3 Security and Personal Responsibility

1. Background - Ongoing Web3 Security Vulnerabilities (feat. Approved Assets)

On July 16, 2024, a DeFi platform, LIFI Protocol, was hacked, resulting in the loss of approximately $11.6 million. LIFI Protocol is a platform aimed at enhancing interoperability across various blockchain networks, mainly providing cross-chain bridge functionality, which facilitates asset transfers and swaps across different blockchains.

This incident appears to have occurred for essentially the same reason as a previous hack in 2022, which resulted in a loss of $600,000. The victims of this hack were users who had used the platform's bridge and swap functionalities and had granted unlimited approval for certain tokens.

Approval is a function that allows a token owner to authorize another user or smart contract to use a certain amount of tokens on their behalf. This enables the authorized party to transfer or use a specified amount of tokens without the owner having to transfer them directly. This function is widely used across various DeFi services.

As of July 18, the vulnerability exploited in the attack has been patched, and LIFI has announced that it is working closely with law enforcement to track the stolen funds. Furthermore, the LIFI Protocol continues to operate normally.

Source: Thefts From Crypto Hacks and Exploits Surge in First Half of 2024

However, the total damage from smart contract vulnerabilities and phishing attacks, such as in the case above, is nearing an estimated $1.4 billion in 2024. These security crises are significant obstacles to the growth of the Web3 industry.

2. Takeaway - Overcoming Security Concerns and Paving the Way to Mass Adoption

Source: OpenZeppelin ERC20.sol

The approval function, central to the hacking case discussed, involves delegating authority, exposing users to various risks, such as:

Phishing Attacks*:* Attackers deceive users into calling approval on malicious smart contracts, making users think they are safe. However, this actually allows attackers to steal all approved tokens.
Malicious Upgrades: Developers or administrators with upgrade authority, or hackers who gain it, could maliciously upgrade smart contracts. The new version could include functions that transfer approved tokens to arbitrary addresses without user consent.
State Inconsistencies During Upgrades: State mismatches can occur during smart contract upgrades, where approved token data is not correctly transferred or is inaccurately handled by the new contract. For example, the new contract might incorrectly apply the authority list from the old contract, or lose some authority data during the transfer process.

In LIFI case, the stolen tokens were in a state of unlimited approval, granted by users, and were exploited via a smart contract vulnerability.

The core issue lies elsewhere. Using many existing dApps and DeFi services almost requires token approval. This means the responsibility for managing these approvals often falls on the users, while the service platforms only encourage delegation.

Source: Rabby Wallet Approvals

Although there are revoke functions within smart contracts to retract given permissions, the reality is that most users do not manage these settings effectively unless they have a deep understanding of smart contract functionalities. This leaves a significant security gap in the DEX ecosystem, where most users prefer simple bridge or swap services.

These potential security risks could pose significant barriers to new users entering the crypto and blockchain industry. Especially for mass adoption, more users need to use blockchain services lightly, yet these users tend to avoid situations where they bear the security risks and responsibilities.

Thus, to achieve mass adoption, potential security risks must be resolved, and users should be distanced from security responsibilities. This can be approached in two main ways:

First, dApp service providers should continually check and ensure that their smart contracts have no security vulnerabilities. While perfectly secure smart contracts do not exist now or in the future, taking no action against known vulnerabilities is far worse. Additionally, maintaining and operating a secure service enhances the external perception of safety and cleanliness, which benefits the service provider.

Secondly, there needs to be development in third-party services that can share the security responsibilities burdening users. For example, services like Revoke.cash help users revoke permissions granted through approvals. While this method is complex and cumbersome for light users, such third-party services can significantly mitigate security responsibilities. More services that help users manage security aspects they cannot easily handle would lead to a safer and more comfortable Web3 environment.

The Web3 industry continues to evolve, but it feels insufficiently robust to embrace light users who could drive mass adoption. Addressing security concerns from the user’s perspective is crucial for achieving true decentralized finance beyond being a niche industry.

3. Others’ Opinions

3.1 C4lvin from ChainLight - “Dapps should get Audits from various security firms in different scopes”

In the blockchain industry, while a perfect smart contract audit is said to be unattainable, vulnerabilities like those leading to LiFi incidents due to a lack of data verification in transactions should never occur if a proper smart contract audit is conducted. Reviewing projects where such incidents occurred reveals that most of these smart contracts were not audited. To prevent accidents caused by such vulnerabilities, I believe it is crucial to ensure that no smart contract falls outside the scope of audits and that smart contracts are audited by various auditing organizations.

Although services like Revoke.Cash can partially mitigate damages, large-scale incidents caused by groups like Lazarus (a North Korean hacking group) often result in asset theft before the attack becomes known to the public. This means that assets with delegated authority are often stolen before users have a chance to revoke that authority. Therefore, it is important to encourage users not to delegate authority over their assets. From a light user's perspective, stronger warnings at the wallet or service level would be effective.

Additionally, while the author seems to focus on the Approve function as a major issue, I do not believe the Approve function is responsible for such hacking incidents. Allowing users to decide their security level is, in my view, a desirable approach. The primary responsibility lies with the auditors and project managers who failed to anticipate and prevent well-known zero-day vulnerabilities, which could have been mitigated. Emphasizing the importance of zero-day vulnerability learning to Web3 developers might be more beneficial. Especially nowadays, platforms dedicated to vulnerability learning are available and can be very helpful. Examples include Phalcon Blocksec Explorer, Lumos Chainlight, and De.Fi Rekt Database.

4. Resource

Related Articles, News, Tweets etc. :