Off-Chain NFT Hijacking

How it works

Purchase attack (A9)

The problem

Most decentralized applications, NFT platforms included, rely on centralized components.

NFT assets are almost always stored off-chain, and most marketplaces, including all of the top 10 on DappRadar, run on a marketplace server. Centralized components of decentralized applications have been attacked before, for example through DNS hijacks of DeFi front ends and a BGP hijack of KlaySwap.

Threat model

An off-path network attacker intercepts and modifies traffic between users and centralized services.

Interception uses BGP or DNS hijacking (RPKI, BGPsec and DNSSEC are not widely deployed) and a fraudulent TLS certificate for the service's domain. The blockchain, smart contracts, decentralized storage and the centralized services are not compromised.

Architectures

Centralization and attacks by type

Type I

Fully decentralized

Registry and marketplace are smart contracts. Users access them and IPFS through their own nodes and can verify all data.

No exploitable interaction

Type II

Centralized asset storage

Assets are hosted on web servers or fetched through IPFS gateways or blockchain-as-a-service providers.

A1–A2

Type III

Centralized marketplace

A marketplace server hosts the storefront and orderbook, provides the parameters users sign and caches tokenURIs and, optionally, assets.

A3–A11

Type IV

Centralized registry access

Users read the on-chain ownership registry through a blockchain-as-a-service provider.

A12

Results

Twelve attacks on interactions with centralized services

Most attacks were validated against OpenSea, the largest NFT marketplace, on the Ethereum Rinkeby testnet.

Attacks that hijack NFTs or cryptocurrency, in architecture Types II to IV.

6 of 10

Top marketplaces on DappRadar load storefront JavaScript from prefixes vulnerable to subprefix hijacking, and one of them also hosts its marketplace server on such a prefix.

5 + 1

IPFS gateways and Infura (blockchain-as-a-service) on prefixes vulnerable to subprefix hijacking.

Attack matrix

Attacks by architecture and detectability

Level 1 detected by auditing the transaction before signing Level 2 detection requires a securely obtained digest or signature Level 3 detected only after the financial loss 2/3 level 2 with IPFS, a blockchain or an on-chain orderbook, otherwise 3

Type IFully decentralized

No exploitable interaction, since users verify all data end to end.

Type IICentralized asset storage

Type IIICentralized marketplace

Type IVCentralized registry access

A9 · PurchaseType III · Level 1The token ID or the destination address of the buy transaction is replaced, so the buyer gets the attacker's NFT or pays the attacker's contract (animation above).

Select an attack for details.

Countermeasures

Detection and prevention

Transaction auditing. Checking the transaction parameters before signing detects level-1 attacks, but most wallets display transaction data as raw hex.
Data authentication. A CID or signature obtained through decentralized infrastructure, or blockchain access through the user's own nodes, detects level-2 attacks.
On-chain orderbooks and bids. An on-chain copy lets buyers verify prices and current bids.
Third-party JavaScript. Marketplaces should audit the scripts their storefronts load.
Secure routing and naming. Authenticated inter-domain routing and naming would prevent the interception. The paper names SCION and RHINE as candidates.

Method

Validation and measurement

The network attacker was emulated with mitmproxy and a self-signed CA certificate trusted by Firefox, with MetaMask as the wallet. Validated attack categories: royalty payout change (A3), modified order or transaction parameters (A4, A5, A9, A10, A11) and wrong data fetched (A6, A7, A8). Only test contracts and NFTs were used, and the findings were reported through OpenSea's bug bounty programme.

Exposure to subprefix hijacking was measured with RIPEstat routing and ROA data. A prefix counts as vulnerable if it is shorter than /24 and has no valid ROA or a ROA whose max-length exceeds the prefix length.

Cite

@InProceedings{nft-security-2023,
  author    = {Felix St\"{o}ger and Anxin Zhou and Huayi Duan and Adrian Perrig},
  title     = {Demystifying Web3 Centralization: The Case of Off-Chain {NFT} Hijacking},
  booktitle = {Proceedings of International Conference on Financial Cryptography and Data Security (FC)},
  year      = {2023},
  month     = may,
  url       = {https://netsec.ethz.ch/publications/papers/2023-FC-NFT.pdf}
}

More research

Ongoing