Tracking Ipfs Users Via Cache Probing

Introduction

IPFS is a distributed file system network that uses hashes to lookup, verify, and track content.

The IPFS reference client has an HTTP gateway on localhost for accessing files (such as HTML) via the network.

These files are stored in the IPFS cache for an indefinite period of time to make the available offline and to others who would request them.

This gateway also has a very liberal CORS header, making content readable to other browser origins.

Sadly, this file permanence system comes at a cost. Websites on or off IPFS can test if any given file is in a node without giving any initial indication that they are doing so.

Probing the cache

Similar to my attacks on I2P, IPFS also has to deal with web vulnerabilities, because of its webui and gateway system.

By requesting a hash from the user's local gateway and tracking the time it takes to load, I can see if they have that file in their cache or not.

Caveats

This form of testing is far from perfect, there are factors that could result in incorrect results:

• Slow machine/disk

• Large files may be more difficult to detect

• If multiple sites did this, they could hurt each other by requesting (and therefore polluting) the same data.

Supercookies 🍪

IPFS can also be used as a type of supercookie with 99-100% accuracy.

An attacker would pre-compute tracking files on their node and assign them to IPFS users by making their clients request & cache them.

These files could then use application cache or service workers to make the cookie available if the IPFS node goes down.

In reality, since IPFS is not that popular to begin with & browsers are already easy to fingerprint, IPFS being installed (combined with other browser data) would be enough to uniquely identify a user.

Mitigation

The cache & supercookie 'attack' could be mitigated by requiring some sort of authentication to interact with the gateway.

Unless a system like that is added, user's will have to do 'ipfs repo gc' and/or shutdown their node to protect themselves.

Noscript's "application boundaries enforcer" should provide some protection as well.

Other Attacks

There are a couple other IPFS attacks I haven't seen discussed much, but I don't really feel need their own posts.

Webui Clickjacking

The IPFS webui does not return 'x-frame-options', meaning the user's IPFS node ID (& system username) can be exfiltrated using frame splicing, and their config maliciously changed via pastejacking.

Stealing cookies

Since all IPFS files are served on the same origin (the gateway address), files have access to each others cookies, local/session storage, and other data. Do not store any sensitive data in IPFS sites.