By: Thinking

background

As the TON ecosystem project heats up, Web3 phishing gangs have also begun to enter the battlefield of the TON ecosystem. Currently, the TON ecosystem uses the TonConnect SDK to solve the problem of cross-platform/application wallet connection and interaction. Such solutions will inevitably encounter a problem: how to solve the domain name verification during cross-platform/application communication?

Usually, in order to allow users to use wallets to connect to DApps or confirm whether the source of the signature request is reliable, the wallet will prompt the source domain name on the request approval page, so that users can better verify and confirm whether the source of the request is consistent with the source of their operation, thereby avoiding fraud from signature requests from malicious sources.

The SlowMist security team has previously discovered domain name verification security issues when cross-platform/application communication between wallets and DApps. We have communicated with the MetaMask SDK and WalletConnect Web3Modal project teams and found that this problem is difficult to handle. Therefore, MetaMask and WalletConnect have not yet completely solved this problem.

Recently, we discovered that the TonConnect SDK in the TON ecosystem also has the same problem, so we disclose it here in the hope of helping users identify and prevent such risks.

analyze

Usually, when the browser extension wallet interacts with DApp, a JS script (content script) is injected into the web page to forward messages between the web page and the browser extension. When the web page and the content script communicate, window.postmessage and window.addEventListener are used. Window.addEventListener can further process the message by obtaining the origin of the message. The specific operations include displaying the origin of the message in the browser extension wallet, determining whether the origin of the message is in the blacklist, and authenticating the origin of the message. Since the origin is obtained by relying on the function provided by the browser, it cannot be forged.

However, when cross-platform/application messaging is in progress, messages are usually forwarded through a message forwarding server, which makes it difficult for the message forwarding server to check the domain name from which the message originates (because the client's data can be forged). As a result, there is a problem of message source being forged. The following are two scenarios for cross-platform/application messaging:

  • Browser web page <=> Message forwarding server <=> Wallet APP

  • Other APPs <=> Message forwarding server <=> Wallet APP

Taking TonConnect SDK as an example, DApp uses TonConnect SDK as a tool for message communication between wallet and DApp. It is necessary to configure dappMetadata when connecting to TonConnect SDK. However, the data of dappMetadata is difficult to verify. Malicious DApp can modify dappMetadata to disguise itself as a trusted website, thereby defrauding users.

You can fake the origin to ton.org by setting manifest.json to the following content:

The following is the PoC after deploying the above code. Next, we scan and parse the QR code.

TonConnect SDK passes the manifestUrl data to the wallet application via a QR code, unlike other SDKs that forward it via a message forwarding server. The wallet application will parse the manifestUrl data obtained by scanning. It can be found that we can easily forge the origin of any DApp to communicate with the wallet, that is, attackers can use this flaw to forge well-known DApps to carry out phishing and fraud attacks.

https://app.tonkeeper.com/ton-connect?v=2&id=24e3f2fdbea19fcd4fe03da3bc3d534d8b988edd01736f0b127a70cf2c531661&r={"manifestUrl":"https://tonconnect.pages.dev/tonconnect-manifest.json","items":[{"name":"ton_addr"}]}

After the connection is successful, the forged DApp initiates a signature request through TonConnect. Once the user confirms, the wallet will broadcast the signed data to the blockchain. Since the origin forgery is extremely deceptive, it is difficult for users to identify the source of the connection and signature application.

In MetaMask SDK, by modifying dappMetadata, you can forge a well-known DApp to carry out phishing and fraud attacks:

Similarly, in WalletConnectModalSign, just modify the metadata:

Summarize

Since there is currently no good solution to the domain name verification problem when mainstream wallets and DApps communicate across platforms/applications, SDK project parties usually add some additional verification methods, such as: WalletConnect's Verify mechanism (https://docs.walletconnect.com/cloud/verify). After the DApp passes the domain name verification, the wallet party can use the Verify API to determine whether the domain name is credible.

However, many mainstream DApps do not verify domain names, so this solution is also difficult to solve forged origin phishing attacks. If the vast majority of DApps use the Verify method to authenticate domain names, it will largely prevent users from being subjected to increasingly rampant forged origin phishing attacks. The SlowMist security team also recommends that users pay attention to identifying whether the website they open is consistent with the domain name requested for approval to avoid such attacks.