Deanonymization of OpenSea NFT holders via cross-site search vulnerability

TLDR

Recently, a cross-site search vulnerability affecting the popular NFT marketplace OpenSea was discovered. When successfully exploited, this issue allows the de-anonymization of OpenSea users by linking an IP address, a browser session or an email under certain conditions to a specific non-fungible token (NFT) and therefore a wallet address, potentially revealing a user’s identity.

The root cause of this vulnerability was the misconfiguration of the iFrame-resizer library used by OpenSea. The misconfiguration allowed the cross-site search vulnerability to exist, leading to the potential exposure of user identities.

After the vulnerability was disclosed, OpenSea quickly released an update to fix the problem. The patch restricted cross-origin communication, reducing the risk of further exploitation. The fix was validated by the Imperva Red Team, who confirmed that the security issue was properly resolved.

Introduction

The world of Web3 and decentralized applications (dApps) is expanding rapidly, bringing with it a number of new opportunities and challenges. As the popularity of dApps increases, so does the potential for security breaches and vulnerabilities.

Recent years have seen several high-profile hacks and vulnerabilities affecting popular Web3 platforms, highlighting the need for developers to prioritize security and privacy. From the infamous DAO hack on the Ethereum blockchain to more recent hacks targeting cross-chain bridging, it’s clear that the security of Web3 applications must be a top priority.

In this blog post, we will dive into the details of the OpenSea vulnerability and discuss the importance of proper cross-origin communication restrictions to protect user anonymity. We will also explore the potential dangers of cross-site attacks and the need for Web3 developers to be vigilant to ensure the safety and security of their platforms.

What is a cross-site search vulnerability?

Search across sites (XS-Search) is a vulnerability in web applications that use query-based search systems. It allows an attacker to extract sensitive information from another origin by sending queries and observing differences in the behavior of the search system when it does or does not return results. The attacker incrementally collects information by sending multiple queries, using the distinct differences in the system’s behavior to extract more and more information. The XS-Leaks attack family was built on the principles of XS-Search, using a similar underlying method to generically extract sensitive information from a web application.

The iFrame resizer library and the potential for cross-site searching

The iFrame-resizer library is used to resize iFrames to fit their content automatically. This is useful when an iFrame is embedded on a page and the content of the iFrame is dynamic and can change size. Without the iFrame-resizer library, the iFrame would not resize to fit the content, potentially leading to a poor user experience.

However, when the iFrame-resizer library is used where cross-origin communication is not restricted, it can lead to a cross-site search security issue. This is because the library broadcasts the width and height of the iFrame, which can be used as an oracle to detect when a search returns results. An attacker could exploit this vulnerability by continuously searching the victim’s assets, performed cross-origin, to leak an NFT name and associated wallet address. This can lead to de-anonymisation of the user if the attacker can link the leaked information to the user’s identity.

In addition to the risk of cross-site search vulnerabilities, the iFrame-resizer library can also be exploited to leak sensitive information in other ways. For example, an attacker could use the library to leak parts of the URL to a cross-origin window, potentially exposing sensitive information such as authentication tokens or other sensitive data. As such, it is important to carefully consider the potential risks of using the iFrame-resizer library without origin restrictions and take steps to mitigate those risks.

Vulnerability overview

OpenSea did not restrict cross-origin communication, which allowed attackers to exploit this vulnerability through cross-site search attacks. The iFrame-resizer library broadcasts the width and height of the page, which can be used as an “oracle” to determine when a given search returns results because the page is smaller when a search returns zero results. By continuously searching the user’s assets, which is done cross-origin through a tab or popup, an attacker can leak the name of an NFT created by the user, thereby revealing their public wallet address. This information can link the user’s identity to the leaked NFT and the public wallet address.

The exploitation steps for this vulnerability are as follows:

• The attacker would send the victim a link through various communication channels such as email or SMS.
• When the victim clicks on the link, it reveals valuable information such as the target’s IP address, user agent, device details and software versions.
• The attacker’s service will then exploit the cross-site search security vulnerability and extract one of the target’s NFT names.
• Finally, the attacker will associate the leaked NFT/public wallet address with the target’s identity, which is the email or phone number to which the link was originally sent.

Leverage development

Once we confirmed that our basic exploitation techniques worked, we began to investigate the search function on OpenSea.

The company mentioned the use of ElasticSearch in their job postings, and indicated that this is likely the engine they use for the search function. We then focused on better understanding how search works on the platform to improve our utilization.

Understanding ElasticSearch

ElasticSearch is a powerful search engine that can be used to search and analyze large amounts of data quickly. One of the key features of ElasticSearch is its ability to normalize language through language-specific analyzers and voices. These algorithms are designed to break down the text into individual words and symbols and to remove inflectional endings such as “-s” or “-ed”. This normalization process helps improve result accuracy and relevance by allowing ElasticSearch to match words with similar meanings, regardless of inflection.

For example, a search for “run” will also match words like “run” and “run” because they share the same base form.

We also learned that the order of two leaked words could be confirmed by searching for them as one word. For example, if we leak the words “amazing” “cat” and “hacker” we can confirm the order by searching for “amazingcat”, which only returns if the order of the words is correct.

This understanding also allows us to anticipate common inflectional endings, such as “s”, when putting together leaky NFT names.

iFrame resizer postMessage Communication Protocol

Since the iFrame resizer is a relatively small and simple one open source projectwe were able to quickly understand the messages we had to send to leak the width and height of the page.

We explored multiple modes to calculate page size using iFrame-resizer and used the iFrame-resizer library to generate post message content for each mode until we found one suitable for our attack.

Speed ​​up the attack

The attack was functional but slow, taking tens of minutes to reveal one word. To speed up the attack, we added a basic word predictor that filtered possible next characters using an English dictionary. This led to a ~10x improvement.

Curing recommendations

One of the most effective measures to take is to use Cross-Origin-Opener-Policy (COOP) Heading. This header allows website owners to specify whether their pages can be accessed in cross-origin contexts, such as when an attacker tries to access their page on a malicious website.

By setting this header, site owners can prevent attackers from accessing cross-site leak “widgets”, such as a reference to the window object on your site, which are often used in cross-site leak attacks.

It’s important to note that adding the “Cross-Origin-Opener-Policy” header to your site is a defense-in-depth technique and not a complete solution to cross-site leaks.

OpenSea’s response

In response to this vulnerability, OpenSea quickly addressed the issue and implemented appropriate cross-origin communication restrictions. Within days of the vulnerability being reported, the team at OpenSea had resolved the issue and ensured that their platform was no longer vulnerable to such attacks.

Final thoughts

This vulnerability highlights the dangers of cross-origin communication, which could lead to XS leaks and other vulnerabilities. We appreciate OpenSea’s quick response in addressing the security issue and working with us to mitigate it.

Our team is dedicated to identifying and reporting vulnerabilities and working with software vendors to improve the safety and security of their platforms, just as we do for our customers.

The post Deanonymizing OpenSea NFT Owners via Cross-Site Search Vulnerability appeared first on the blog.

*** This is a Security Bloggers Network syndicated blog from the blog written by Ron Masas. Read the original post at: