MetaMask Clickjacking Vulnerability Analysis: iframe Hijacking and Phishing Whitelist Bypass | Think like an attacker, defend like a guardian

On 3 June 2022, MetaMask (MM) publicly disclosed a severe Clickjacking vulnerability discovered by a white-hat researcher. The impact: when a user’s MM extension wallet is unlocked and they visit a malicious site, the site can use an iframe tag to embed the unlocked MM wallet page, hide it, and then guide the user to click on what appears to be the website — while the actual interaction happens on the unlocked MM page — thereby stealing the user’s cryptocurrency or NFTs. Given MM’s large user base and the number of projects that fork MetaMask, we immediately began reproducing the vulnerability and searching for its impact on other forked projects after MM’s disclosure.

The SlowMist Security Team then notified affected project teams as much as possible and guided them through remediation. We are now publishing this Clickjacking vulnerability analysis to help future projects avoid the same pitfall.

Vulnerability Analysis

Since MM did not provide a detailed explanation when disclosing this Clickjacking vulnerability — only describing the exploitation scenario and potential impact — I encountered quite a few pitfalls during reproduction (lots of blind guessing at the vulnerability point). To help everyone understand the vulnerability more smoothly, I’ll first cover a prerequisite concept before diving into the analysis.

Let’s look at Manifest - Web Accessible Resources. In browser extension wallets, there is a configuration called web_accessible_resources that restricts which resources of the extension can be accessed by web pages. By default, web pages cannot access resources within the browser extension; only the extension itself can access its own resources. In short, pages under http/https protocols cannot access chrome-extension resources by default. However, if the extension configures web_accessible_resources to expose its internal resources, they become accessible to pages under http/https protocols.

MM’s extension wallet, in versions prior to 10.14.6 (this article uses 10.14.5 as an example), had retained the configuration "web_accessible_resources": ["inpage.js", "phishing.html"], and this configuration was a key factor enabling the vulnerability to be exploited.

web_accessible_resources configuration

However, during the vulnerability analysis, I found that app/scripts/phishing-detect.js (v10.14.5) had already imposed protocol restrictions on the phishing page redirect. (In my understanding, there should be other pitfalls here, since the "web_accessible_resources": ["inpage.js", "phishing.html"] configuration was still present.)

Protocol restriction code in phishing-detect.js

Continuing to trace when this protocol restriction was introduced, we found it was added in the following commit — meaning that prior to v10.14.1, the lack of protocol restriction on redirects allowed the Clickjacking vulnerability to be easily exploited.

Related commits:

Commit diff for the protocol restriction

To verify the code analysis, we switched to v10.14.0 — the version before the protocol restriction — for testing, and found that the entire attack could be easily reproduced.

v10.14.0 vulnerability reproduction

However, MM’s public report also mentioned that the Clickjacking vulnerability was fixed in v10.14.6, so v10.14.5 is vulnerable. Looking back at the earlier conjecture: (in my understanding, there should be other pitfalls here, since the "web_accessible_resources": ["inpage.js", "phishing.html"] configuration was still present).

After repeatedly reviewing the code, in v10.14.5 and earlier versions, when the phishing page warning is displayed, if the user clicks “continuing at your own risk,” the hostname is added to the local whitelist. As a result, the MetaMask Phishing Detection warning no longer appears the next time the user visits that site.

For example, the phishing site ethstake.exchange — by embedding it in a web page via an iframe tag and exploiting the Clickjacking vulnerability, the malicious phishing site can be added to the whitelist, and MM will no longer show a warning the next time the user visits the phishing site.

Using Clickjacking to add a phishing site to the whitelist

Fix and Impact

As shown in the analysis above, MM actually fixed two Clickjacking vulnerabilities. During reproduction, we found that the latest v10.14.6 has removed the web_accessible_resources configuration entirely, thoroughly fixing the clickjacking issue on the MetaMask Phishing Detection page.

(1) Fix for using the Clickjacking vulnerability to induce users into making transfers (affected versions: <= v10.14.0):

https://github.com/MetaMask/metamask-extension/commit/c1ca70d7325577835a23c1fae2b0b9b10df54490

(2) Fix for using the Clickjacking vulnerability to add phishing sites to the whitelist (affected versions: <= v10.14.5):

https://github.com/MetaMask/metamask-extension/commit/7199d9c56775111f85225fe15297e47de8e2bc96

The SlowMist Security Team immediately contacted the project teams, but as of now, some have not yet responded — and it has been 11 days since MM disclosed the vulnerability. To prevent users from suffering losses due to this vulnerability, the SlowMist Security Team has chosen to publish the vulnerability analysis. If any affected project team sees this article and needs assistance, please contact the SlowMist Security Team.

Final Thoughts

The SlowMist Security Team reminds browser extension wallet project teams that if you are developing based on MetaMask < v10.14.6, you should check whether you are affected by this vulnerability. If you need assistance, please contact the SlowMist Security Team.

The core issue with this vulnerability is the inconsistency between the web_accessible_resources configuration and the phishing warning mechanism — the extension exposed phishing.html to web pages without considering that the page itself could be embedded via iframe and clickjacked. This is a classic “consistency gap between declaration and implementation”: the configuration’s intent was to make the phishing detection page accessible, but the actual effect was that attackers could hijack this page to bypass phishing detection itself. For all projects forking MetaMask, it is essential to sync upstream security fixes promptly and to independently audit configurations like web_accessible_resources that involve resource exposure boundaries.

Reference:

https://medium.com/metamask/metamask-awards-bug-bounty-for-clickjacking-vulnerability-9f53618e3c3a