
Une faille dans la phase de validation des données entraîne une perte de 3,3 millions de dollars : analyse détaillée de l'incident d'attaque sur Socket
TechFlow SélectionTechFlow Sélection

Une faille dans la phase de validation des données entraîne une perte de 3,3 millions de dollars : analyse détaillée de l'incident d'attaque sur Socket
Le 16 janvier 2024, Socket Tech a été victime d'une attaque entraînant une perte d'environ 3,3 millions de dollars. Cet article détaille l'ensemble des événements liés à cette attaque.
Rédaction : CertiK

Le 16 janvier 2024, Socket Tech a été attaqué, subissant une perte d’environ 3,3 millions de dollars. L’attaquant a exploité une faille dans la phase de validation des données d’un contrat Socket, volant les fonds des utilisateurs ayant autorisé ce contrat via une saisie malveillante de données. Cet incident a affecté au total 230 adresses, avec une perte maximale individuelle atteignant environ 656 000 dollars.
Introduction contextuelle
Socket est un protocole d'interopérabilité assurant la sécurité et l'efficacité du transfert de données et d'actifs entre chaînes. Le contrat Socket Gateway constitue le point d'entrée de toutes les interactions avec la couche de liquidité de Socket. Tous les ponts d'actifs et DEX convergent ici en un méta-pont unique, sélectionnant automatiquement le meilleur itinéraire transactionnel selon les préférences utilisateur (coût, latence ou sécurité).
Trois jours avant l'attaque, l'administrateur des contrats Socket a exécuté la commande addRoute, ajoutant une nouvelle route au système. Bien que cette action visait à étendre les fonctionnalités de Socket Gateway, elle a involontairement introduit une vulnérabilité critique.
L'image ci-dessous montre l'enregistrement de l'ajout de cette route par l'administrateur du contrat :

Résumé de l'incident
1. À 15h03 (heure de Pékin) le 16 janvier, le portefeuille de l'attaquant a reçu les fonds nécessaires à l'attaque. Notre analyse temporelle indique que ces fonds proviennent de l'adresse 0xe620, liée à un retrait de 10 BNB depuis Tornado Cash.

2. Ces fonds ont servi à déployer et exécuter deux contrats exploitant la vulnérabilité de Socket. Le premier ciblait les jetons USDC présents dans des adresses ayant autorisé SocketGateway (voir capture ci-dessous). 127 victimes ont ainsi perdu environ 2,5 millions de dollars.

3. Ensuite, un second contrat a visé les WETH, USDT, WBTC, DAI et MATIC présents sur les adresses des victimes. 104 autres victimes ont alors perdu environ :
-
42,48 WETH
-
347 005,65 USDT
-
2,89 WBTC
-
13 821,01 DAI
-
165 356,99 MATIC
4. L’attaquant a converti les USDC et USDT en ETH.

Origine de la vulnérabilité
La faille exploitée se trouvait dans la fonction performAction de l'adresse de routage nouvellement ajoutée, appelée routeAddress.
Initialement, la fonction performAction de cette adresse devait simplement aider aux opérations d'emballage (wrapping) et de déballage (unwrapping).
Cependant, une vulnérabilité critique était présente : l'utilisateur pouvait directement injecter des données externes via swapExtraData dans un appel .call(), sans aucune validation. Cela permettait à un attaquant d'exécuter n'importe quelle fonction malveillante.

Dans cet incident, l’attaquant a conçu une entrée malveillante swapExtraData pour déclencher la fonction transferFrom. Ce faux appel a profité des autorisations accordées par les utilisateurs au contrat SocketGateway pour leur dérober leurs fonds.
Bien que le contrat vérifie ensuite si le solde utilisateur a changé correctement après l'appel fromToken.call(), il ne prend pas en compte le cas où l'attaquant fixe le montant à zéro.

Reconstitution de l'attaque
1. Utilisant un contrat malveillant, l’attaquant a invoqué la fonction 0x00000196() sur le contrat Socket Gateway.

2. La fonction fallback(), utilisant la signature hexadécimale 196, appelle alors le contrat de routage vulnérable (routerAddress).

3. Dans la capture ci-dessous, on observe les fausses données d'entrée utilisées par l’attaquant, où toutes les quantités d’échange sont définies à 0.

4. Un appel à WrappedTokenSwapperImpl.performAction() est ensuite lancé pour effectuer l'échange.

5. Sans aucune vérification, les données SwapExtraData falsifiées sont acceptées puis exécutées par fromToken (WETH).

6. L’attaquant répète ce processus jusqu’à épuisement des actifs des victimes. Après l’apparition des transactions malveillantes, Socket a rapidement désactivé la route vulnérable via disableRoute, empêchant une propagation plus large de l’attaque.
7. Le 23 janvier, Socket a annoncé avoir récupéré 1032 ETH, puis le 25 janvier, a confirmé un remboursement intégral de toutes les pertes. L’incident a ainsi été résolu.

Synthèse de l'incident
Les attaques par calldata malveillant dans des contrats de routage disposant d’autorisations illimitées auprès des utilisateurs ne sont pas rares.
Des attaques similaires ont déjà touché Dexible et Hector Bridge.
Le 17 février 2023, le DEX décentralisé Dexible a été attaqué, perdant plus de 1,5 million de dollars. L’exploitant a saisi un calldata malveillant dans la fonction fill() afin de voler les actifs des utilisateurs.
Le 2 juin 2023, les protocoles du réseau Hector ont été compromis. L’attaquant a déployé un faux contrat USDC et utilisé un calldata malveillant pour transférer 652 000 vrais USDC depuis les contrats des victimes.
Les plateformes agrégatrices blockchain améliorent souvent la liquidité et réduisent les pertes en encapsulant plusieurs ponts et contrats de routage. Toutefois, cette complexité accrue pose de nouveaux défis en matière de sécurité.
La résolution de cet incident impliquant Socket témoigne des efforts conjoints de toutes les parties prenantes. CertiK continuera de s'engager pleinement dans l'audit complet et la détection proactive des risques afin de renforcer la confiance communautaire et la sécurité globale du secteur.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News










