BTC a également la Forêt Noire : exposer les bots malveillants sur la chaîne

Auteur : Tal Be'ery

Source:

Traduction : Blockchain vernaculaire

Les chercheurs de Zengo ont révélé que des bots malveillants surveillaient l’existence d’adresses aléatoires dangereuses sur BTC blockchains et les exploitaient immédiatement pour commettre des vols, causant des millions de dollars de pertes, dont l’une s’est produite le 23 novembre 2023.

Dans le cadre des recherches en cours de Zengo X dans le domaine de la sécurité de la blockchain, nous avons enquêté sur le cas des 139 BTC récemment perdus, qui s’élevaient à environ 5,5 millions de dollars à l’époque. À notre insu, ce faisant, nous avons ouvert BTC boîte de Pandore de la Forêt Sombre.

En 2020, les chercheurs de Paradigm Dan Robinson et Georgios Konstantopoulos ont publié un article de blog influent intitulé « ETH Workshop is a Dark Forest » : révélant les bots qui se cachent dans l’obscurité des pools de mémoire de ETH Workshop, surveillant les transactions en attente et essayant de capitaliser sur les opportunités lucratives qu’ils créent. **

Aujourd’hui, nous vous révélons que ce phénomène ne se limite pas aux blockchains ETH, mais s’applique également à BTC blockchains (et peut-être à bien d’autres).

1, ce cas de frais excessifs

Le 23 novembre, un accord BTC a attiré l’attention des analystes de BTC. **Cette transaction a établi un record pour le paiement des frais, en payant plus de 3 millions de dollars (83 BTC) pour le transfert de 2 millions de dollars de BTC. **

Bien que l’explication immédiate de ces frais exorbitants (qui sont généralement censés être inférieurs à 10 $) soit de les blâmer sur une sorte d’erreur de frappe manuelle, comme cela s’est produit dans le passé, il n’a pas fallu longtemps pour que les utilisateurs prétendent qu’ils étaient les propriétaires originaux de X (avant Twitter) et qu’ils ont été piratés d’une manière ou d’une autre. **

Le propriétaire du compte X prouve cryptographiquement qu’il possède réellement l’adresse BTC en la signant avec la clé privée associée.

2, notre enquête a commencé

Au fur et à mesure que nous commençons à enquêter plus en profondeur sur cet accord d’honoraires exorbitants, des faits plus subtils mais intéressants émergent.

Transactions marquées (Source : mempool.space)

Ce qui précède montre quelques informations intéressantes :

CPFP : C’est l’abréviation de « Child Pays For Parent », ce qui signifie que l’entrée de cette transaction est la sortie d’une autre transaction non confirmée. Dans ce cas, cela signifie que pendant que la première transaction attendait dans le mempool, la transaction surfacturée s’est produite. Selon les données de l’explorateur, il a en fait été envoyé dans la même minute que la transaction précédente. **Le coût est exactement de 60% du total dépensé (83,65 / 139,4), il est donc peu probable qu’il s’agisse d’une erreur, mais plutôt du résultat d’une sorte d’action automatisée. **

RBF désactivé : l’expéditeur de la transaction a désactivé l’option « Remplacer par des frais » (RBF) ou a empêché d’autres transactions d’écraser la transaction avec des frais plus élevés. De plus, un autre utilisateur X a remarqué qu’il y avait initialement plusieurs transactions de dépassement de frais candidates, se remplaçant les unes les autres en payant des frais plus élevés (qui ne sont plus visibles dans l’explorateur, car les informations de transaction remplacées ont été effacées dans un court laps de temps).

3. Situation réelle : Supposons d’abord

Sur la base des données, il y a plusieurs hypothèses possibles pour expliquer cette transaction de dépassement de frais :

Le propriétaire d’origine a payé trop cher pour une erreur de frappe : la déclaration du propriétaire sur X était juste pour sauver la face, car prétendre avoir été piraté semble plus acceptable que d’admettre être maladroit.

Note : Cela ne semble pas très plausible, car la transaction a été envoyée alors que la transaction précédente était encore dans le mempool (voir CPFP ci-dessus), ce qui nécessitait une expertise technique, et la nature exacte des frais (exactement 60 % des frais totaux) ne correspond pas à la théorie de l’erreur de saisie ou de la maladresse générale.

La clé privée du propriétaire d’origine a été piratée : l’attaquant a révélé la clé privée et a attendu que le propriétaire envoie des fonds à l’adresse.

Notre avis : C’est peu probable car la transaction a été préemptée par RBF, ce qui signifie que plusieurs parties sont au courant de la clé privée.

La clé privée du propriétaire d’origine est prévisible : la clé privée est créée de manière prévisible, par exemple en hachant une phrase secrète (« Brian-wallet ») ou en sélectionnant une clé dans un ensemble trop petit (32 bits). Ces questions sont abordées en profondeur dans notre récent article de blog.

Les attaquants génèrent une collection de toutes ces clés privées prévisibles et de leurs adresses correspondantes, et chaque fois qu’une transaction pour envoyer des fonds à l’une de ces adresses se trouve dans le mempool, ils se précipitent immédiatement pour envoyer des transactions ultérieures afin de transférer ces fonds à leur adresse.

Cette dernière hypothèse explique tout : une réponse immédiate (« CPFP » ci-dessus) et des frais exorbitants sont ce que les attaquants doivent faire pour vaincre d’autres attaquants. Le caractère « forfaitaire » de la redevance (60%) est dû au caractère automatique de l’opération, nécessaire pour faire échec aux autres parties. La désactivation du RBF est un autre mécanisme utilisé par les attaquants pour augmenter leurs chances de vaincre d’autres parties.

Cette hypothèse est également cohérente avec le comportement passé de l’adresse à l’extrémité destinataire d’une transaction à frais excessivement élevés. Bon nombre des transactions qui affluent à l’adresse ont les mêmes caractéristiques que cette transaction à frais élevés (mais pas aussi lucratives que cette transaction de plusieurs millions de dollars).

Le comportement des attaquants est cohérent (source : X/Twitter).

Cette conclusion est, bien sûr, une explication très effrayante et audacieuse qui nécessite des preuves supplémentaires. **

4. Preuves

Pour vérifier nos affirmations, nous avons décidé de générer une clé privée prévisible, d’y envoyer des fonds et d’observer les résultats. Si nos hypothèses sont correctes, alors les fonds devraient être volés immédiatement. Pour créer une clé privée non aléatoire et obtenir l’adresse générée, nous avons utilisé l’outil Web populaire de Ian Cloeman (qui a également bien fonctionné dans le passé).

Définissez la clé privée sur « 1 » (notez que la phrase mnémotechnique générée est principalement composée du mot « abandon » avec l’index 0)

À l’aide de cet outil, nous avons défini la clé privée sur « 1 » et obtenu l’adresse générée : bc1q4jgysxym8yvp6khka878njuh8dem4l7mneyefz. Nous avons vérifié qu’il n’avait pas été utilisé auparavant pour exclure d’autres explications possibles.

Ensuite, nous avons envoyé une transaction de 10 $ à cette adresse… Comme prévu, nous avons découvert que cela a été suivi d’une transaction de frais exorbitants (5 $, ou 50 %) qui a redirigé les fonds vers une autre adresse !

En outre, nous avons observé une concurrence féroce entre plusieurs parties essayant d’obtenir un avantage par le biais du RBF avec des frais plus élevés, qui se sont même élevés à près de 99% des fonds, mais ces tentatives ont échoué en raison de la première transaction désactivant le RBF.

4 transactions RBF, la dernière offrait 9,87 $ sur un total de 10 $ de frais.

5. Conclusion : les monstres existent bel et bien

Si la phrase de récupération ou la clé privée d’un utilisateur est générée de manière prévisible ou soumise à un caractère aléatoire indésirable, elle sera exploitée une fois que l’attaquant aura appris les détails exacts de la génération prévisible. **

Comme nous l’avons détaillé dans notre récent article de blog, la question de la génération de clés sécurisées dans les portefeuilles de crypto-monnaies est négligée par la plupart des utilisateurs, mais elle s’avère être un problème qui affecte les portefeuilles et entraîne d’énormes pertes.

Étant donné que les utilisateurs ne peuvent pas générer leurs propres clés privées, mais qu’ils ne peuvent pas prouver que les clés privées sont aléatoires, les utilisateurs ne peuvent pas vérifier le caractère aléatoire de leurs clés et doivent faire confiance à leurs portefeuilles.

Ce problème est une autre manifestation d’un problème de base plus large qui repose sur les portefeuilles à parti unique. Afin de résoudre ce problème central, ainsi que le problème spécifique de l’aléatoire, nous devons accepter le fait que les utilisateurs doivent faire confiance à certaines entités externes et passer à une architecture plus robuste qui réduit la confiance dans chaque partie impliquée en augmentant le nombre de parties impliquées. **

L’ajout de participants peut réduire la confiance requise pour chaque participant et rendre le système plus robuste (voir notre récent article de blog pour plus de détails).