Comment Namecoin Blockchain Research a prédit les cyber-attaques RTM

La blockchain Namecoin a été créée comme une alternative aux registraires DNS traditionnels, protégée de la censure et de la saisie forcée de domaine. Au cours des dernières années, des opérateurs de botnet tels que Dimnie, Shifu, RTM et Gandcrab ont commencé à l'utiliser pour gérer les adresses des serveurs C&C.

D'une part, la décentralisation et la stabilité de la blockchain empêchent les chercheurs et les prestataires de supprimer de tels domaines ou d'en prendre le contrôle. D'autre part, l'infrastructure basée sur la blockchain a une caractéristique architecturale: tous les changements dans le réseau sont accessibles au public et peuvent être utilisés pour étudier et suivre les actions des attaquants.

Cet article présente l'approche utilisée pour cartographier les botnets en Namecoin et les suivre pour extraire de nouveaux IOC. En utilisant l'approche décrite, des listes d'actifs (voir l'annexe) utilisées par les botnets mentionnés ci-dessus ont été compilées.

Digression lyrique

Les inventions qui modifient Internet résolvent souvent non seulement et pas tant un problème technique que social. Ce sont précisément ces technologies et services qui permettent à la communauté de regarder de côté certains axiomes qui semblaient inébranlables, de les repenser, de recréer à partir de zéro, en ne laissant qu'une idée et en abandonnant la charge des conventions et des limitations héritées accumulées au fil des ans. Blockchain et Bitcoin, Tor, Wikipedia - derrière le succès de chacun d'eux est un petit groupe de passionnés aux yeux brûlants, croyant sincèrement qu'ils font une société meilleure.

Hélas, d'autres viennent souvent après eux - étrangers aux idéaux étranges des pionniers de l'Internet, mais beaucoup plus pratiques. Ils trouvent une application alternative à la technologie, à laquelle les créateurs n'ont pas pensé (ou n'ont pas voulu penser). Étant à la frontière (et le plus souvent, pour cacher, franchement à l'étranger) du admissible, cette application alternative, souvent non sans l'aide des médias, pour la majorité se transforme en un défaut implicite , voire le seul .

L'équivalence de la technologie en tant qu'idée et la méthode la plus discutée de son utilisation peuvent conduire au rejet par la société de la technologie elle-même. Du fait de la criminalisation de son utilisation, un service immature peut être réduit au niveau d'une culture marginale ou complètement détruit. C'est donc arrivé il y a longtemps avec Napster , il n'y a pas si longtemps - avec BitTorrent et Tor, en ce moment, cela se produit avec Bitcoin.

Ce n'est pas passé le héros de ce travail - Namecoin. Namecoin est une chaîne de blocs conçue pour stocker des paires clé-valeur arbitraires, dont la plus célèbre est un système d'enregistrement de nom DNS décentralisé et résistant à la censure - Dot-Bit.

Notre intérêt pour Namecoin a grandi après que le groupe de gestion du botnet RTM a commencé à utiliser Dot-Bit pour gérer ses serveurs C&C. À un moment donné, nous nous sommes demandé - est-il possible de détecter de nouveaux serveurs C & C immédiatement après leur enregistrement dans Dot-Bit? Et s'il n'y a pas eu de problèmes avec les mises à jour de domaines bien connus, le développement d'une approche qui permet de détecter des preuves solides de la connexion de nouveaux domaines avec une personne d'intérêt s'est soudain avéré être une tâche de recherche passionnante, dont le résultat a été ce travail.

En général, la recherche Namecoin et la collecte d'indicateurs de compromis en Dot-Bit ont été effectuées plus tôt. Le travail le plus détaillé peut être considéré comme un article de Kevin Perlow . Il a été le premier à attirer l'attention sur la possibilité fondamentale d'extraire des données de Namecoin et a décrit plusieurs techniques heuristiques qui permettent à un expert de trouver des domaines de caractéristiques similaires aux serveurs C&C bien connus d'un groupe particulier.

L'approche présentée dans cette étude présente plusieurs différences significatives par rapport à la technique experte d'indexation et de pivotement décrite par Kevin. Les règles heuristiques que nous avons développées pour déterminer les propriétaires de domaine dérivent des principes de la blockchain et de la formation de transactions en son sein et, en plus de la description générale, sont présentées sous la forme de formulations logiques strictes. Avec une description formelle de l'algorithme de contournement, cela vous permet d'automatiser la recherche d'IOC, ce qui augmente considérablement l'efficacité de l'enquête. De plus, l'algorithme développé permet non seulement de trouver d'autres noms qui étaient autrefois utilisés par le groupe d'étude, mais vous permet également de suivre la création de nouveaux domaines contrôlés par la même personne.

Tout le travail est divisé en trois chapitres. Le premier chapitre décrit les bases du Bitcoin, dont le code a été utilisé comme plate-forme pour créer Namecoin. De nombreuses entités, relations et leurs implémentations définies dans Bitcoin ont été héritées par Namecoin. Leur compréhension est cruciale pour une discussion plus approfondie.

Le deuxième chapitre est consacré directement à Namecoin et à son application principale - Dot-Bit.

Le troisième chapitre décrit l'approche proposée pour extraire des données de Namecoin, et donne également une description formelle de l'algorithme de contournement de la blockchain et des règles heuristiques utilisées pour établir des relations entre les domaines.

Les annexes contiennent des IOC collectés à l'aide de la méthode décrite pour certains réseaux de zombies, ainsi qu'une liste de références et de référentiels qui aideront les chercheurs qui souhaitent continuer à travailler sur ce sujet.

Bitcoin 201

La plupart des informations de cette section sont collectées à partir des documents de la série d'articles de Sergey Pavlov_dog Potekhin « Bitcoin en bref ». Pour les lecteurs russophones, cette source est, à notre avis, la plus complète et la plus approfondie accessible au public, mais elle est étonnamment facile à lire. Chercheurs intéressés par le dispositif interne de Bitcoin, nous vous invitons à ne pas vous limiter aux extraits donnés dans cette section, mais à vous familiariser avec le texte intégral des articles, disponible via le lien dans l'application. Le reste des informations présentées ci-dessous sera suffisant pour comprendre la description de l'algorithme et des règles heuristiques pour trouver la relation entre les adresses en Namecoin, donnée dans le dernier chapitre.

Bien qu'il soit habituel de commencer l'histoire de la blockchain avec des blocs et de la cryptographie qui les relie, nous commencerons par les transactions.

Transaction

Comme vous le savez, l'analogue le plus proche de Bitcoin est un livre de comptes dans lequel toutes les transactions avec des pièces sont enregistrées. Mais, étrangement, dans Bitcoin, il n'y a pas de tableau général du formulaire <, > , tout comme il n'y a pas de comptable en chef qui éditerait ce tableau.

Au lieu de cela, la blockchain très notoire est utilisée, c'est-à-dire que toutes les transactions sont généralement stockées. Pour simplifier, nous pouvons supposer que ce sont des messages de la forme:

 <address 1> sent <amount> BTC to <address 2> 

Donc, si vous parcourez toute la blockchain, vous pouvez calculer combien de pièces «appartiennent» à une adresse particulière.

Entrées et sorties

Une transaction réelle sur un réseau Bitcoin est un peu plus compliquée que celle décrite ci-dessus. Il s'agit d'une structure dont les principaux composants sont les entrées et les sorties.

Les entrées sont des transactions auxquelles vous vous référez. Imaginez que trois transactions ont été envoyées à votre adresse X une fois:

 TXN_ID: 123456, VALUE: 40 BTC TXN_ID: 645379, VALUE: 10 BTC TXN_ID: 888888, VALUE: 100 BTC 

Si vous devez dépenser, par exemple, 45 BTC , vous pouvez vous référer à la transaction 888888 ou à deux transactions à la fois: 123456 et 645379 .

Sorties - littéralement "sorties". Nous pouvons supposer que ce sont des «adresses» auxquelles des pièces seront «envoyées» à la suite de la transaction. Il peut également y avoir plusieurs sorties, chacune ayant son propre montant.

Dans l'image ci-dessous, une nouvelle transaction C , qui fait référence à deux sorties - A et B En conséquence, la transaction a 0.008 BTC à l'entrée, qui sont ensuite divisés en deux sorties - 0.001 BTC envoyé à la première adresse et 0.006 BTC à la seconde.



La possibilité de spécifier plusieurs sorties à la fois est une caractéristique très importante, car la sortie de transaction ne peut être utilisée comme entrée qu'une seule fois et uniquement dans son intégralité . Si vous avez une transaction entrante à 10 BTC et que vous devez en dépenser 8, vous créez simplement une transaction avec une entrée et deux sorties: 8 BTC pour le vendeur et 2 BTC pour votre adresse. Si vous créez une transaction dans laquelle la somme des sorties est inférieure à la somme des entrées (comme dans l'image), la différence est envoyée à l'adresse du mineur qui a écrit votre transaction dans le bloc.

Frais

C'est cette différence entre la somme des entrées et la somme des sorties qui est appelée « transaction fee », transaction fee . C'est la deuxième source de revenus la plus importante pour les mineurs, et le temps qu'il faut pour que la transaction soit incluse dans la blockchain en dépend. Cela est dû au fait que chaque mineur dispose d'un certain pool de transactions non vérifiées qui prétendent être dans le bloc, et, en règle générale, le mineur les trie simplement par ordre décroissant, maximisant ainsi leur profit. Par conséquent, plus la commission est élevée, plus vous serez dans la file d'attente et plus votre paiement ira vite.

La vue générale de la transaction est décrite dans la spécification officielle du protocole , ici un des cas particuliers les plus courants est donné.



previous output hash - identifiant (hachage) de la transaction à laquelle nous faisons référence. previous output index - puisque nous devons nous référer non pas à la transaction elle-même, mais à l'une de ses sorties, alors dans ce paramètre, nous indiquons quelle sortie particulière nous intéresse. La numérotation commence à zéro. value - la quantité de Satoshi ( 1/100000000 BTC) envoyée à la sortie. Il est enregistré sous une forme peu endienne, c'est-à-dire 62 64 01 00 00 00 00 00 - c'est 0x016462 ou 0.00091234 BTC .

Les paramètres de block lock time et de sequence sont rarement utilisés dans la pratique. Nous ne sommes pas intéressés par eux, nous allons donc omettre la description de leur objectif.

Mais sur les paramètres avec le mot script dans le titre, nous nous attardons plus en détail.

Script

Le réseau Bitcoin dispose d'un mécanisme basé sur des algorithmes cryptographiques avec une clé publique qui vous permet de créer un système dans lequel seul le propriétaire de la clé peut utiliser les pièces associées à l'adresse obtenue à partir de cette clé. Nous allons voir comment cela est mis en œuvre sous le capot.

Pour commencer, à l'intérieur de Bitcoin, il existe un langage de programmation empilé simple appelé Script . Voici le programme de script le plus simple:

 2 3 OP_ADD 5 OP_EQUAL 

Chaque instruction est appelée opcode , il y en a environ 80. L'image ci-dessous montre le processus d'exécution du programme ci-dessus.











Dans Bitcoin Script est utilisé pour définir une condition dans laquelle il sera possible de dépenser la sortie et de pouvoir confirmer que la condition est remplie. La condition ( locking script ) est stockée dans la transaction dans le champ scriptPubKey pour chaque sortie. La confirmation que la condition est remplie ( unlocking script ) est écrite dans le champ scriptSig pour chaque entrée.

Pour vérifier le droit d'utiliser la sortie, vous devez connecter le unlocking script + le locking script et exécuter le programme résultant dans son ensemble. Si après exécution, TRUE reste au sommet de la pile, alors la transaction est valide.

Payer au hachage de clé publique (P2PKH)

Le script P2PKH utilisé dans la plupart des transactions, vous devez donc comprendre comment il fonctionne. Voici sa vue générale:



Ce script est connu depuis l'avènement du Bitcoin, et il effectue la tâche mentionnée au début du chapitre - s'assurer que seul le propriétaire de la clé peut utiliser les pièces associées à l'adresse obtenue à partir de cette clé.

L'idée est la suivante: laissez votre ami B posséder une paire de clés - P (privé) et K (public). À l'aide de la fonction de hachage, il obtient l'adresse A de la clé publique et vous indique l'adresse. Ensuite, vous envoyez, par exemple, 1 BTC à l'adresse A et écrivez ce qui suit dans le champ du locking script :

Seule une personne possédant la clé privée de l'adresse A peut dépenser cette transaction. Pour preuve, écrivez dans le unlocking script , d'une part, la clé publique K , et d'autre part, la signature de la transaction avec la clé privée P

Lorsque B décide d'utiliser votre transaction comme entrée, il crée, par exemple, 0.5 BTC , et dans le champ de unlocking script , unlocking script met la signature de sa transaction avec la clé privée P - sig et la clé publique K- PubK .

Voici le processus d'exécution du programme combiné:

Blocs et blockchain

Si la blockchain entière est un livre, les blocs individuels peuvent être représentés comme des pages sur lesquelles les transactions sont enregistrées. Chaque bloc "se réfère" au précédent, et ainsi de suite jusqu'au tout premier bloc ( genesis block ). C'est ce qui crée une telle fonctionnalité de la blockchain que l'immuabilité. Vous ne pouvez pas prendre et modifier le bloc #123 pour que personne ne le remarque: la blockchain est conçue de manière à entraîner un changement dans le bloc #124 , puis #125 et ainsi de suite, tout en haut.

La structure du bloc ressemble à ceci:



Les six premiers paramètres (tous sauf txn_count et txns ) forment l'en-tête du bloc. Le hachage d'en-tête est appelé hachage de bloc; Les transactions elles-mêmes ne participent pas directement au hachage. merkle_root est responsable de leur immuabilité - s'il est simplifié, il s'agit d'un hachage de toutes les transactions dans le bloc. Vous pouvez en savoir plus sur l'algorithme de construction de l'arbre Merkle ici sur ce lien .

Le nonce et les bits sont directement liés au processus d'apparition des blocs - minage.

Exploitation minière

Le minage est un processus critique pour Bitcoin, consistant à créer de nouveaux blocs et à poursuivre deux objectifs à la fois. Le premier est la production de masse monétaire. Chaque fois qu'un mineur crée un nouveau bloc, il est récompensé pour cela avec le Nième nombre de pièces qu'il dépense ensuite quelque part, lançant ainsi de nouveaux fonds dans le réseau.

Le deuxième objectif, beaucoup plus important, est de contrôler le respect des règles du réseau. Ce sont les mineurs qui vérifient les scripts et les entrées de transaction avant de les inclure dans le bloc.

Ceux qui souhaitent en savoir plus sur les fondements financiers du Bitcoin peuvent conseiller cet article . Je n'accorderai pas beaucoup d'attention au premier aspect de l'exploitation minière et je me concentrerai sur le second - vérifier les transactions et les lancer sur le réseau.

Preuve de travail

Laissez-vous être mineur. Vous avez 10 transactions que vous souhaitez inclure dans le bloc. Vous vérifiez la validité de ces transactions, en forme un bloc, spécifiez 0 dans le champ nonce et considérez le hachage de bloc. Puis changez nonce en 1, comptez à nouveau le hachage.

Votre tâche consiste à trouver un nonce tel que le hachage de bloc (nombre 256 bits) soit inférieur à un nombre prédéterminé N La recherche d'un tel hachage n'est possible que par le nonce force brute. Par conséquent, plus vous voulez trouver rapidement du nonce, plus vous aurez besoin de puissance.

Le nombre N est exactement ce paramètre (il est aussi appelé target ), que le réseau ajuste en fonction de la puissance totale des mineurs. Si demain des blocs commencent à sortir, relativement parlant, toutes les trois minutes, alors N sera réduit, plus de temps sera nécessaire pour rechercher le nonce et block time augmentera à nouveau à 10 minutes. Et vice versa.

Voilà à quoi ressemble l'algorithme de preuve de travail sous-jacent à Bitcoin et à de nombreuses autres chaînes de blocs. D'une simplicité apparente, il présente un certain nombre de caractéristiques importantes:

• La création d'un nouveau bloc est une tâche difficile sur le plan des calculs. Dans le même temps, la vérification de l'exactitude du bloc est une opération simple et presque instantanée.
• L'ensemble du réseau prend 10 minutes pour calculer un nouveau bloc (en moyenne). L'heure spécifique est différente pour chaque blockchain, mais l'essentiel est que la durée moyenne est prédéfinie. De plus, cette durée ne dépend pas du nombre de participants au réseau. Même si un jour il y aura cent fois plus de mineurs, l'algorithme changera ses paramètres pour qu'il devienne plus difficile de trouver le block time et block time retombe au voisinage de l'heure spécifiée.
  
  Comme décrit ci-dessus, le processus d'exploration se résume à trouver un hachage de bloc inférieur à un nombre appelé target . Dans la structure de blocs, ce nombre est écrit dans le champ des bits. Par exemple, pour le bloc #277316 target était 1903a30c .

Comme décrit ci-dessus, le processus d'exploration se résume à trouver un hachage de bloc inférieur à un nombre appelé target . Dans la structure de blocs, ce nombre est écrit dans le champ des bits . Par exemple, pour le bloc #277316 target était 1903a30c .

 $ bitcoin-cli getblock 0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4 { "hash" : "0000000000000001b6b9a13b095e96db41c4a928b97ef2d944a9b31b2cc7bdc4", "confirmations" : 35561, "size" : 218629, "height" : 277316, "version" : 2, "merkleroot" : "c91c008c26e50763e9f548bb8b2fc323735f73577effbc55502c51eb4cc7cf2e", "tx" : ["d5ada064c6417ca25c4308bd158c34b77e1c0eca2a73cda16c737e7424afba2f", ...], "time" : 1388185914, "nonce" : 924591752, "bits" : "1903a30c", // <--   "difficulty" : 1180923195.25802612, "chainwork" : "000000000000000000000000000000000000000000000934695e92aaf53afa1a", "previousblockhash" : "0000000000000002a7bbd25a417c0374cc55261021e8a9ca74442b01284f0569", "nextblockhash" : "000000000000000010236c269dd6ed714dd5db39d36b33959079d78dfd431ba7" } 

En bits en fait, deux nombres sont écrits à la fois: le premier octet 0x19 est l'exposant, les trois autres octets 0x03a30c sont la mantisse. Pour obtenir la target partir de bits , vous devez utiliser la formule suivante:

 target = mantissa * 2^(8 * (exponent - 3)) 

Mais ce sont des bits , en règle générale, qui sont indiqués dans tous les registres de blocs en ligne, tels que, par exemple, https://namecha.in/ - Registre de blocs Namecoin.

Et oui, assez de théorie. Tout ce dont nous avons parlé ci-dessus lorsqu'il est appliqué à Bitcoin s'applique également à Namecoin - à l'exception des petites différences, dont nous parlerons dans la section suivante.

Namecoin

Namecoin est une blockchain basée sur les algorithmes et le code source de Bitcoin, dont l'idée principale est d'utiliser un schéma de registre de transactions distribué pour gérer un système de nom de domaine, un analogue du DNS traditionnel.

Namecoin copie les principales approches Bitcoin (Proof-of-Work, intervalle de génération de blocs de 10 minutes) et les formats de données, à l'exception de petits ajouts, dont nous parlerons plus tard.

Les domaines Namecoin ont le suffixe .bit. Cette zone n'a pas été allouée par l'IANA et n'a pas été affectée à la liste des domaines à usage spécial . Les serveurs DNS normaux répondent généralement à ces demandes NXDOMAIN. Mais il existe des passerelles de DNS à Namecoin (par exemple, OpenNIC ), des proxys publics avec prise en charge de Namecoin, des plug- ins de navigateur et un projet open source qui vous permet de démarrer votre propre serveur DNS avec prise en charge de Namecoin.

Pour gérer un domaine avec le nom, disons facebook.bit , il suffit d'enregistrer la clé d/facebook préfixe d/facebook est utilisé dans Namecoin pour les domaines) et de déterminer sa valeur. Le format JSON est utilisé pour définir les valeurs. Une entrée qui définit la résolution de domaine sur l'adresse IP 1.2.3.4 ressemble à ceci:

 {"ip": ["1.2.3.4"]} 

Namecoin attribue les noms sur la base du premier arrivé, premier servi . Même pour Mark Zuckerberg lui-même, il sera cryptographiquement impossible de prendre le domaine facebook.bit au propriétaire.

En fait, rien ne limite l'utilisation de Namecoin à la seule gestion des ensembles de noms DNS - adresse IP. Namecoin peut être utilisé (et utilisé) comme table distribuée pour mapper des clés arbitraires à des valeurs. Mais nous nous concentrerons précisément sur le scénario de son utilisation dans lequel il représente un DNS alternatif sur blockchain.

Gestion de domaine

Namecoin utilise une transaction pour stocker un enregistrement de domaine. A savoir, le champ scriptPubKey contenant le programme est la condition pour utiliser la sortie de transaction, à laquelle nous avons consacré tant de temps dans le chapitre précédent. Pour gérer les enregistrements, Namecoin a introduit trois nouveaux opérateurs (plus précisément, les opérateurs existants redéfinis):

• NAME_NEW
• NAME_FIRSTUPDATE
• NAME_UPDATE

Leur signification ressort clairement des noms, mais nous analyserons néanmoins le but et le format d'utilisation de chacun d'eux.

Vous pouvez remarquer que l'opérateur de suppression ou d'invalidation de domaine est manquant. Pour nettoyer le registre des noms inutilisés, un mécanisme est intégré au réseau qui libère automatiquement un nom qui n'a pas été mis à jour depuis 36 000 blocs (~ 250 jours).

NAME_NEW

La première étape consiste à annoncer l'intention d'enregistrer un nouveau nom sur le réseau. Pour ce faire, créez simplement une pièce spéciale (sortie) pesant au moins 0.01 NMC , dont le output script ressemblera à ceci:

 OP_NAMENEW <20 byte hash> OP_2DROP <lock script> 

Pour le démontrer, je vais utiliser les transactions que Stephen Morse a faites pour illustrer son article .

Donc, si nous voulons annoncer l'enregistrement du nom d/stephenmorse , alors nous devons faire ce qui suit:



En regardant la transaction qui en résulte, vous pouvez remarquer deux faits intéressants. Premièrement, malgré le fait que le output script écrit en notation Namecoin, il est toujours valable du point de vue du Bitcoin d'origine. Les créateurs de Namecoin ont si bien choisi les codes pour leurs opérations qu'en Bitcoin ils correspondent à des opérations qui sont essentiellement équivalentes à l'écriture dans la pile constante. NAME_NEW (0x51) correspond à OP_1 , qui pousse OP_1 pile 1. Une histoire similaire avec NAME_FIRSTUPDATE ( 0x52 ou OP_2 , met 2) et avec NAME_UPDATE ( 0x53 ou OP_3 , met 3). Ainsi, les deux premières étapes du script ne mettent que deux valeurs sur la pile. Et la prochaine opération OP_2DROP supprime de la pile, de sorte que le P2PKH supplémentaire fonctionne «à partir de zéro». Par conséquent, toutes ces astuces de script que nous avons couvertes dans le chapitre sur Bitcoin sont également applicables à Namecoin, malgré la redéfinition de certaines opérations.

Deuxièmement, les clés qui ouvrent une pièce spéciale et la changent sont différentes. Bien que rien ne vous empêche techniquement d'utiliser la même clé à plusieurs reprises, il est courant de générer une nouvelle clé pour chaque reçu. Ceci est fait pour rendre difficile l'identification des corrélations entre les transactions et augmenter le niveau d'anonymat dans le réseau.

À première vue, il semble étrange que, contrairement au bon sens, il soit impossible de prendre et d'enregistrer immédiatement un nom et une adresse IP pour celui-ci. Ceci est fait pour que personne ne puisse intercepter le nom dès qu'il voit que vous voulez l'enregistrer (puis vous le revendre).

Par exemple, les mineurs, en analysant les transactions non confirmées (qui ne sont encore incluses dans aucun des blocs) du réseau, pourraient créer leur propre transaction pour l'enregistrement du même domaine et l'inclure (et non la vôtre) dans leur bloc. Pour implémenter cette attaque, il n'est même pas nécessaire de miner votre bloc. Il suffira de mettre votre transaction sur le réseau moyennant des frais importants. Par conséquent, deux opérations distinctes NAME_NEW et NAME_FIRSTUPDATE , et la seconde ne peut être effectuée que par celui qui a effectué la première, et uniquement après que NAME_NEW est entré dans un bloc.

En fait, cette restriction est encore un peu plus stricte: NAME_FIRSTUPDATE est possible au plus tôt 12 blocs après NAME_NEW (soit environ 2 heures). Pour comprendre pourquoi les blocs de cette restriction ne sont pas 1, pas 2, pas 3, mais spécifiquement 12, nous devrons prendre un peu de recul par rapport à l'histoire principale et comprendre ce que sont la fork et l' 51% attack .

NAME_FIRSTUPDATE

Le but de l'opération NAME_FIRSTUPDATEest de publier le nom que j'ai annoncé NAME_NEWet de lui spécifier une valeur. Pour ce faire, je dois lancer une transaction sur le réseau, dont l'entrée est la pièce très spéciale que j'ai générée à la sortie NAME_NEW. Afin de confirmer le droit de l'utiliser, je présente dans le script d'entrée ma clé publique et la signature de la transaction NAME_NEWeffectuée par la clé de paire privée, exactement selon le schéma que nous avons examiné dans le chapitre sur P2PKH.

L'un des résultats de la transaction sera une nouvelle pesée spéciale des pièces, comme la précédente, rien de moins 0.01 NMC. Son script de sortie devrait être comme ceci:

 OP_NAME_FIRSTUPDATE <Name> <Salt> <Value> OP_2DROP OP_2DROP <lock script> 

SaltEst le nombre très aléatoire 0xd5eeb22ee8117f57que nous avons créé lors de la première étape de préparation du script NAME_NEW. Name- il est d/stephenmorseen hexadécimal 0x642f7374657068656e6d6f727365.

Le champ Valuedoit contenir un tableau associatif représentant les règles selon lesquelles le nom sera résolu. Une liste complète des clés et règles possibles pour les remplir ici . En première approximation, il s'agit d'un analogue du fichier de zone; le lien ci-dessus montre le mappage des entités Namecoin avec des entités DNS familières. Les plus populaires d'entre eux sont ip, un exemple avec lequel était plus élevé, et ns, que nous utilisons maintenant.

Pour indiquer ce que sera le serveur NS pour le domaine, nous 1.2.3.4mettrons une valeur dans Value {“ns”:[“1.2.3.4”]}, mais, bien sûr, en hexadécimal - 0x7b226e73223a5b22312e322e332e34225d7d.

Comme la dernière fois, fermez la pièce avec P2PKH. Dans son exemple, Stephen a délibérément créé une pièce à l'étape NAME_NEW avec un poids pas exactement 0.01 NMC, mais avec une marge, de sorte qu'à l'étape suivante, cette marge serait suffisante pour la commission au mineur. Dans le cas général, la transaction aura une entrée de plus pour assurer la commission - et une sortie de plus pour la livraison.

Nous collectons tout dans une transaction et le jetons dans le réseau .



Lorsque la transaction tombe dans le bloc, les hôtes mettront à jour dans leurs tables la valeur de la clé d/stephenmorseactivée {“ns”:[“1.2.3.4”]}. Tous les navigateurs prenant en charge Namecoin résoudront désormais le domaine stephenmorse.bitet ses sous-domaines en adresses IP via le serveur DNS situé à l'adresse 1.2.3.4.

NAME_UPDATE

Le «tableau» avec les clés et leur signification, que j'ai mentionné à la fin de la dernière section, est en fait appelé UTXO set (unspent transaction output). Puisqu'il est essentiel que le réseau empêche les dépenses répétées de fonds, avant d'ajouter une transaction au bloc, le mineur vérifie si les entrées précédemment spécifiées dans la transaction ont été utilisées. Pour accélérer cette opération, toutes les sorties inutilisées sont stockées dans une structure de données distincte. Cette structure n'existe pas au niveau du réseau, mais est calculée et stockée localement par chaque nœud.

Après avoir terminé la transaction NAME_FIRSTUPDATE, la sortie de ma pièce avec un poids 0.01 NMC, à laquelle la valeur de la clé est attachée d/stephenmorse, a frappé la tableUTXO. Si cette sortie n'est pas dépensée pour 36 000 blocs (soit plus de 8 mois avec 10 minutes par bloc en moyenne), alors elle sera considérée comme invalide et le nom correspondant comme gratuit.

Cette période de 36 000 blocs (ainsi que la valeur minimale d'une pièce spéciale en 0.01 NMC) est clairement définie au début du réseau et reste inchangée. Pour prolonger l'enregistrement du nom, ainsi que pour toute modification de l'enregistrement ou le transférer à un autre propriétaire, une transaction est utilisée NAME_UPDATE.

Les règles pour la formation d'une telle transaction ne diffèrent pratiquement pas de celles décrites ci-dessus. L'entrée pour la transaction doit être la sortie de la pièce obtenue dans la transactionNAME_FIRSTUPDATE. Un apport supplémentaire est nécessaire pour assurer la commission. Des deux sorties de la transaction, l'une est une nouvelle pièce avec une valeur mise à jour pour le nom, et la seconde est conçue pour transférer la modification de la commission. Le format de script de sortie pour la pièce est:

 OP_NAME_UPDATE <Name> <Value> OP_2DROP OP_DROP <lock script> 

Comme dans le cas précédent, Nameil s'agit de - d/stephenmorseet Value- JSON avec une valeur, tous deux en hexadécimal. Fermez la sortie à l'aide de P2PKH et lancez la transaction dans le réseau .


En général, c'est presque tout ce que je voulais dire sur la gestion des noms dans Namecoin. Il ne reste plus qu'à dire quelques mots sur les coûts de possession d'un domaine.

Coût

Calculons combien le contenu du nom Dot-Bit(le nom de la zone DNS .bit, fonctionnant sur la base de Namecoin) coûte en crypto-monnaie et, en traduisant les nombres en monnaie fiduciaire, est comparable au coût d'un domaine DNS "normal".

Ainsi, comme on peut le voir dans la section précédente, pour une transaction, les NAME_NEWcoûts du propriétaire du domaine seront 0.01 NMCde créer une pièce à laquelle la zone sera attachée, plus la commission du mineur. Pour une transaction, une NAME_FIRSTUPDATEnouvelle pièce est créée au détriment de l'ancienne, et en plus le propriétaire ne paie que la commission. Après environ 8 mois, le propriétaire devra terminer la transaction NAME_UPDATEpour conserver le nom enregistré. Et c'est là que les coûts requis pour la première année se terminent.

La plupart des articles sur Namecoin (y compris l' article précédemment cité par Stephen Morse) sont basées sur des données des premières années d'existence du réseau et affirment que la commission du mineur est de 0,005 NMC. Mais depuis lors, la valeur médiane de la commission a progressivement diminué et au début de 2019 est d' environ 0,0003 NMC. Le taux de change du NMC par rapport au dollar américain, au contraire, ayant subi plusieurs hausses, est revenu au niveau de 2015 et s'élève à environ 0,7 $ pour 1 NMC. Il est facile de calculer que le domaine dans la zone .bit la première année coûtera au propriétaire 0,0109 NMC ou 0,00763 $. Peut-être qu'il sera plus facile pour quelqu'un de se rappeler un analogue approximatif de ce montant en monnaie russe - 50 kopecks.

Eh bien, c'est la limite inférieure qui correspond au scénario d'achat d'un nom pour une utilisation future ou un cybersquattage. Et la limite supérieure? Étant donné que l'entrée de chaque transaction mettant à jour la zone doit être une pièce d'un des blocs précédents, le maximum théorique de la fréquence de mise à jour du nom est égal à la fréquence de l'apparition de nouveaux blocs. Rappelant que la valeur moyenne de cette valeur a été fixée au début du réseau et est d'environ 10 minutes, on peut estimer que la limite supérieure du coût de maintenance d'un domaine sera de 15,7744 NMC ou un peu plus de 11 $.

Comme vous pouvez le voir, même un scénario aussi fantastique d'utiliser un nom en Namecoin à un coût équivaut approximativement à la première année de possession d'un domaine régulier dans la zone .com la plus populaire. Si nous comparons un scénario plus réaliste avec une mise à jour en moyenne une fois par jour, le nom dans la zone .bit coûtera environ 8 cents par an, ce qui est beaucoup moins cher que les offres les plus avantageuses du DNS traditionnel, qui ne tombent pas en dessous de 1 $. Dans le scénario d'utilisation à court terme du domaine (de plusieurs heures à un mois), la différence en faveur de Namecoin sera déjà de deux ordres de grandeur.

Compte tenu de l'attractivité financière du service, ainsi que de l'anonymat du propriétaire du domaine, y compris de l'absence d'une «piste monétaire» traditionnelle pour le DNS ordinaire, il devient clair pourquoi Namecoin est devenu un réseau populaire pour les propriétaires de services avec un risque accru de déconnexion ou de blocage, en particulier les réseaux de zombies.

Botnets à Namecoin

En effet, le fait que les opérateurs de botnet aient commencé à utiliser l'anonymat Dot-Bitpour protéger leurs serveurs C&C n'est pas surprenant. Une autre chose est plus intéressante - combien de temps les botnets en .bit restent actifs.

Les domaines C&C enregistrés dans des zones DNS «ordinaires» sont tôt ou tard retirés au propriétaire, ce qui oblige l'opérateur à payer pour enregistrer un nouveau nom et lancer un nouvel assemblage de bot sur le réseau, avec un nouveau serveur de gestion. L'impossibilité fondamentale de supprimer un domaine dans la zone .bit a augmenté la durée de vie du botnet de plusieurs ordres de grandeur.

Prenons par exemple le pationare.bitdomaine enregistré en décembre 2016. Il a été utilisé pour contrôler un botnet Chthronic(distribution d'un cheval de Troie bancaire construit sur la base du fameux ZeuS). Campagne de distributionChthronica été associé à l'utilisation du pack d'exploit RIG et a été décrit en détail par divers chercheurs (par exemple malware-traffic-analysis.net ) fin 2016 et premier semestre 2017.

On pourrait supposer que ce botnet a été détruit depuis longtemps. Mais pas plus de deux ans après le lancement, le domaine C&C du botnet et son réseau sont toujours actifs. Comme le montre la capture d'écran ci-dessous, la dernière mise à jour a été effectuée en décembre 2018.



Ça a l'air tentant, non? Étant donné que le nom DNS du serveur de gestion reste intact, il n'est pas nécessaire de mettre à jour fréquemment le code bot et de redémarrer la campagne de distribution. Il ne reste que le coût de la modification de l'hébergement après avoir bloqué l'adresse IP, mais ces coûts peuvent également être réduits en utilisant des serveurs Web piratés comme proxy, dont les coques coûtent moins d'un dollar.

D'un autre côté, toutes les transactions dans la blockchain sont accessibles au public pour tout participant. Comme nous l'avons expliqué en détail dans les chapitres précédents, les pièces en Namecoin ne disparaissent pas sans laisser de trace, ce qui signifie que nous pouvons suivre leur redistribution entre les adresses. Et connaissant les règles et les restrictions, en tenant compte des transactions qui sont formées dans Namecoin, nous pouvons trouver des modèles significatifs dans lesquels la gestion uniforme de certaines adresses impliquées dans la transaction sera évidente. Dans ce cas, les domaines payés avec des pièces de ces adresses auront un propriétaire commun - le groupe que nous gérons, qui contrôle le botnet.

Nous développerons cette idée plus loin.

Système général de collecte du CIO

Décrivons le schéma de recherche général en utilisant l'exemple d'un vrai botnet du groupe RTM. Nous allons construire sur cet échantillon , qui a été identifié comme Win32/Spy.RTM.N.





Comme vous pouvez le voir sur la capture d'écran ci-dessus, après avoir démarré, il essaie d'obtenir l'adresse IP pour le nom stat-counter-4.bit. Nous obtenons des informations sur l'historique des transactions pour ce nom en Namecoin.



L'identifiant de la transaction qui a créé ce domaine, nous l'obtenons en cliquant sur le lien vers l'opération NAME_NEW. L'adresse d'entrée de cette transaction, à l'aide de laquelle le domaine a été créé, est évidemment gérée par le groupe qui nous intéresse. Il sera la première série de données: N3KPt8py24EAsAiKquyFgoKGyTYeR5Tmry.



Sur la base de l'ensemble de données initial, nous contournons de manière itérative la blockchain, en nous déplaçant dans le sens de sa croissance (mouvement ascendant ou amont). Au début de chaque étape, nous obtenons une transaction dont une certaine pièce à l'entrée appartient à la personne qui nous intéresse. Dans un premier temps, nous vérifions la transaction à partir de l'ensemble de données initial, le propriétaire des pièces à l'entrée dont nous connaissons a priori.

La transaction est vérifiée pour la conformité aux règles heuristiques (nous les formulerons ci-dessous), qui garantissent qu'une certaine pièce (ou pièces) à la sortie de la transaction appartient à la même personne que la pièce d'entrée connue. Si la transaction en question satisfait une ou plusieurs heuristiques, alors ces pièces de guidage indiqueront la direction du mouvement ultérieur. La transaction qui dépense la pièce de guidage sera la prochaine étape de l'itération.

À chaque étape de l'itération, nous reconstituons la liste des domaines qui ont participé aux transactions et la liste des adresses IP auxquelles ces domaines ont été résolus. Ce sont des identificateurs historiques de compromis (IOC), qui peuvent être utilisés pour les criminalistes, ainsi que pour identifier les tactiques et les méthodes de regroupement.

Le mouvement s'arrête si la transaction en question ne satisfait à aucune des heuristiques. Cela signifie que nous ne pouvons pas dire avec certitude que l'un des résultats de la transaction en question est contrôlé par la personne qui nous intéresse.

Une autre situation qui arrête le mouvement est le manque de transactions à partir de l'adresse de sortie. Nous enregistrerons ces adresses dans une liste séparée de pièces non dépensées (UTXO). Ils représentent la plus grande valeur de toute l'étude. Étant donné que nous sommes convaincus que ces adresses sont gérées par la personne qui nous intéresse, toute transaction future utilisant ces adresses générera un nouveau CIO inconnu auparavant - le nom de domaine ou l'adresse IP - qui n'a pas encore été utilisé par le groupement. Mais avec une forte probabilité, ce sera bientôt.

Pour contourner la blockchain, il est pratique de l'exporter vers la base de données. Pour cela, vous pouvez utiliser, par exemple, l' utilitaire rusty-blockparser modifié , dans lequel nous avons amélioré la prise en charge de Namecoin en ajoutant la reconnaissance des opérations NAME_*, les structures de données Auxiliary Proof-of-Worket en élargissant le format d'exportation.

Le pseudo-code Python pour le mouvement ascendant est présenté ci-dessous. Ci-après, il est supposé que les données de transaction de la blockchain sont stockées dans MongoDB.

 start = "37d40bc2f3ca7415908dc9e276593b50d3120158cd540cb088246f2e2cf88b16" tx = namecoin.transactions.find_one({"id": start}) def upstream_movement(tx): global names global IPs global utxo global known_addresses heuristic_result = upstream_heuristic_test(tx) if heuristic_result and heuristic_result.guiding_outs: if tx.has_name_op(): names.add(tx.name_op.name) for ip_address in tx.name_op.get_ip(): IPs.add(ip_address) for guiding_out in heuristic_result.guiding_outs: known_addresses.add(guiding_out.address) tx = namecoin.transactions.find_one({"in.id": guiding_out.id}) if tx: upstream_movement(tx) else: utxo.add(guiding_out) 

La deuxième partie du contournement de la blockchain est le mouvement contre la croissance de la blockchain (mouvement vers le bas ou mouvement en aval). En général, l'algorithme de mouvement vers le bas n'est pas différent de l'algorithme vers le haut. Un mouvement commence par une transaction de l'ensemble de données d'origine. A chaque étape, la transaction est vérifiée pour la conformité aux règles heuristiques (en général, différentes des règles de mouvement ascendant). La seule différence est que la pièce, dont l'appartenance est connue a priori, est à la sortie de la transaction, et l'heuristique garantit que la même personne a une ou plusieurs pièces à l'entrée.

Un mouvement à la baisse s'arrête également si la transaction en cours ne satisfait à aucune des heuristiques. Contrairement au mouvement vers le haut, nous ne pouvons pas rencontrer de pièces non dépensées parmi les guides, et cette option pour quitter la récursivité dans le mouvement vers le bas ne fonctionnera pas. Mais, comme pour le mouvement ascendant, nous reconstituons à la fois la liste des noms et la liste des adresses IP.

Le pseudo-code Python pour le mouvement vers le bas ressemblerait à ceci:

 start = "37d40bc2f3ca7415908dc9e276593b50d3120158cd540cb088246f2e2cf88b16" tx = namecoin.transactions.find_one({"id": start}) def downstream_movement(tx): global names global IPs global utxo global known_addresses heristic_result = downstream_heuristic_test(tx) if heuristic_result and heuristic_result.guiding_ins: if tx.has_name_op(): names.add(tx.name_op.name) for ip_address in tx.name_op.get_ip(): IPs.add(ip_address) for guiding_in in heuristic_result.guiding_ins: known_addresses.add(guiding_in.address) tx = namecoin.transactions.find_one({"out.id": guiding_in.id}) if tx: downstream_movement(tx) 

Considérons maintenant les règles heuristiques que nous utiliserons lors du déplacement le long de la blockchain.

Règles heuristiques

Changement commun

Revoyons la transaction, dont une capture d'écran est donnée ci-dessus. Une adresse N3KPt8py24EAsAiKquyFgoKGyTYeR5Tmrycontenant de l'argent pour créer un nouveau nom est envoyée à l'entrée de transaction . Il y aura deux adresses pour les transactions NAME_FIRSTUPDATEet NAME_UPDATEà l'entrée - une pièce spéciale avec une zone de la transaction précédente par domaine et des fonds supplémentaires pour couvrir la commission.

Je noterai immédiatement que dans le cadre des transactions, nous parlerons à la fois des pièces et des adresses. Malgré le fait que dans certains travaux, ces concepts sont considérés comme presque équivalents, il est important pour nous d'indiquer clairement la différence entre ces termes, car au cours de l'étude, nous tirerons des conclusions sur les pièces et les adresses.

Dire «pièce», nous entendrons un solde positif formé comme la sortie d'une transaction. Cette pièce est identifiée par le numéro de transaction qui l'a générée et l'indice de sortie. Par exemple, une pièce à l'entrée de la transaction considérée ci-dessus a un identifiant 5778be8e1901e9931e9b41a128a0b7f963e6e1ae72e461df2cba26e6279d433a:1, car elle a été formée en sortie (avec l'index 1) de la transaction 5778be8e1901e9931e9b41a128a0b7f963e6e1ae72e461df2cba26e6279d433a.

Une pièce spéciale, comme précédemment, nous appellerons une pièce d'une valeur nominale de b 0.01 NMC, locking scriptqui contient l'opération avec un nom de domaine. Nous avons examiné en détail le mécanisme de formation de ces pièces dans la section Gestion de domaine. Une pièce ordinaire, nous l'appellerons une pièce de monnaie arbitraire, à laquelle l'opération avec le domaine n'est pas liée.

La principale propriété des pièces est leur immuabilité. Toute pièce ne peut être dépensée qu'une seule fois et uniquement dans son intégralité. Ainsi, tout est mentionné sur le réseau Namecoin au maximum deux fois: une fois à la création, et une deuxième fois aux dépenses.

Dire «adresse», nous entendrons un identifiant qui identifie de manière unique une paire de clés qui peut ouvrir un script de verrouillage dans un format P2PKHqui ferme une pièce située à l'entrée ou à la sortie d'une transaction. Étant donné que seule la clé correspondant à l'adresse peut dépenser une pièce, l'analogie la plus proche du monde physique avec l'adresse est le portefeuille dans lequel les pièces sont stockées (et à partir desquelles elles sont dépensées).

Malgré le fait qu'à Namecoin, une adresse n'est souvent utilisée que deux fois, il n'est pas nécessaire de recevoir et de consommer une seule pièce. Les faits de la réutilisation des adresses nous aideront un peu à l'avenir.

Nous avons parlé plus en détail des entrées, sorties et adresses dans le chapitre de Bitcoin 201.

Ainsi, deux pièces sont formées à la sortie de la transaction. La N2hgZoWaTKoJ7FPmLuytTow3XrCCfEj2camême pièce spéciale, pesant 0,01 NMC, à laquelle le domaine est lié, est allée à l' adresse . Une NKMMLwyMw4nwGuke6vd3AuDBMP18FWRaF1pièce ordinaire avec changement a été envoyée à la deuxième adresse .

Il s'agit du schéma de transaction le plus courant. Il y a encore des options quand il y a plus d'une pièce à l'entrée, mais leur propriété commune est que la pièce avec changement est toujours exactement la même.

Vous pouvez deviner qu'une telle transaction correspond à une simple mise à jour des informations de domaine. Le paiement de la mise à jour s'effectue à l'aide d'une (moins souvent plusieurs) pièces appartenant à une seule personne. En effet, comme une transaction n'a toujours qu'un seul auteur, elle doit gérer toutes les adresses d'entrée. Sans cela, il ne sera pas en mesure de créer un script de déverrouillage, qui est nécessaire pour utiliser les pièces de ce portefeuille.

Eh bien, puisque tout le changement de cette opération est collecté dans une pièce, il est clair que cette pièce appartient à la même personne que les pièces à l'entrée.

Un schéma similaire pour Bitcoin est décrit dans ce travail , où il est appelé one-time change. Il reflète la méthode par laquelle les applications Bitcoin natives effectuent les transactions - bitcoindetbitcoin-qt. Une fois (une fois), il est appelé en raison d'une autre caractéristique de ces applications. Par défaut, ils génèrent de nouvelles adresses pour les pièces en sortie de la transaction créée.

Namecoin, avec la base de code Bitcoin, a hérité de la majeure partie du code de ces applications, appelées namecoindet namecoin-qt. En ce qui concerne les pièces ordinaires, nous pouvons utiliser cette heuristique en toute sécurité sans aucun changement.

Les statistiques de réutilisation des adresses pour le stockage des pièces spéciales montrent que cette règle est dans la plupart des cas également observée pour eux. La réutilisation de telles adresses est assez rare. Adresses utilisées plus d'une fois, environ 6% du total; plus de deux fois - environ 1%. Sur la base de l'objectif de Namecoin, il semble raisonnable de supposer que la plupart des transactions avec des pièces spéciales sur le réseau sont de simples opérations de création et de mise à jour, pendant lesquelles le propriétaire du domaine ne change pas. Par conséquent, nous pouvons affirmer qu'une telle opération correspond au retrait d'une pièce spéciale vers une nouvelle adresse, précédemment inutilisée.

Voyons maintenant un exemple de transaction avec une adresse réutilisée pour une pièce de sortie spéciale. Pour ce faire, effectuez une autre transaction du groupe RTM -b3c7ce9ca3a689c6236b9d6df3c257c5fab6c3985187669ccf731ac42a127a11.



L'adresse NDpWDEx1mBkUYywqxDTAZZeGCfUV4GkVE8à laquelle la pièce spéciale est allée était déjà utilisée dans les transactions précédentes.



Comme mentionné précédemment, les scripts par défaut dans les applications clientes natives pour Namecoin n'entraînent pas la réutilisation des adresses. Pour envoyer une pièce spéciale à une adresse existante, le propriétaire devra faire des efforts séparés et facultatifs, trouver et indiquer explicitement l'adresse de sortie au stade de la formation de la transaction.

Pourquoi cela pourrait-il être requis? La seule mention de la situation dans laquelle l'adresse de sortie est indiquée manuellement, je ne l'ai rencontrée que dans les instructions de transfert du domaine à un autre propriétaire.



La conjecture est confirmée en considérant le futur sort des adresses à la sortie de la transaction en question. Dans le diagramme ci-dessous, cette transaction est marquée par un jalon vert clair. On peut voir que la prochaine transaction 9e16f6besur le domaine stat-counter-4 a eu lieu en utilisant une adresse monétaire NJ8xUePvqui n'a pas de connexion explicite avec l'adresse utilisée dans la transaction "parent". De toute évidence, le domaine a été transféré à la gestion d'une autre personne.



Dans le cas général, il peut s'agir soit de la vente d'un domaine à un autre propriétaire qui n'est pas lié aux activités de la personne concernée, soit du transfert d'un domaine entre les comptes d'une personne. La deuxième option est la simplicité et le faible coût d'enregistrement d'un nouveau domaine, ainsi que le manque d'intérêt visible des organisations et des propriétaires de marques pour l'enregistrement de domaines dans la zone .bit. Nous n'avons pas pu trouver au moins une motivation peu justifiée pour l'achat d'un domaine, constatée dans une activité malveillante. Par conséquent, nous pensons que malgré la possibilité de transférer le domaine à une autre personne, les transactions avec des adresses réutilisables pour le retrait d'une pièce spéciale représentent un réarrangement des actifs entre plusieurs comptes contrôlés par un groupe.

Nous formulons les arguments ci-dessus sous la forme d'une règle heuristique, que nous appellerons changement commun:

, , , .

, , .

, , .

Le schéma d'utilisation de cette règle est illustré dans la figure. Flux gris - pièces ordinaires, vert - une pièce spéciale. Les guides seront toutes les pièces de la fin de la transaction en face de la pièce par laquelle nous sommes arrivés à cette transaction: toutes les sorties sont pour le mouvement vers le haut, et toutes les entrées sont pour le mouvement vers le bas.



Nous notons plusieurs caractéristiques de cette heuristique. Premièrement, bidirectionnel: il fonctionne à la fois pour le mouvement vers le haut, lorsque nous connaissons le propriétaire de l'entrée, et pour le mouvement vers le bas, lorsque nous connaissons le propriétaire d'une des pièces à la sortie.

Deuxièmement, la disponibilité facultative d'une pièce spéciale: malgré le fait qu'en son absence la transaction n'est pas liée à la mise à jour du domaine, le raisonnement logique donné ci-dessus concernant le propriétaire d'une pièce ordinaire reste valable.

Le pseudo-code pour tester une transaction pour la conformité avec la règle de changement commune ressemblerait à ceci:

 def common_change(tx): result = {"guiding_outs": [], "guiding_ins": []} if len(tx.outs.money) != 1: return {} addr = tx.outs.money[0].address first_tx = namecoin.tx.find_one({"out.id": addr}, sort=[("block", 1)]) if first_tx.id != tx.id: return {} else: result["guiding_outs"] = tx.outs.all result["guiding_ins"] = tx.ins.all return result 

Dépenses communes

L'heuristique considérée ci-dessus a une autre propriété importante, en plus de la bidirectionnalité. Changement commun - heuristique "sans mémoire"; le résultat de la vérification est déterminé uniquement par les caractéristiques de la transaction en question et ne dépend pas des résultats d'autres heuristiques et des données accumulées. Une telle heuristique est indispensable dans les premières itérations d'un parcours, pour le remplissage initial d'un ensemble de données. En revanche, il est facile de remarquer les limites de son application. Par exemple, elle se concentrera sur une transaction contenant deux sorties de trésorerie ou plus.

À titre d'exemple d'une telle transaction, considérez db4ff4082f39d0a501508706e627f26aa92712d27b4f633ded59917d201cfae5. Cette opération concerne les activités du groupe gérant le botnet Dimnie.



Nous avons effectué cette transaction via l'adresseMy7Ap3nH5f4X6Us2KiUWisd77wRpMG1MDYqui a été utilisé dans la transaction CC précédente comme adresse de connexion. Malgré le fait que son attitude envers la personne étudiée ne fait aucun doute, nous ne pouvons pas en dire autant (ainsi que le contraire) à propos des autres sorties et entrées. Il peut s'agir d'une redistribution de pièces entre les adresses de groupe, auquel cas toutes les adresses sont contrôlées par la personne qui nous intéresse. Ou est-ce, peut-être, une recharge à partir des adresses de l'un des échanges vendant des jetons Namecoin. Ou un transfert d'un autre membre du réseau qui n'est pas lié aux activités de la personne étudiée. Il est impossible de tirer une conclusion définitive sur les seuls attributs de cette transaction.

Considérez l'adresseN4XtLb7xpC4Zk72T8QcshKhTW17ZCyQ1j1à l'entrée de cette transaction. Cette adresse a déjà été utilisée précédemment («plus tôt» pour un mouvement à la baisse signifie «à l'avenir», «dans le sens de la croissance de la blockchain») à l'entrée d'une transaction CC 6bffc741eb66de074c09a380fb5e6bd13d4bd5205c36a76e3682674dba08461e, ce qui nous permet de considérer que cette adresse est gérée par la personne qui nous intéresse. Et comme, comme cela a déjà été montré, les clés de toutes les pièces à l'entrée de la transaction sont contrôlées par une seule personne (ce qui ne peut pas être dit sur les sorties), nous avons des raisons de croire que toutes les autres entrées appartiennent également au groupe qui nous intéresse.

La condition stricte des dépenses communes heuristiques semble très simple:

S'il est connu qu'au moins une des adresses à l'entrée de la transaction est contrôlée par une certaine personne, alors toutes les autres adresses aux entrées de cette transaction sont contrôlées par la même personne. Les pièces à ces entrées appartiennent à la même personne.

Comme vous pouvez le voir, cette heuristique n'a de sens que pour le mouvement vers le bas. Lorsque nous nous dirigeons vers la croissance de la blockchain, nous arrivons à la transaction à l'étude via l'un des intrants. Dans ce cas, la condition de règle est satisfaite automatiquement, mais ne dit rien sur les sorties de la transaction et ne vous permet pas de continuer à vous déplacer vers l'amont. En d'autres termes, il s'agit d'une heuristique unidirectionnelle.

La deuxième caractéristique de cette heuristique, qui mérite d'être soulignée, est qu'ici, nous avons d'abord utilisé les données accumulées à la suite de la vérification des transactions précédentes - une liste d'adresses gérées par la personne faisant l'objet de l'enquête. Pour cette raison, cette heuristique secondaire ne peut pas être utilisée pour un mouvement indépendant, sans aucune heuristique primaire qui ne dépend pas des résultats accumulés (comme un changement commun).

Le pseudo-code pour tester la conformité d'une transaction avec la règle de dépenses communes ressemblerait à ceci:

 def common_spending(tx): result = { "guiding_ins": [] } for input in tx.get_ins(): if input.address in known_addresses: return {"guiding_ins": tx.ins.all} return {} 

Adresse connue

La dernière heuristique que nous considérerons dans le cadre de cette section est la plus simple de toutes. Il s'agit d'une heuristique bidirectionnelle secondaire qui (puisqu'elle est bidirectionnelle) peut être utilisée à la fois pour un mouvement vers le haut et vers le bas. La formulation stricte de l'adresse heuristique connue pour le mouvement ascendant ressemble à ceci:

S'il est connu que l'adresse à l'entrée (sortie) de la transaction est contrôlée par une certaine personne, alors les pièces reçues à cette adresse (dépensées à partir de cette adresse) appartiennent à la même personne.

Bien que l'heuristique ressemble à un truisme franc, cette règle permet de trouver des branches et des intersections dans les flux de pièces et ajoute la connectivité à l'arbre de transaction. De plus, il vous permet de ne pas arrêter le mouvement sur les transactions qui ne relèvent pas d'autres heuristiques. Un exemple est la transaction du 7a35b9cb0a16b3eba92781be014555eaa4255bd17655bb00f2b3f42c3950ac69botnet Dimnie déjà mentionné.



L'ayant atteint dans un mouvement à la hausse, nous ne pourrons pas avancer avec l'aide d'un changement commun, car la sortie est plus d'une pièce ordinaire. En regardant une transaction, nous ne pouvons pas dire combien de pièces dans la sortie appartiennent à la même personne que la pièce dans l'entrée - les deux, une ou aucune. L'utilisation de l'heuristique d'adresse connue vous permet d'avancer du fait que l'adresseMwMdTb8WQvoRW9jEW5dHn9SkkCJTRn31wQa été impliqué dans la transaction CC cf7ac8986f9855246c6cf26df9a24aa5645cb9258bf787e034a33e75101ae1fcqui a créé le domaine rencontré plus tôt dans le mouvement en amont d/sectools.

Par souci d'exhaustivité, nous donnons le pseudocode de l'adresse heuristique connue:

 def known_address(tx): result = { "guiding_outs": [], "guiding_ins": [] } for output in tx.get_outs(): if output.address in known_addresses: result["guiding_outs"].append(output) for input in tx.get_ins(): if input.address in known_addresses: result["guiding_ins"].append(input) return result 

Donc, maintenant nous avons à la fois l'algorithme de contournement général et l'heuristique nécessaire pour se déplacer le long de la blockchain, afin que nous puissions les assembler pour obtenir un certain IOC de Namecoin.

C'est parti!

Nous allons passer par les transactions RTM avec le mouvement à la hausse et à la baisse, en commençant par 37d40bc2f3ca7415908dc9e276593b50d3120158cd540cb088246f2e2cf88b16. Au cours de l'avancée sur la blockchain, nous collecterons non seulement le CIO, mais aussi les transactions elles-mêmes qui satisfont l'heuristique. Les flux de pièces entre les transactions que nous visualisons à l'aide du graphique Sankey.

Le diagramme complet est trop grand pour être affiché dans le format de ce document, donc je n'en donnerai ici qu'une partie qui est nécessaire pour la suite de l'histoire.



Un flux de pièces ordinaires est surligné en gris. Les couleurs restantes correspondent aux flux de pièces spéciales. Une couleur distincte est sélectionnée pour chaque nom. Les jalons blancs correspondent aux transactions qui satisfont aux conditions heuristiques. Les jalons rouge vif sur la droite sont UTXO.

L'élément de graphique sur lequel je voudrais attirer l'attention est mis en évidence par un jalon bleu. Il s'agit d'une entrée pendante - une pièce qui a surgi à l'entrée d'une transaction que l'algorithme a transmise sur le mouvement ascendant, mais la transaction qui a créé cette pièce ne l'a pas rencontré.

Les entrées pendantes sont des signes que la structure à l'étude a des branches latérales qui ne sont pas connectées au tronc principal le long duquel l'algorithme se déplace. Dans le cas illustré, il s'agit d'un autre compte indépendant. Comme on peut le voir sur le diagramme, il commence à être utilisé pour payer les changements dans les domaines que nous connaissons déjà. De ce fait, nous pouvons conclure que ce compte est également contrôlé par la personne faisant l'objet de l'enquête. Pour obtenir le CIO associé aux opérations sur ce compte jusqu'à ce qu'il apparaisse sur le graphique, nous allons commencer un mouvement à la baisse distinct, en commençant dans une transaction avec une entrée pendante.

De même, dans un mouvement vers le bas, des sorties pendantes peuvent se produire. Pour chacun d'eux, nous lancerons un mouvement haussier distinct à partir de la transaction correspondante.

En plus des transactions du groupe qui contrôle le botnet RTM, nous avons également examiné les transactions des groupes qui contrôlent les botnets Shifu, Dimnie et GandCrab. En conséquence, 164 domaines enregistrés dans l'intérêt de ces groupes et 277 adresses IP associées à ces noms ont été trouvés. Au moment d'écrire ces lignes, sur les UTXO collectés appartenant à ces groupes, 39 pièces restaient en vigueur.

Les listes du CIO, ainsi que les adresses Namecoin sur lesquelles sont restées les pièces inutilisées des groupes, figurent à l'annexe A.

Conclusion

Les tests en conditions réelles représentent un défi pour presque toutes les technologies. Au milieu des années 2000, Wikipédia était devenu une source d'information si populaire et fiable qu'en changeant le texte des articles, il était devenu possible de contrôler l'opinion publique, de se lancer, de gagner de l'argent. Cette période de l'histoire du service est célèbre pour ses énormes guerres de révision - l'utilisation agressive du mécanisme de correction des articles et l'annulation des modifications par plusieurs parties belligérantes afin de gagner le différend sur le contenu de l'article. Les pages de Wikipédia se sont transformées en une foire internationale de vanité, où tout le monde voulait littéralement dire le dernier mot.

D'une part, ils ont commencé à mener la guerre des amendements, en fixant des règles spéciales qui permettent, en cas de litige, d'exclure temporairement la possibilité de modifier l'article - jusqu'à ce que les débatteurs de la section "Discussion" trouvent un libellé de compromis. D'autre part, la guerre des révisions a contraint Wikipedia à lancer un mécanisme dynamique de gestion des ressources des administrateurs, ce qui leur a permis d'être rapidement impliqués dans la résolution des conflits dans les zones les plus chaudes. De plus, l'encyclopédie a profité de l'attention du public qui s'est attirée sur les articles individuels pour attirer davantage de participants à la rédaction de ces articles et obtenir la couverture la plus correcte et complète d'un sujet particulier.

Namecoin, comme Wikipedia, peut-il grandir et faire face à son défi? Attendez et voyez.

Des tableaux PS avec des indicateurs de compromis sont disponibles sur GitHub .

Publié par Alexey Goncharov, PT Expert Security Center