We recently pledged to increase transparency and community education around security matters that could impact OpenSea and its users. If you haven’t read our first blog post in the series, we encourage you to check it out.

A vulnerability was brought to our attention that reinforces how important it is to stay informed and follow security best practices while navigating the NFT space–or anywhere online. Thanks to Check Point Research (CPR) and our own independent efforts, the vulnerability was patched and there are no known victims.

However, this presents an opportunity for our team and our community to learn, so let’s talk about what happened.  

What was the vulnerability and how did OpenSea find out about it?

CPR chose to look into OpenSea after users reported falling victim to attacks triggered by malicious NFTs. While these reported attacks ultimately did not leverage a vulnerability within OpenSea, the investigation led to the discovery of a security flaw in our platform that, if exploited, could have led to the users approving malicious transactions. It’s important to note had an attacker attempted to take advantage of this flaw, the end-user would have needed to approve the malicious transaction through a wallet signature.    

Here’s what a theoretical attack using the vulnerability would have looked like:

• A hacker creates and transfers a malicious gift NFT, which includes an SVG file, to a target victim. For context, an SVG (Scalable Vector Graphics) is a type of image on the web that can be interactive and run scripts.  
• The victim right-clicks the image from the malicious NFT and opens it in a new tab or window, which triggers a pop-up from a third-party wallet provider from the OpenSea storage domain (i.e. storage.opensea.io) requesting a connection to the victim’s third-party wallet. This is an abnormal event because third-party images on OpenSea do not result in a request for a wallet connection.
• The victim then can choose to click to connect their third-party wallet.  
• If the victim connects their wallet, the victim will then be presented with a final pop-up (depicted further below in this blog) asking the victim to sign a transaction that will transfer items or funds to the attacker. An informed user may recognize the threat and mitigate it by rejecting the transaction, instead of signing it.
• However, if the victim had not recognized the threat and performed the above actions, the end result is the potential theft of items in the user’s wallet.  

CPR disclosed its findings to OpenSea on Sunday, September 26, 2021, and we’re thankful for their swift and collaborative action. OpenSea fixed the vulnerability within an hour of receiving CPR’s findings. We additionally collaborated with Jay Niffley, an independent security researcher, who reported a related vulnerability to the storage.opensea.io domain.

In total, we analyzed over 73 million objects, 4.4 million SVG files, finding only 77 that were potentially related to the vulnerability and confirming they were not malicious. We shared these 77 SVG files that had characteristics of the vulnerability from our storage domain with CPR and all vulnerability vectors were confirmed closed by CPR.  

Did OpenSea fix it?

In less than an hour of disclosure, we fixed the issue and verified the fix was effective. CPR worked closely and collaboratively with us to ensure the fix worked correctly.

We also worked diligently to analyze relevant reports from OpenSea users who indicated they might have been exploited by a malicious NFT. However, we have yet to identify a single instance where a malicious file was leveraged.

What can users do to protect against these types of threats?

While signing wallet actions is required to take certain actions on OpenSea, you should always be careful when receiving requests to sign a transaction with your wallet online. Before you approve a request for your signature, you should carefully review what is being requested and consider whether or not the request is abnormal or suspicious. If you have any doubts, you should reject the request.

For example, in the signature screen below, you can examine who the transaction is between (“USER” and “ATTACKER” would instead have wallet addresses of the relevant parties), what action will be taken, and what the cost (if applicable) of the action will be. If you do not recognize the transaction, then it is important to reject the requested transaction.  

Additionally, you should check if the signature request correlates with an expected action. In this theoretical attack, the user is asked to connect their wallet and then sign the transaction after opening an image from a third party in a new tab. This is unexpected behavior on OpenSea since it is not correlated to services provided by OpenSea, such as buying an item, making an offer, or favoriting an item.

Users should note that OpenSea does not request wallet signatures for viewing or clicking third-party photos or links. Such activity is highly suspicious and users should not sign transactions that are unrelated to the specific actions on OpenSea listed above.

What happens now?

To help promote platform safety as we scale, OpenSea has been doubling down on community education around security best practices. This disclosure and post-mortem is the latest post in a series highlighting safety tips and developments in the NFT space.

Whether you are new to the blockchain world and absorbing this information for the first time, or an old salt using this as a refresher course, our goal with this content is to empower the community to detect, mitigate and report attacks in the blockchain ecosystem.