How Safe Is Your Web3 Application?
As Crypto, Blockchain, NFT, Decentralized Applications, Web3, and Metaverse are becoming more popular among every person with access to the internet these days, we see more and more people getting into the crypto world and as a result of that, there are more attempts to steal crypto assets.
In this post, I will discuss the web3 application’s client-side vulnerabilities, a breach that I found on a popular NFT marketplace (which asked not to be disclosed), that could allow hackers to steal assets using client code execution, and the need for an official security regulation on Web3 applications.
Web3
“an idea for a new iteration of the World Wide Web based on the blockchain, which incorporates concepts including decentralization and token-based economics”. Wikipedia
In other words, it’s a web application that interacts with data via a decentralized blockchain instead of a dedicated server. The most common use cases for Web3 applications today are NFT marketplaces, crypto exchanges, metaverse, and crypto games.
The Web3 application interacts with a smart contract, which is a code that runs in the blockchain that contains the application data and logic. Dapp (“Decentralized application”) is the definition of a web application that runs the blockchain.
To interact with the blockchain, a user needs to have a “bridge” to the blockchain. That bridge is usually called a wallet, which is software that is installed often in the browser as an extension and is responsible for connecting with the blockchain behind the scenes. MetaMask as an example is as of today the most popular wallet.
Web3 application overview
The interaction with the wallet is done via global Javascript code (e.g window.ethereum object) which is injected by the extension to each page.
The window.ethereum object interacts with the extension, and the extension code interacts with a provider that eventually interacts with the actual blockchain.
The Missing piece
As a technology, Web3 has some benefits, and it can solve some real-life problems (e.g authentication layer, scale issues, etc), but as of today, there is no official security guideline or recommendations for its security aspects when dealing with users’ crypto assets. In Web2 we can compare it to the security standards of websites that are using credit card transactions.
PCI DSS (“Payment Card Industry Data Security Standard”) is the standard for the usage of credit card transactions on websites. It was introduced in 2004 to minimize fraud on web applications by implementing methods such as data encryption, using a firewall, and protecting the data of the user. Protecting data breaches can be done by redirecting the user to a purchase page, using external windows (iframe) for sensitive areas, etc.
The credit card industry is a veteran in the fraud battlefield, but even with standards, compliance restrictions, and advanced security methods it will “lose” ~34 billion dollars in 2022 for fraudulent transactions (according to Nilson Report )
In Web3, there is no such compliance or regulations at the moment, so the possibility that a web3 application will be breached by application-layer exploits is not too low, and since the interaction with the blockchain is done via client code, it can be manipulated with the wrong application architecture.
External code execution on websites (e.g third-party scripts) is always problematic in the matter of security, and there are many examples of breaches that were caused by supply-chain attacks or browser extensions/plugins.
When I checked several popular web3 applications (NFT marketplaces and exchanges) I assumed that some of them were hackable, since they were built in a way that allowed unsafe client code to manipulate some of their protocols.
The exploit that I found was on the actual NFT marketplace that I’m using personally.
It could have let hackers change the address of the recipient on the NFT transfer action using external code execution. I was able to prove it using a chrome extension that I created.
At first, I tried to understand how the application is built, and then I tried to understand the transfer protocol and checked for the right places that could manipulate it.
After I understood what I needed to change, I searched for breaches that would let me execute the code that will modify the transfer protocol.
Transfer protocol
Steps:
1. The user fills in the transaction details into the form area (asset, recipient, and quantity) and clicks “Transfer”
2. DOM event is triggered
3. The application sends an HTTP request with the transaction data to the back-end
4. The application sends a transaction request to the Metamask client SDK
5. Metamask client SDK sends an event to the extension
6. Metamask extension shows a popup, which the user needs to sign (the transaction approval)
7. Metamask sends a transaction to the blockchain
8. Transfer confirmation (the NFT has been given to the recipient address)
The Breach
These are the areas that I searched for when I investigated the application:
- Transfer protocol (application network APIs)
- Code discovery
- Code execution
- Input Areas
Transfer protocol
The transfer protocol (step #3) wasn’t too hard to understand.
It wasn’t encrypted, there wasn’t any data integrity check for the payload, and it was able to be manipulated (I checked it using a simple terminal).
Code Discovery
This part is about making the application code readable.
Code obfuscation (TL;DR — “make it hard to read”) tends to be related to malicious scripts (you can read about it here), but it is helpful when you want sensitive code flows to be hard to understand on the client-side.
When I checked the source code of the application I saw that it wasn’t obfuscated and the transaction flow was easy to understand. I could see the structure of the application by its bundle code (which was literally in development mode for some reason…) and I could also see which dependencies the application is using behind the scenes (it would potentially help an attacker to find some more attack vectors).
Being able to understand the application code gave me some hints on how to breach it.
Code execution
Missing CSP headers (Content Security Policy) allowed any script to be fetched to the site. I used this breach to inject an external script using a chrome extension code.
Input Areas
Sensitive Input elements weren’t “secured” (missing PCI implementations), so sensitive DOM elements could be hacked by code execution. I used it to manipulate the data of those elements.
Breach code
I needed to inject code that would be able to execute in the context of the application, so I injected an external script by adding it as a script element to the DOM from the content script (client script that is executed by the extension).
code Injection
The extension’s content script code is executed in an Isolated world (TL;DR — “clean” execution environment), so I needed to inject a script that will execute code in the application context.
code execution
This code is a basic example of how I changed the value of the input element, so the asset will be transferred to a different wallet.
I created MutationObserver and observed the DOM for input elements that might indicate the input that changes the address of a transfer transaction.
I modified the value (HTMLInputElement.prototype.value) property getter of the input of the recipient of the transfer protocol using defineProperty, so when another code will try to get its value (step #3 of the transfer protocol), it will retrieve a different one.
I also was able to hack the transfer protocol by modifying the network APIs directly, but the marketplace requested to not disclose this technique publicly.
Conclusion
When I found out that the application is not safe for users I contacted the marketplace about it, and the incident was managed by Hackerone platform (bug bounty platform).
Eventually, the breaches were fixed, and the incident was closed.
Web applications security guidelines
A general solution for securing users’ data on web3 applications, and its application layer in general, is not too different from any other web application security solution.
These three rules will reduce most of the security risks on web applications:
- Protect The application from unwanted external code execution
For example, use CSP (Content Security Policy) headers to restrict the sources (domain) of the resources that are fetched by the application.
If this header is shown on the response of the application document, the browser will restrict the resources that the application will fetch, for reducing the chance that external code will be able to be executed. - Protect sensitive DOM elements (e.g forms) from being manipulated
Use known methods for isolating sensitive DOM elements from the main execution of the application (TL;DR — use isolated iframe for that).
This exact method is used to protect credit card data on websites.
In other words, tread areas that are handling crypto transactions like you would tread areas that would use credit card data. (hint — this is part of PCI regulations and standards…) - Secure payload data (data integrity)
make sure that the payload that transfers sensitive data is not able to be manipulated (or even make this effort to be hard for attackers to implement). There are several techniques for such a thing from using a checksum on the payload to checking the source of each request using dynamic tokens.
Data flow
It is important to understand that the transaction data flow has two main parts.
- Application → Wallet SDK
The flow of the data from the application code to the extension code - Wallet SDK → Blockchain
The flow of the data from the extension code to the blockchain
This post is about problems in the first flow (Application → Wallet SDK), and not about the security of the integration with the extension itself.
It will be logical to guess that the second flow (Wallet SDK → Blockchain) also has some flaws, but it is not in the scope of this post.
1. This is not a call to hack web3 applications, but another proof that web3 applications should have official security guidelines.
2. The reason that I searched for the breach is that I wanted to check if the NFT marketplace that I’m using is safe.
3. The breach is not too sophisticated, in the technical aspect of it (relative to other crypto breaches). I used common techniques that malware is using to steal credit card data from users on infected web applications, but the result of the breach could be devastating for anyone who could potentially lose an expensive bored ape for fraud…
