Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 

Abonnez-vous gratuitement à notre NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Se désabonner

Imperva : La désanonymisassions des propriétaires de NFT OpenSea via une vulnérabilité de recherche intersite

mars 2023 par Imperva

Récemment, une vulnérabilité de recherche intersites a été découverte sur la populaire place de marché de NFT OpenSea. Lorsqu’elle est exploitée avec succès, cette vulnérabilité permet de désanonymiser les utilisateurs d’OpenSea en liant une adresse IP, une session de navigation ou un courriel dans certaines conditions à un jeton non fongible (NFT) spécifique et, par conséquent, à une adresse de portefeuille, révélant ainsi potentiellement l’identité d’un utilisateur.

La cause première de cette vulnérabilité est la mauvaise configuration de la bibliothèque iFrame-resizer utilisée par OpenSea. Cette mauvaise configuration a permis à la vulnérabilité de recherche intersites d’exister, conduisant à l’exposition potentielle des identités des utilisateurs.

Après la divulgation de la vulnérabilité, OpenSea a rapidement publié un correctif pour résoudre le problème. Le correctif limite la communication inter-origine, réduisant ainsi le risque d’une exploitation plus poussée. Le correctif a été validé par l’équipe rouge d’Imperva, qui a confirmé que la vulnérabilité avait été correctement corrigée.

Introduction

Le monde du Web3 et des applications décentralisées (dApps) se développe rapidement, apportant avec lui une foule de nouvelles possibilités et de nouveaux défis. La popularité croissante des Apps s’accompagne d’un risque accru de failles de sécurité et de vulnérabilités.

Ces dernières années, plusieurs piratages et vulnérabilités très médiatisés ont affecté des plateformes Web3 populaires, soulignant la nécessité pour les développeurs de donner la priorité à la sécurité et à la protection de la vie privée. Du tristement célèbre piratage de la DAO sur la blockchain Ethereum aux piratages plus récents ciblant les ponts inter-chaînes, il est clair que la sécurité des applications Web3 doit être une priorité absolue.

Dans cet article de blog, nous allons plonger dans les détails de la vulnérabilité OpenSea et discuter de l’importance des restrictions de communication cross-originales appropriées pour protéger l’anonymat des utilisateurs. Nous explorerons également les dangers potentiels des attaques de recherche intersites et la nécessité pour les développeurs Web3 de rester vigilants afin d’assurer la sécurité de leurs plateformes.

Qu’est-ce qu’une vulnérabilité de recherche intersites ?

La recherche intersites (XS-Search) est une vulnérabilité dans les applications web qui utilisent des systèmes de recherche basés sur des requêtes. Elle permet à un attaquant d’extraire des informations sensibles d’une origine différente en envoyant des requêtes et en observant les différences de comportement du système de recherche lorsqu’il renvoie ou non des résultats. L’attaquant recueille progressivement des informations en envoyant plusieurs requêtes et en utilisant les différences de comportement du système pour extraire de plus en plus d’informations. La famille d’attaques XS-Leaks s’est construite sur les principes de XS-Search, en utilisant une méthode sous-jacente similaire pour extraire de manière générique des informations sensibles d’une application web.

La bibliothèque iFrame-resizer et le potentiel de recherche intersites
La bibliothèque iFrame-resizer est utilisée pour redimensionner automatiquement les iFrames en fonction de leur contenu. Cette fonction est utile lorsqu’une iFrame est intégrée à une page et que le contenu de l’iFrame est dynamique et peut changer de taille. Sans la bibliothèque iFrame-resizer, l’iFrame ne se redimensionnerait pas pour s’adapter à son contenu, ce qui pourrait nuire à l’expérience de l’utilisateur.

Cependant, lorsque la bibliothèque iFrame-resizer est utilisée dans un contexte où la communication inter-origine n’est pas restreinte, elle peut entraîner une vulnérabilité de recherche inter-site. En effet, la bibliothèque diffuse la largeur et la hauteur de l’iFrame, ce qui peut être utilisé comme un oracle pour détecter les résultats d’une requête de recherche. Un attaquant peut exploiter cette vulnérabilité en recherchant continuellement les actifs de la victime, en effectuant une recherche croisée, afin de divulguer le nom d’un NFT et l’adresse du portefeuille qui lui est associée.

Cela peut conduire à la désanonymisassions de l’utilisateur si l’attaquant peut associer les informations divulguées à l’identité de l’utilisateur. Outre le risque de vulnérabilités liées aux recherches intersites, la bibliothèque iFrame-resizer peut également être exploitée pour divulguer des informations sensibles d’autres manières.

Par exemple, un attaquant pourrait utiliser la bibliothèque pour faire fuir des parties de l’URL d’une fenêtre d’origine croisée, exposant potentiellement des informations sensibles telles que des jetons d’authentification ou d’autres données sensibles. Il est donc important d’examiner attentivement les risques liés à l’utilisation de la bibliothèque iFrame-resizer sans restriction d’origine et de prendre des mesures pour les atténuer.

Aperçu de la vulnérabilité

OpenSea n’a pas restreint la communication inter-origine, ce qui permet aux attaquants d’exploiter cette vulnérabilité par le biais d’attaques de recherche inter-sites. La bibliothèque iFrame-resizer diffuse la largeur et la hauteur de la page, ce qui peut être utilisé comme un "oracle" pour déterminer quand une recherche donnée donne des résultats, car la page est plus petite quand une recherche ne donne aucun résultat. En recherchant continuellement les actifs de l’utilisateur, ce qui est fait de manière croisée par le biais d’un onglet ou d’une fenêtre contextuelle, un pirate peut divulguer le nom d’un NFT créé par l’utilisateur, révélant ainsi l’adresse publique de son portefeuille. Cette information permet d’associer l’identité de l’utilisateur au NFT et à l’adresse du portefeuille public qui ont fait l’objet de la fuite.

Les étapes d’exploitation de cette vulnérabilité sont les suivantes :

● L’attaquant enverrait à la victime un lien par le biais de divers canaux de communication tels que le courrier électronique ou les SMS.
● Lorsque la victime clique sur le lien, celui-ci révèle des informations précieuses, telles que l’adresse IP de la victime, l’agent utilisateur, les détails de l’appareil et les versions des logiciels.
● Le service de l’attaquant exploiterait alors la vulnérabilité de recherche intersite et extrairait l’un des noms NFT de la victime.
● Enfin, l’attaquant associerait l’adresse du NFT/portefeuille public ayant fait l’objet d’une fuite à l’identité de la victime, à savoir l’email ou le numéro de téléphone auquel le lien a été initialement envoyé.

Développement de l’exploit
Une fois que nous avons confirmé que nos techniques d’exploitation de base fonctionnaient, nous avons commencé à étudier la fonction de recherche sur OpenSea.
L’entreprise a mentionné l’utilisation d’ElasticSearch dans ses offres d’emploi, ce qui indique qu’il s’agit probablement du moteur qu’elle utilise pour sa fonction de recherche. Nous nous sommes alors attachés à mieux comprendre le fonctionnement de la recherche sur la plateforme afin d’améliorer notre exploit.

Comprendre ElasticSearch
ElasticSearch est un moteur de recherche puissant qui peut être utilisé pour rechercher et analyser rapidement de grands volumes de données. L’une des principales caractéristiques d’ElasticSearch est sa capacité à normaliser le langage à l’aide d’analyseurs et de stemmers spécifiques à la langue. Ces algorithmes sont conçus pour décomposer le texte en mots et en jetons individuels et pour supprimer les terminaisons flexionnelles telles que "-s" ou "-ed". Ce processus de normalisation contribue à améliorer la précision et la pertinence des résultats en permettant à ElasticSearch de faire correspondre des mots ayant une signification similaire, quelle que soit leur désinence.

Par exemple, une recherche pour "run" correspondrait également à des mots comme "ran" et "running" car ils partagent la même forme de base.
Nous avons également appris que l’ordre de deux mots fuyants pouvait être confirmé en les recherchant comme un seul mot. Par exemple, si les mots "amazing", "cat" et "hacker" sont divulgués, nous pouvons confirmer l’ordre en recherchant "amazingcat", qui n’apparaît que si l’ordre des mots est correct.

Cette compréhension nous permet également d’anticiper les terminaisons flexionnelles courantes, telles que "s", lorsque nous reconstituons les noms de NFT ayant fait l’objet d’une fuite.

Protocole de communication postMessage de l’iFrame-resizer
Comme iFrame-resizer est un projet open-source relativement petit et simple, nous avons pu comprendre rapidement les messages que nous devions envoyer pour connaître la largeur et la hauteur de la page.

Nous avons exploré plusieurs modes de calcul de la taille de la page à l’aide de iFrame-resizer et utilisé la bibliothèque iFrame-resizer pour générer le contenu des messages postaux pour chaque mode jusqu’à ce que nous ayons identifié celui qui convenait à notre attaque.

Accélérer l’attaque
L’attaque était fonctionnelle mais lente, prenant des dizaines de minutes pour révéler un mot. Pour accélérer l’attaque, nous avons ajouté un prédicteur de mots de base qui filtre les caractères suivants possibles à l’aide d’un dictionnaire anglais. Cela a permis une amélioration d’environ 10 fois.

Recommandations en matière de renforcement
L’une des mesures les plus efficaces consiste à utiliser l’en-tête COOP (Cross-Origin-Opener-Policy). Cet en-tête permet aux propriétaires de sites web de spécifier si leurs pages sont accessibles dans des contextes d’origine croisée, comme lorsqu’un attaquant tente d’ouvrir leur page à partir d’un site web malveillant.

En définissant cet en-tête, les propriétaires de sites web peuvent empêcher les attaquants d’accéder aux "widgets" des fuites intersites, tels qu’une référence à l’objet fenêtre de votre site web, qui est souvent utilisé dans les attaques de fuites intersites.
Il est important de noter que l’ajout de l’en-tête "Cross-Origin-Opener-Policy" à votre site web est une technique de défense en profondeur et non une solution complète aux fuites intersites.

Réponse d’OpenSea
En réponse à cette vulnérabilité, OpenSea a rapidement abordé le problème et a mis en place des restrictions appropriées pour les communications inter-origines. Quelques jours après le signalement de la vulnérabilité, l’équipe d’OpenSea a corrigé le problème et s’est assurée que sa plateforme n’était plus exposée à de telles attaques.

Réflexions finales
Cette vulnérabilité met en évidence les dangers de la communication inter-origine, qui peut conduire à XS-Leaks et à d’autres vulnérabilités. Nous apprécions la réponse rapide d’OpenSea en abordant le problème de sécurité et en travaillant avec nous pour l’atténuer.
Notre équipe se consacre à l’identification et au signalement des vulnérabilités et collabore avec les fournisseurs de logiciels pour améliorer la sécurité de leurs plateformes, tout comme nous le faisons pour nos clients.


Voir les articles précédents

    

Voir les articles suivants