DERP Example 2: NFT Marketplace

Dr. Sebastian Bürgel
HOPR
Published in
4 min readJan 26, 2022

HOPR’s DERP tool makes it clear just how far we have to go before crypto can claim to be truly private and decentralized. You can read more about how the tool works in the overview article here. You can also walk through our first DERP example, explaining how your secret Metamask account might not be as secret as you thought…

Our second DERP example is less extreme than the Metamask linkability issue, but the simplicity of the exploit highlights a severe issue with how certain crypto services are provided: a malicious RPC provider can use the data payload from a request they handle to frontrun your transaction.

In this example, we’ll be using an NFT marketplace, but you could substitute many different crypto dApps and see the same issue.

This example also uses a slightly different DERP setup: instead of an RPC provider on Ethereum mainnet, we’re using one on Gnosis Chain.

If you’d like to replicate this, using the settings pictured below.

Network Name: DERP — Gnosis Chain

RPC URL: https://derp.hoprnet.org/rpc/xdai/mainnet

Chain ID: 100
Currency Symbol: xDAI

If you already have Gnosis Chain set up in your wallet, you will get an error when you enter the Chain ID. It’s safe to ignore this.

To test this exploit, we’re using one of HOPR’s own Boost NFTs. These are NFTs you can earn for testing and other activities. You can lock them in our staking program to increase your APR, but you can also trade them. Here’s one available on epor.io, an NFT marketplace on Gnosis Chain.

In the video above, you can see I’ve connected my wallet and clicked the button to begin the process of bidding 14 xDAI for a silver Surveyor boost NFT. However, I don’t complete the transaction.

Now what do we see in DERP?

This small interaction resulted in a LOT of requests. But scrolling down we see the one we’re interested in: eth_estimateGas. This call is used to estimate the necessary gas for the pending transaction: the results are what your wallet UI uses to display the suggested gas price.

Here’s the data from that request:

[

{

“gasPrice”: “0x77359400”,

“value”: “0xc249fdd32777ffff”,

“from”: “0x0c89edd253cfd1a95a9d56a11dcd7f0a1ea9eeb0”,

“to”: “0x8b90560963cf5625384e6e642c4979e6a1c38b04”,

“data”: “0x12c04b3e00000000000000000000000000000000000000000000000000000000000092af”

}

]

Using a hex converter, we can interpret the data as follows.

The “gasPrice” of 0x77359400 is the gas price recommended by Metamask.

The “value” of 0xc249fdd32777ffff is the amount of my bid: 14 xDAI.

The data payload isn’t super interesting. The initial eight characters don’t show up in 4bytes.directory, so they must represent a function call exclusive to the NFT marketplace. Then there’s a bunch of zeros and the string 92af. Using this string and a spot of reverse engineering, it’s possible to identify the precise NFT being bid on and the owner.

That’s not particularly private information, though. The owner’s could also be found by clicking the avatar on the epor.io bid page. What’s interesting is that this data payload is ALL you need to bid on this NFT.

If we wanted we could, for example, program DERP such that whenever it received a request like this one, it instead submitted an identical transaction with the same data payload, but from an account controlled by us. We could then immediately relist the same NFT at a higher price.

That might not seem like much of an exploit, but if I identify your account as an NFT collector (easily done by analyzing your token holdings, since as the RPC provider I already know your address), it’s a solid bet that I could squeeze you into making a slightly higher bid.

What’s interesting about this example is it’s not clear whose fault it is that this is possible, or what should be done about it. As a crypto user, I obviously want an estimate of the gas price I’ll have to pay for a transaction. The only way to calculate this is to use the details of the transaction I’m planning to make. But it isn’t always necessary to submit so much data that a front run attack is possible: in many cases it would be sufficient to just reveal the type of smart contract function being called, and leave the identifying details out.

Sebastian Bürgel,
HOPR Founder

--

--