我们最近发现了一种新型的网络钓鱼技术，可用于在连接的去中心化应用（DApp）身份方面误导受害者。
我们将这种新型的网络钓鱼技术命名为 Modal Phishing（模态钓鱼攻击）。
攻击者可以向移动钱包发送伪造的虚假信息冒充合法的 DApp，并通过在移动钱包的模态窗口中显示误导性信息来诱骗受害者批准交易。这种网络钓鱼技术正在广泛使用。我们与相应的组件开发人员进行了沟通，并确认他们将发布新的验证 API 以降低该风险。
在 CertiK 对移动钱包的安全研究中，我们注意到Web3.0 货币钱包的某些用户界面（UI）元素可以被攻击者控制用来进行网络钓鱼攻击。我们将这种钓鱼技术命名为 Modal Phishing，因为攻击者主要针对加密钱包的模态窗口进行钓鱼攻击。
模态（或模态窗口）是移动应用程序中经常使用的 UI 元素。模态通常显示在应用程序主窗口顶部。这样的设计通常用于方便用户执行快速操作，如批准/拒绝Web3.0 货币钱包的交易请求。
Web3.0 货币钱包上的典型模态设计通常提供供用户检查签名等请求的必要信息，以及批准或拒绝请求的按钮。
真实交易批准模式与网络钓鱼交易批准模式对比
在上方截图中，我们展示了 Metamask 上一个常规的交易审批模态窗口是如何出现的。
当一个新的交易请求被连接的去中心化应用程序（DApp）初始化时，钱包会展示一个新的模态窗口，并要求用户进行人工确认。
如上图左侧所示，模态窗口通常包含请求者的身份，如网站地址（此例中为 localhost）、图标等。如 Metamask 这样的一些钱包也会显示有关请求的关键信息，在实例中我们看到一些 UI 元素被标记为“Confirm”，以提示用户这是一个常规的交易请求。
然而，这些用户界面元素可以被攻击者控制以进行 Modal Phishing 攻击。在右侧的截图中，我们可以看到攻击者可以更改交易细节，并将交易请求伪装成来自“Metamask”的“Security Update”请求，以诱使用户批准。
如截图所示，攻击者可以操纵多个 UI 元素。
因此我们将在本文中为大家分享两个典型案例，并确定那些可被攻击者控制的 UI 元素。
详细信息如下：
① 如果使用 Wallet Connect 协议，攻击者可以控制 DApp 信息 UI 元素（名称、图标等） 。
② 攻击者可以控制某些钱包应用中的智能合约信息 UI 元素。
攻击者控制的 Modal 和相关的信息源（DApp 信息和方法名称）示例
示例①：通过 Wallet Connect 进行 DApp 钓鱼攻击
Wallet Connect 协议是一个广受欢迎的开源协议，用于通过二维码或深度链接将用户的钱包与 DApp 连接。用户可以通过 Wallet Connect 协议将他们的钱包与 DApp 连接起来，然后与该协议进行进行交易或转账。
在Web3.0 货币钱包和 DApp 之间的配对过程中，我们注意到Web3.0 货币钱包会展示一个模态窗口，显示传入配对请求的元信息——包括 DApp 的名称，网站地址，图标和描述。Web3.0 钱包展示的这些信息和方式根据 DApp 名称、图标和网站地址不同而变化，以供用户查看。
但是这些信息是 DApp 提供的，钱包并不验证其所提供信息是否合法真实。比如在网络钓鱼攻击中，某雷碧可以假称为某雪碧（均为 DApp），而后在用户发起交易请求之前诱骗用户与其连接。
小伙伴们可以复制链接【https://www.youtube.com/watch? v=x 6 muJmDBC 3 o】到浏览器查看 CertiK 为此做的一个小测试。
在该视频中，CertiK 展示了攻击者是如何「欺瞒」Uniswap DApp 的——攻击者声称自己是 Uniswap DApp，并连接 Metamask 钱包，以此欺骗用户批准传入的交易。
在配对过程中，钱包内显示的模态窗口呈现了合规 Uniswap DApp 的名称、网站网址和网站图标。
由于网址中使用了 https 方案，所以还显示了一个挂锁图标，这样显得模态窗口更为逼真和合法了。在配对过程中，只要受害者想在假 Uniswap 网站上进行交易操作，攻击者就可以替换交易请求参数（如目的地地址和交易金额）来窃取受害者的资金。
请注意，虽然不同的钱包上的模态设计不同，但攻击者是始终可以控制元信息的。
下图展示了当我们将 ZenGo 和1Inch钱包连接到钓鱼网站的 DApp 时，配对批准模式的样子。
如上例所示，被大规模使用的 Wallet Connect 协议并未验证配对的 DApp 信息的合法性。被操纵的元信息被钱包应用程序进一步使用并呈现给用户，这可以被用来进行 Modal Phishing。作为一个潜在的解决方案，Wallet Connect 协议可以提前验证 DApp 信息的有效性和合法性。Wallet Connect 的开发人员已经承认了知晓这个问题，并正在研究相关解决方案。
示例② ：通过 MetaMask 进行智能合约信息网络钓鱼
你可能已经注意到，在 Metamask 批准模态的图标或网站名称下，有另一个视图，显示了一个不固定的字符串例如“Confirm”或“Unknown Method”。这个 UI 元素是由 Metamask 设计的，用于识别相应的交易类型。
在呈现交易批准模态时，Metamask 会读取智能合约的签名字节，并使用链上方法注册表查询相应的方法名称，如以下代码所示。然而，这也会在模态上创建另一个可以被攻击者控制的 UI 元素。
MetaMask 的智能合约方法名称说明
我们可以看到 Metamask 上有一个交易请求模态，其被标记为“Security Update”。攻击者建立了一个钓鱼智能合约，其有一个 SecurityUpdate 具备支付函数功能，并允许受害者将资金转入该智能合约。
攻击者还使用 SignatureReg 将方法签名注册为人类可读的字符串“SecurityUpdate”中。如前所述，当 Metamask 解析这个钓鱼智能合约时，它使用函数签名字节查询相应的函数方法，并在批准模态中呈现给用户。
从这个智能合约的交易可以看出，这个特定的钓鱼智能合约已经运行了 200 多天。
开发者应该时刻注意监测那些会向用户呈现的内容，并采取预防措施过滤掉可能被用于网络钓鱼攻击的词语。
在本文中，我们为大家展示了Web3.0 货币钱包上不应盲目信任的常见 UI 组件——模态窗口。
模态窗口中的某些 UI 元素可以被攻击者操纵，以创造出非常「真实且有说服力」的钓鱼陷阱。因此，我们将这种新的网络钓鱼技术命名为 Modal Phishin（模态钓鱼攻击）。
这种攻击发生的根本原因是钱包应用程序没有彻底验证所呈现的 UI 元素的合法性。
例如，钱包应用程序直接信任来自 Wallet Connect SDK 的元数据，并将其呈现给了用户。
Wallet Connect SDK 也并不验证传入的元数据，这在某些情况下使得呈现的元数据可以被攻击者控制。在 Metamask 中，我们可以看到类似的攻击原理也被攻击者滥用，在模态窗口中显示欺诈性的智能合约函数方法名称。
总体而言，我们认为钱包应用程序的开发者应该始终假设外部传入的数据是不可信的。开发者应该仔细选择向用户展示哪些信息，并验证这些信息的合法性。除此之外，用户也应通过对每个未知的交易请求保持怀疑的态度来守好自己安全上的「一亩三分地」。
