We recently identified a new type of phishing technique that can be used to mislead victims about the identity of connected dApps. We name this novel phishing technique Modal Phishing. Attackers can send crafted messages to mobile wallets, impersonating a legitimate dApp and tricking victims into approving transactions by showing misleading information in the modal of mobile wallets. This phishing technique is being actively used in the wild. We communicated with the corresponding vendor to address the risks. New Verify APIs will be released as mitigations.

What is Modal Phishing?

During CertiK’s security research on mobile wallets, we noticed that certain user interface (UI) elements of crypto wallets can be controlled by attackers to conduct phishing attacks. We name this phishing technique Modal Phishing, as the attacker mainly targets the modal window of crypto wallets.

A modal (or modal window) is a UI element used in mobile applications. The modal normally appears as a window sitting on top of an application's main window. Such a design is often used for users to perform a quick operation, such as approving/rejecting transaction requests on cryptocurrency wallets. A typical modal design on crypto wallets often includes necessary information for users to examine the incoming request, and buttons to approve or deny the request.

In the above screenshots, we show how a regular transaction approval modal window appears on Metamask. When a new transaction request is initialized by a connected decentralized application (dApp), the wallet renders a new modal window asking for the user’s confirmation. As shown in the screenshot on the left, the modal window normally contains the identity of the requester, such as a website address (localhost), icon, and so on. Some wallets, such as Metamask, also show key information about the request, which is shown tagged “Confirm” to suggest to the user that this is a regular transaction request.

However, these UI elements can be controlled by attackers to carry out modal phishing attacks. On the right screenshot, we can see that the attacker can change the transaction details and camouflage the transaction request to be a “Security Update” request from “Metamask” to trick users into approving it.

As shown in these screenshots, there are multiple UI elements that can be manipulated by attackers. In this blog, we will introduce two phishing scenario examples and identify the UI elements that attackers can control. More specifically, we show that:

Examples of Attacker Controlled Modals and Associated Information Source (dApp Info & Method Name)

Example 1: dApp Phishing via Wallet Connect

Wallet Connect protocol is a popular open-source protocol used to connect a user's wallet with a dApp via a QR code or deep linking. Users can connect their wallet to dApps via the Wallet Connect protocol and then interact with the protocol.

During the pairing process between the crypto wallet and the dApp, we noticed that the crypto wallet launches a modal window to show users the meta information of the incoming pairing request. This includes the dApp name, website address, icon, and description. The way crypto wallet presents such information are often customized but usually the dApp name, icon and website address is included for the user to review.

However, this information is provided by the dApp, wallets do not verify if the information given is legitimate. In a phishing attack, a fake dApp can claim to be another dApp and trick users into connecting to it before initiating transaction requests. In this video, we show how an attacker can claim to be Uniswap dApp to connect with a Metamask wallet and trick users into approving the incoming transactions.

In our demo, we show how the attacker spoofs the Uniswap dApp. During the pairing process, the modal window shown in-wallet presents the legitimate Uniswap dApp name, website url, and website icon. Due to the use of the https scheme in the URL, a padlock icon is also shown to further legitimize the modal window. After the pairing process, whenever the victim wants to perform a swap operation on the fake Uniswap website, the attacker can replace the transaction request parameters (such as destination address and transaction amount) and steal funds from the victim.

Note that although the modal design varies on different wallets, the attacker can always control the meta information. Below we show how the pairing approval modal looks when we connect ZenGo and 1Inch wallet to the phishing dApp.

Now knowing that the pairing and transaction modal windows can be manipulated by attackers, we can see that such an attack can be used to convince users that the transaction request comes from a legitimate dApp. As shown in the following screenshot, we create a fake dApp which claims to be “Metamask” and initiate a phishing smart contract. We show that an attacker can impersonate a dApp from Metamask or Uniswap in the transaction approval modal.

As shown in the above example, the widely used Wallet Connect protocol does not verify the legitimacy of paired dApp information. The manipulated meta information is further consumed by wallet apps and presented to users which can be used as Modal Phishing. As a potential mitigation, the Wallet Connect protocol should verify the dApp information ahead of time. Wallet Connect developers have acknowledged this issue and are working on a solution.

Example 2: Smart Contract Info Phishing via MetaMask

You may have already noticed that under the icon or website name on the approval modal from Metamask is another view showing an unfixed string, such as “Confirm” or “Unknown Method”. This UI element is designed by Metamask to identify the corresponding transaction type.

While rendering the transaction approval modal, Metamask reads the smart contract's signature bytes and queries the corresponding method name using an on-chain method registry, as shown in the following code. This, however, also creates another UI element on modal that can be controlled by attackers.

Phishing campaigns that utilize malicious modal windows have been gaining attention on Twitter recently.

We can see a transaction request modal on Metamask marked as “Security Update”. The attacker built a phishing smart contract which has a SecurityUpdate payable function and allows the victim to transfer funds into this smart contract. The attacker also used SignatureReg to register the method signature into the human-readable string “SecurityUpdate”. As previously mentioned, when Metamask parses this phishing smart contract it queries the corresponding function methods using the function signature bytes and presents it in the approval modal to users.

As we can see from the transactions of this smart contract, this particular phishing smart contract has been used for over 200 days.

Combining these controllable UI elements, the attacker can create a very convincing transaction request which is shown as a “Security Update” request from “Metamask” seeking the user’s approval.

In the above example, we show how smart contract information related UI elements on wallets can be manipulated by phishing attackers.

Although we use Metamask as the example here, other wallets may also have similar vulnerabilities. The developers of wallet applications should always be careful about what to present to users, and take precautions to filter out the possible words that can be used in phishing attacks.

Conclusion

In this blog, we show that a common UI component – modal windows – on crypto wallets cannot be blindly trusted. Certain UI elements from modal windows can be manipulated by attackers to create very convincing phishing scenarios. Thus we name this new phishing technique Modal Phishing.

The root cause of such an attack is that the wallet applications do not thoroughly verify the presented UI elements. For example, the wallet application simply trusts the metadata from Wallet Connect's SDK and presents it to users. The Wallet Connect SDK does not verify the incoming metadata either, which in certain situations allows the rendered metadata to be controlled by an attacker. In Metamask, we can see the similar attacking principle is also abused by attackers to show fraudulent smart contract function method names in modal windows.

In general, we believe the developers of wallet applications should always assume incoming data is untrustworthy. Developers should carefully choose what information to present to the user and verify the legitimacy of this information. Users can play their part by maintaining a skeptical attitude to every unknown transaction request.

Read more: https://www.certik.com/resources/blog/4uOOlTALvO5p7aNm1X4rey-modal-phishing-in-web3-mobile-wallets