Vulnérabilités d'échange décentralisé

Au cours du mois dernier, les pertes résultant d'attaques de pirates informatiques contre la communauté crypto ont atteint 1.019 milliard de dollars (24.10), dépassant les mois précédents (en omettant l'incident de Terra Luna)

En y regardant de plus près, on constate que les principaux exploits ont été menés sur les plateformes DEX (Decentralized Exchange), totalisant près de 15% des pertes totales en octobre seulement.

Dans cet esprit, approfondissons trois cas dans le monde de l'exploitation DEX et essayons de répondre à ces questions :

• Quelles sont les principales causes des vulnérabilités DEX ?
• Comment pouvons-nous les éviter à l'avenir ?

Échange de bananes

Le 28 août, l'échange de jetons $DDC, Échange de bananes, a été attaqué. L'attaquant a réussi à manipuler le prix de la pièce, en brisant la logique interne de calcul du prix, et a ainsi échangé 23 $DDC contre 110,105 XNUMX $BUSD.

La vulnérabilité était assez simple mais l'impact avait un énorme potentiel de profit :

1. L'attaque a commencé par une transaction de 26 $DDC sur le compte de l'attaquant
2. Ensuite, une recherche du portefeuille d'une victime a été lancée afin de trouver un portefeuille contenant une grande quantité de jetons.
3. [Exploitation] Lorsqu'un compte approprié a été trouvé, l'attaquant a appelé handleDeductFee qui a effectué une déduction de presque tous les jetons du solde de la victime
4. Afin de finaliser la manipulation de prix, la fonction sync a été appelé pour mettre à jour la valeur/le prix de $DDC

En conséquence, le solde de $DDC dans le pool a été réduit à 0.0003 $DDC, après la mise à jour de la valeur/du prix, le prix de $USD correspondant à $DDC est considérablement augmenté et une grande quantité de $USD peut être échangée. via une petite quantité de $DDC. Le pirate a utilisé 23 $ DDC pour échanger contre 104,600 XNUMX USD.

Alors, comment était-il possible pour un attaquant de manipuler le solde du compte de la victime ? Quel était le handleDeductFee fonction en cours d'exécution ?

Jetons un œil au code :

function handleDeductFee (ActionType actionType, uint256 feeAmount, address from, address user) external override {
	distributeFee(actionType, feeAmount, from, user);
}

// deduct the config fee and transfer to handle fee address which config.
// parameter from
function distributeFee (ActionType actionType, uint feeAmount, address from, address user) internal { 
	_balances [from] = _balances[from].sub(feeAmount);
	...
}

Ici nous avons une fonction externe à arguments contrôlables qui appelle une fonction interne passant les mêmes arguments en paramètres qui effectue une déduction en utilisant ces arguments tout de suite.

L'agresseur a transmis l'adresse de la victime comme from paramètre et le feeAmount était légèrement inférieur au résultat de balanceOf de cette adresse.

C'est ça! Pas une seule validation sur les données entrantes. Aucune théorie complexe derrière cela.

Cyber Sécurité 101 : Ne faites jamais confiance aux données contrôlées par l'utilisateur.

Plus d'informations peuvent être trouvées dans le post Twitter de Beosin Alert ici.

Ensuite, nous passerons en revue un protocole plus complexe. Mais comme nous l'avons déjà vu, manquer une ligne de code peut casser tout le système.

Échange de transit

Échange de transit est une plate-forme d'agrégation DEX multi-chaînes fonctionnant sur les chaînes Ethereum et Binance. Le 1er octobre, la plateforme a été victime d'une attaque qui a drainé près de 29 millions de dollars d'actifs des portefeuilles des utilisateurs du protocole.

L'échange avec Transit Swap implique de passer par quelques contrats qui acheminent et relient différents échangeurs et appliquent la gestion des autorisations. Chacun des contrats appelle l'autre en passant ses paramètres comme arguments au suivant, chacun d'eux utilise les paramètres pour traiter une logique et exécuter des actions.

Une version simplifiée du flux de données ressemble à ceci :

Comme je l'ai mentionné plus tôt, chacun des contrats appelle le suivant en passant les arguments en tant que paramètres, alors pourquoi est-ce si critique ?

"La principale raison de cette attaque est que le protocole Transit Swap ne valide pas strictement les données transmises par l'utilisateur lors de l'échange de jetons, ce qui se traduit par un appel externe arbitraire." – L'analyse de SlowMist

Aucun des contrats n'a correctement validé les données utilisées pour effectuer la transaction. En conséquence, l'attaquant a réussi à manipuler toute la chaîne en passant des données spécialement conçues pour chaque étape de la transaction.

C'est encore un autre cas de validation de données avec une vulnérabilité à plus grande échelle. Passons à l'une des plus grosses pertes de cette année :

Échange Maiar – Réseau Elrond

La troisième attaque DEX la plus rentable de tous les temps a été menée sur le Maire DEX. Les pirates ont exploité une fonction vulnérable nouvellement déployée sur le réseau principal. Ils ont réussi à vider les réserves du protocole, en volant 113 millions de dollars d'actifs.

L'exploit a commencé avec une fonction executeOnDestByCaller qui a permis au contrat A d'effectuer des actions sur le contrat C via le proxy B. Le contrat A appellera une fonction à l'intérieur de B qui permet à B d'effectuer des actions sur C au nom du contrat A.

Pour illustrer cela, nous allons illustrer les contrats A, B et C. Appels du contrat A foo qui est à l'intérieur de B. foo en cours executeOnDestByCaller qui permet à B d'exécuter la fonction bar du contrat C en tant qu'imposteur de A.

En pratique, le contrat B peut exécuter chaque fonction au nom de A si A a fait le premier appel à B. Cette idée semble déjà un peu louche.

Pour créer un exploit en utilisant cette fonction, il faut comprendre comment faire en sorte que la victime appelle le contrat, puis on peut faire ce qu'elle veut avec ce contrat en utilisant les fonctions externes qu'il fournit comme transferFrom.

Heureusement pour les hackers, Elrond a un concept appelé Rappels. En utilisant ces rappels, on peut transmettre une fonction malveillante en tant que rappel à la victime, qui n'aura d'autre choix que d'exécuter le rappel et le reste appartient à l'histoire.

Si vous souhaitez plonger plus profondément, veuillez vous référer à Rapport officiel d'Elrond et Répartition de l'attaque par Arda.

Il n'y avait donc pas de vulnérabilité dans le code mais plutôt une faille logique. Le public a trouvé plusieurs problèmes de sécurité avec cette fonctionnalité après le déploiement, mais le correctif et le correctif n'ont pu être livrés qu'une semaine plus tard, exposant ainsi tous les contrats à une vulnérabilité potentielle pendant une semaine entière.

Répondre aux questions

Sachant ce que nous savons maintenant, nous pouvons répondre à ces questions.

Les incidents discutés partagent une cause commune : la vulnérabilité des contrats intelligents. Nous connaissons tous les termes vulnérabilités et exploits dans d'autres scénarios, alors qu'est-ce qui le rend différent dans le scénario du contrat intelligent ?

1. Open source – Comme nous le savons tous, le « D » dans DEX signifie décentralisé, ce qui signifie que le produit est piloté par les utilisateurs, ce qui rend le code accessible au monde entier. Cela rend les vulnérabilités plus faciles à trouver.
2. Difficile à mettre à jour – Le coût de recherche et de mise à jour d'une vulnérabilité est beaucoup plus élevé que dans une application hors chaîne. Au fur et à mesure que les contrats sont téléchargés sur la chaîne, corriger une vulnérabilité signifie télécharger une nouvelle copie du contrat et rediriger toutes les adresses de l'ancienne vers la nouvelle si aucun contrat de proxy n'est utilisé.

Par conséquent, nous n'avons pas de seconde chance. Nous devons nous assurer que le contrat est sans bogue et sécurisé avant de le télécharger sur la chaîne.

Les audits de sécurité avant le téléchargement et la surveillance constante des menaces de sécurité sont des mesures cruciales dans le monde des applications décentralisées.

Conclusion

Ces exemples ne couvrent qu'une partie des vulnérabilités et des problèmes rencontrés dans les contrats intelligents. Au fur et à mesure que le développement du Web 3 progresse, des algorithmes plus complexes seront introduits dans le monde, des algorithmes qui pourraient jouer un rôle important dans le prochain exploit et entraîner des pertes de fonds.

L'analyse des exploits passés et l'atténuation, l'audit et la vérification du code peuvent éviter les pertes de fonds et faire une énorme différence pour l'avenir des applications décentralisées.