Les NFT sont aussi sûrs que leur créateur les a créés. Comme pour toute technologie émergente, prendre des raccourcis dans les étapes de conception peut avoir des conséquences désastreuses sur toute la ligne.
Kraken Security Labs a scanné des milliers de contrats intelligents sur la blockchain Ethereum pour tirer parti des vulnérabilités laissées ouvertes dans certains jeton non fongible (NFT) contrats.
Ci-dessous, l’équipe détaille comment nous avons pu prendre en charge deux NFT vulnérables avec peu d’effort et montre également comment vous protéger contre ce type de NFT non sécurisé.
Comment les médias et les métadonnées d’un NFT sont stockés
Contrairement aux croyances populaires, tous les médias NFT (ou métadonnées) ne sont pas stockés sur une blockchain. Dans de nombreux cas – comme dans les contrats ERC-721 que nous sommes sur le point de voir – la blockchain stocke simplement un aiguille à l’endroit où les médias sont conservés, comme un coffre de banque qui contient un morceau de papier avec le adresse de l’endroit où une œuvre d’art est stockée.
Indépendamment de la sécurité de votre banque, ce morceau de papier ne sera pas d’une grande utilité si quelqu’un se rend à l’adresse et remplace l’art.
La blockchain stocke simplement un lien vers les médias.
C’est là qu’un acteur malveillant s’intéresse. Quel site Web ou hébergeur détient les médias ? Qui les paie pour le stocker ? Combien de temps ce lien va-t-il être vivant ? Et le pointeur sur la chaîne peut-il être mis à jour ?
Kraken Security Labs a analysé des milliers de NFT à la recherche de liens expirés (sites Web expirés ou URL personnalisées de services d’hébergement). Étonnamment, cette analyse a révélé un grand nombre de jetons vulnérables.
Reprendre un NFT hébergé sur GitHub
L’équipe a d’abord identifié un jeton nommé UniOption, dont le contrat a été créé en décembre 2020. Le contrat TokenURI a révélé que les métadonnées du jeton étaient hébergées sur stacksideflow.github.io:
L’URL des métadonnées du jeton.
Mais lors de la visite de la page, une erreur 404 est apparue, indiquant que la page n’existe pas.
Typiquement, le github.io le domaine héberge le contenu de l’utilisateur avec une URL au format nom d’utilisateur.github.io. Mais nous n’avons pas trouvé d’utilisateur nommé stacksideflow – suggérant que le compte avait depuis été renommé ou supprimé.
De là, nous avons enregistré un nouveau compte avec le nom d’utilisateur et créé un référentiel. Avec un peu plus de configuration, nous avons réussi à diffuser du contenu personnalisé via l’URL stacksideflow.github.io :
En imitant le chemin indiqué dans le contrat NFT, nous avons ajouté un simple fichier JSON à notre nouveau référentiel qui fournirait notre métadonnées au jeton :
Le nom, la description et l’image ont été modifiés.
Et juste comme ça, le NFT a été détourné ! Le nouveau nom, la description et l’image peuvent être vus sur les sites d’exploration NFT tels que OpenSea et Rarible.
Reprendre un NFT expiré
Ensuite, nous avons regardé ksfootball — une collection d’art numérique sur le thème du football.
La prochaine victime de l’équipe.
Après examen rapide, nous avons constaté que le contenu était diffusé par un domaine appelé ksfootball.app:
Encore une fois, nous avons interrogé la méthode tokenURI pour trouver ces informations.
Une recherche a révélé que le domaine était expiré et pouvait être acheté pour quelques dollars. À partir de là, nous avons acheté le domaine et, comme dans l’exemple précédent, mis en place un chemin pour fournir des métadonnées personnalisées aux NFT.
Encore une fois, si nous recherchons la collection sur Rarible ou OpenSea, nous pouvons voir les modifications apportées à l’image, au titre et à la description.
Le NFT maintenant détourné sur Rarible.
Comment puis-je me protéger contre le piratage ?
Nous avons ciblé les jetons inactifs pour les besoins de cette recherche, mais les mêmes techniques pourraient être appliquées aux jetons que vous pourriez posséder.
Souvenez-vous toujours de cela, alors que les données de la blockchain peuvent être immuables, là où elles pointent ne sont pas toujours aussi sécurisées. Lorsqu’un contrat intelligent code en dur une URL sujette à modification, le créateur la laisse ouverte au piratage.
De plus, certains contrats peuvent inclure des fonctions qui permettent au propriétaire du contrat ou au détenteur du jeton de mettre à jour l’URL, auquel cas elle n’est pas statique et peut changer à l’avenir. Actuellement, il n’existe pas de moyen simple de détecter cette vulnérabilité « d’URL pouvant être mise à jour », bien que l’examen du code de contrat intelligent (le cas échéant) sur des pages telles qu’Etherscan puisse s’en protéger.
Pour les NFT ERC-721, Kraken Security Labs vous conseille de toujours vérifiez où votre jeton est stocké. Vous pouvez le faire en appelant le contrat tokenURI méthode, par exemple en utilisant Etherscan.io. En utilisant le Lire le contrat fonctionnalité, vous pouvez obtenir l’URI des métadonnées de votre jeton.
De plus, les projets qui stockent leurs données à 100 % en chaîne (comme OnchainMonkey ou CryptoPunks) ne sont pas sujets à ces vulnérabilités car ils ne pointent pas vers un stockage externe.
Au-delà de la vérification du tokenURI, vous devez vous assurer que l’URL de l’image dans les métadonnées pointe également vers un emplacement de confiance.
Idéalement, si votre NFT stocke ses données hors chaîne, il doit être hébergé sur un système tel que Arweave ou IPFS (le système de fichiers interplanétaire) — à ne pas confondre avec IPNS (le Système de noms interplanétaire), car ces liens ne sont pas garantis immuables. Par exemple, un lien IPFS normal (commençant par ipfs://ipfs/… ) ne peut pas être altéré, n’a pas de point de défaillance unique et un stockage adressable par le contenu. Cependant, avec IPFS, il faut continuellement épingler le fichier sur un nœud IPFS, il n’est donc pas à l’abri de l’expiration, contrairement à des systèmes tels que Arweave.
