Pentesters Guide to Web3 dApps: Exploiting Browser Extensions

We have teamed up with Jason Doyle, a security researcher and penetration tester in crypto, to share his guide on getting started with pentesting web3 browser extensions. He has already used the techniques described below to help uncover and fix several vulnerabilities in popular crypto extensions, including ours, Wallet Guard, Pocket Universe and others.

At Revoke.cash we are very thankful to people like Jason that help us strengthen our security and protect our users, and we encourage more ethical white-hat hackers to get started with pentesting web3 browser extensions and report any vulnerabilities they find to the affected providers.

Introduction

Excited to unveil a first-of-its-kind Web3 dApp penetration testing methodology and mini-course after rigorously reviewing crypto wallet extensions and scam detection engines! Stay ahead in web app pentesting with this free training on Web3 browser extensions. Learn to intercept, modify, and replay communications between web dApps and the blockchain, discover how scam detection engines analyze raw transaction requests, and practice three testing techniques to circumvent their security controls.

This approach offers an engaging opportunity for pentesters to explore front-end Web3 dApp components without delving too deeply into the complexities of smart contracts and EVMs. Some basic understanding of conventional web attacks and familiarity with crypto wallets is recommended.

Download the training materials and vulnerable browser extension versions to follow along for hands-on practice! Most versions of extensions I cover are no longer available online but they can be downloaded from course materials on my GitHub repo.

Browser extensions mentioned in this article include: Coinbase Wallet, MetaMask, Pocket Universe, MintDefense (now @Kerberus), Wallet Guard, Scam Sniffer, AegisWeb3, Revoke.cash, Web3 Antivirus, Blockaid, and ChainGPT.

Key Components and Inter-Process Communications

To grasp how certain security controls can be tested, we must first understand the infrastructure they aim to protect, the key components, and communications between them. The typical data flow without any security extensions installed involves the following components:

Web dApp: This is the decentralized application running in the browser. It uses JavaScript libraries like ethers.js or web3.js to send requests to the Ethereum Provider based on user actions within the dApp.
Ethereum Provider: An API injected into the webpage by MetaMask or other Ethereum wallets. This provider acts as a bridge or interface that manages JSON-RPC requests and responses between the dApp and wallet.
Wallet Extension (e.g., MetaMask): The user's wallet interface, handling account management, transaction signing, and submitting transactions to the Ethereum network for validation. The wallet prompts the user for approval of transactions or signing requests initiated by the dApp.

As illustrated in the walkthrough video, we were able to see and even replay the communications from the OpenDea web dApp which triggered MetaMask to sign a request. Here's the logging script we used:

window.addEventListener('message', function (event) {
  if (event.data.data.data['method'] == 'eth_sendTransaction') {
    console.log('Tx Received', event.data);
  }
});

Primer on Scam Detection Engines

This next section will be an introduction to scam detection extensions that intercept and scan transactions between web dApps and the Ethereum Provider for potential risks. They alert users about suspicious requests, like transferring assets to phishing addresses.

Extensions like Pocket Universe and Wallet Guard provide transaction warnings for user review, while Mint Defense (now Kerberus) automatically blocks risky transactions or forwards safe ones to MetaMask without any need for user feedback.

The former options aim to empower users by providing transaction details and heuristic data for making informed decisions, while the latter takes a zero-assumed knowledge approach and proactively makes decisions on behalf of the user. The video below shows how these engines ingest transaction data and deal with a real scam site, allowing you to see them in action.

We are not here to create undetectable scam websites. All security vulnerabilities and detection bypass methods discussed in this series have been reported to the affected providers. Our focus is on exploring techniques to test for new software bugs in Web3 browser extensions, regardless of their category.

While we are currently examining scam detection mechanisms, our aim is to find ways to evade their data interpretation processes to bypass detection. This knowledge can serve as a foundation for developing your own test scenarios and can be applied to other dApp-related extensions that you might need to test as an ethical hacker.

Security Bypass Types and Test Cases

This section outlines two common types of security extension bypasses — interception and translation — each highlighting a different attack strategy or outcome. Additionally, we'll explore three testing techniques used to find extension bypasses, including input modification, alternate invocation, and protocol manipulation.

Download the training materials and vulnerable browser extension versions to follow along for hands-on practice! Most versions of extensions I cover are no longer available online but they can be downloaded from course materials on my GitHub repo.

The goal is to submit an unsafe or malicious transaction request that can be properly interpreted by a victim's MetaMask wallet and considered valid by the blockchain network, while simultaneously being invalid, out of scope, or seen as safe in the eyes of the targeted scam detection engine. Bypassing scam detection is one thing, but if MetaMask (or the target wallet) can't read the transaction payload, your bypass won't work. Without a readable payload, victims can't approve the scam transaction.

Definitions for the common bypass types:

Interception Bypass: This occurs when the attacker sends the request in a way that evades the extension's user interface completely and any preventive measures it might have in place. The request is shown only in MetaMask as if the security extension was not even installed. Sometimes referred to as a "full bypass".
Translation Bypass: In this scenario, the request reaches the security extension, and its UI attempts to process the transaction. However, due to a failure in interpreting the transaction correctly, it results in an error or false negative, allowing harmful transactions to proceed without proper scrutiny. Sometimes referred to as a "partial bypass".

Input Validation Testing - Data Types & Formats

The first of three techniques we'll use to test for extension bypasses will be input validation testing by modifying data types and formats. A common technique for us Web2 pentesters when checking client-side or server-side applications for vulnerabilities in input validation. This technique is used by submitting transactions in formats that may challenge the interpretation or interception capabilities of the extensions. Examples of this could include using incorrect data types or unexpected data structures.

The goal is to either trigger an error condition in the extension or cause the parser to misinterpret the input data's request type or parameter values to evade it's detection logic. In other words, we want the extension to either throw an exception so our request can't be scanned, or make the extension think our request doesn't need to scan the transaction because it believes it is an unsupported request.

Business Logic Testing - Alternate Invocation

This next testing technique we can refer to as alternate invocation. One bypass I privately reported over a month ago to a handful of extension providers is actively being exploited today, as revealed by the security researcher Bernhard Mueller in his excellent write-up uncovering the obfuscated mechanisms of a popular scam product known as Angel Drainer.

So, what exactly do I mean by 'Alternate Invocation'? It's essentially about finding new ways to call or invoke a target process to evade detection. Until now, we've interacted with MetaMask through the standard Ethereum Provider API, using the ethereum.request syntax to send transaction details, similar to what happens in dApps using the ethers.js or web3.js libraries. The provider then delivers that request as a JSON-RPC message and MetaMask displays the message or transaction in the UI for approval.

But there's actually another way to invoke MetaMask directly by crafting your own JSON-RPC message, bypassing the usual Ethereum API altogether. This is done through window.postMessage and, interestingly, not all security extensions caught this behavior, which allowed it to bypass several of them.

So let's demonstrate this bypass and see how it works.

I reported this vulnerability to MintDefense (now Kerberus), Web3Antivirus, Pocket Universe, and Fire (retired) around March 6, 2024 but it's still being exploited in the wild more than two months later in select extensions that never patched it.

Business Logic Testing - Protocol Manipulation

Let's discuss the final testing technique: Protocol Manipulation. This method involves disrupting or altering the normal flow of operations to induce an adverse effect that may benefit an attacker. For instance, a Man-in-the-Middle (MITM) attack can occur when an attacker secretly intercepts and potentially alters the communication between two endpoints that believe they are directly communicating with each other. This allows an attacker to modify or spoof incoming or outgoing requests or responses.

The following extension bypass example is a type of MITM that tricks the protocol into accepting a falsified response. But I begin the video by showing a protocol analysis methodology so you know how to test for these yourselves.

As with most penetration tests, you typically start with a passive reconnaissance phase before moving on to a more active discovery phase that focuses on identifying a target's attack surface. In protocol analysis, I usually kick off by simulating data flows as a regular user and documenting inputs and outputs. It's essential to pay attention to user-controllable inputs and outputs since these could be potential attack vectors.

You'll witness this process in action in the upcoming video, which, to me, was the most interesting of them all - transitioning from discovery to method hooking and spoofing, showcasing the final exploit.

That's all for now. Keep an eye out for the upcoming series on how traditional web app vulnerabilities like Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF) bring about entirely new attack vectors in the Web3 world of web dApps. The instances of Web2-style attacks that siphon digital assets from a victim's crypto wallet, I suspect, will become more commonplace than we would all like in the near future.