Web3.0 is a new era where innovation opportunities and security challenges coexist. It brings new concepts such as blockchain technology, smart contracts, DeFi, and DePIN, but also brings up a variety of security issues such as malicious attacks, vulnerabilities, and fraud. On the other hand, since current Web3.0 products often incorporate many Web2.0 elements, the security risks of traditional Web2.0 have also become an important factor threatening the Web3.0 world.
As the world's leading Web3.0 security organization, the CertiK team has been proactively focusing on various native and derived potential risks, protecting thousands of customers from losses.
In this article, we will show you how the CertiK team discovered and resolved the Web2.0 vulnerability in WalletConnect, a common Web3.0 protocol.
WalletConnect与VerifyAPI
WalletConnect is one of the most popular open source protocols for Web3.0, used to connect various dApps with decentralized wallets. Users can establish a new connection by scanning the QR code provided by the dApp. Although the QR code will display detailed information such as the name, icon, and source of the dApp, this information is unilaterally provided by the dApp and does not need to be verified by the wallet, so there is a risk of phishing attacks, which is also a focus of many security teams including CertiK.
To this end, WalletConnect launched the "VerifyAPI".
"VerifyAPI" is a proactive security enhancement measure launched by WalletConnect for integrated wallets, which will alert users to suspicious or malicious domains to prevent phishing attacks. The API uses WalletConnect's domain registry and Blowfish's domain scanner to review connection requests. When a user tries to connect to a dApp, VerifyAPI can cause the wallet to present four states to help users assess the security of the domain and identify potential risks.
Discovering the vulnerability
The vulnerability in the WalletConnect protocol was discovered accidentally by the team during a routine penetration test for a client product. In the initial stage of a penetration test, the team usually goes through a comprehensive exploration process to understand the functionality of the application and the various services that interact with it. In this case, the web application of the client product used WalletConnect. Our monitoring of HTTP traffic captured information about requests made to the WalletConnect endpoint, and one of the requests caught our attention in particular.
Before we dive into the specifics of this vulnerability, let’s look at the VerifyAPI HTTP request workflow from the dApp’s perspective:
1. The embedded WalletConnectSDK sends a request to verify.walletconnect.com and includes the project ID in the path. If the ID has been registered with WalletConnect, the server will reply with a link to the index.js file and a CSRF token.
2. The SDK then performs a GET request to retrieve a JavaScript snippet that validates the request using the previously obtained path and CSRF token.
3. After the user confirms that the wallet is connected through WalletConnect and a QR code is generated, the SDK will send a POST request to the /attestation endpoint, match the id, and complete the initial dApp setup.
When inspecting the HTTP response, we noticed that the HTML body contained a token value that directly embedded a JavaScript code block. For experienced Web2.0 security experts, this pattern indicates a potential vulnerability for HTML injection or XSS (cross-site scripting) attacks. To verify this hypothesis, we modified the token value in the request above to the XSS payload <svg/onload=alert(document.domain)>, and the script was successfully executed, which means that the XSS vulnerability does exist. https://verify.walletconnect.com/index.js?token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
XSS is a type of injection attack that can embed malicious scripts in trusted websites.
In Web2.0 applications, attackers often use XSS vulnerabilities to access user cookies and hijack user network sessions and account control. Other attacks include redirecting users to harmful websites or initiating unauthorized requests. In the Web3.0 environment, XSS attacks can manipulate decentralized wallet connections and trick users into signing harmful transactions, thereby stealing assets.
We then conducted further investigation into the XSS issue, including testing various payloads to assess whether this vulnerability could evolve into a more serious risk such as SQL injection or remote code execution.
VerifyAPI is open source code, and after reviewing its code, we understood the root cause of the XSS vulnerability - the vulnerability comes from the way the validate_format function validates the format of the tag value.
if!CsrfToken::validate_format(&query.token){
Although it checks if the token value has a valid JWT header, it fails to thoroughly check the entire token value, so an attacker can still perform an XSS attack by appending a payload to the JWT token value.
fnvalidate_format(s:&str)->bool{jsonwebtoken::decode_header(s).is_ok()}
Proof of Concept
In order to verify the potential threat, our security team used the above XSS vulnerability to create a demonstration payload. Once used on a phishing website, the user will receive an asset authorization prompt. If the user clicks confirm without carefully checking the transaction data, the control of the assets will be authorized to the attacker.
Since users still see the domain name https://verify.walletconnect.com/, their vigilance against transaction signatures will be greatly reduced. For non-professional users, it is difficult to verify all the details of the transaction, and they may inadvertently sign malicious transactions and cause losses.
On the other hand, we did not find any methods that could amplify the impact of this vulnerability during our research, such as invading other modules of WalletConnect or initiating user passive actions.
solution
After detecting the XSS vulnerability, our team quickly provided a detailed report to the WalletConnect team. The WalletConnect team quickly confirmed our findings and set a timeline for resolving the issue.
WalletConnect's remediation includes updating the validate_format function. This update adopts a whitelist approach, allowing only letters, numbers, and the symbols -, ., and _ for tag values. While text injection is still theoretically possible, this critical update significantly reduces the risk of XSS attacks.
timeline
October 14, 2023: CertiK reports the vulnerability to WalletConnect.
October 16, 2023: WalletConnect acknowledges receipt of the report and confirms the issue.
October 20, 2023: WalletConnect updated the source code and pushed it to VerifyAPI.
October 20, 2023: CertiK confirms that the XSS issue has been mitigated.
Final Thoughts
This incident brings us an important reminder: the vulnerabilities unique to Web2.0 will not only continue to exist in the Web3.0 environment, but will also continue to evolve and pose greater security threats in newer forms. Therefore, proactive protection is crucial. Regular audits, penetration tests, careful vulnerability assessments, and real-time follow-up of the latest security trends are the best practices for Web3.0 companies to protect security and stay ahead of attackers. For DeFi users, it is crucial to stay vigilant at all times.
Always verify the URL of the website or platform carefully, especially the numbers and letters that look similar. Scammers often use similar URLs to deceive users.
When making a transaction, please carefully review all the details of the transaction. Wallet applications will occasionally release new warnings for new scams. Make sure you understand all the warnings from the wallet and confirm the accuracy of the destination address before clicking confirm.
In this article, we detailed the XSS vulnerability found in WalletConnect's VerifyAPI and its impact, emphasizing the security risks brought by Web2.0 attacks in the Web3.0 environment. Thanks to the WalletConnect team for their quick response and effective remediation, which reflects their strong sense of responsibility for the security of users and the Web3.0 industry.
