Comment faire une attaque à 51%

[darosior]

Salut,

Dans le cadre de meetups que j'organise à l'INSA Lyon (nommés "Shiba to lion"), j'ai fait une attaque à 51% sur le réseau Insacoin. Etant donné que c'est un sujet qui a beaucoup buzzé et qui est très mal compris, j'en ai fait un article décrivant ce que c'est vraiment et comment en faire une (en théorie, puis en pratique à-travers l'exemple de ce que j'ai fait). L'article est en anglais (à la fois parcequ'un anglais m'a demandé un tuto et parceque je voulais toucher un audience plus large), mais je reste disponible sur ce thread pour détailler en français certaines parties si besoin et répondre aux questions.
Lien vers l'article : https://medium.com/@darosior/how-to-perform-a-51-attack-f8f739925110

[TITI45555]

COMBIEN cela t'a t-il couté ?


En heures ? Journée ?

COMBIEN DE ROI SI REVENTE ILLEGALE ?

 

[yogg]

Intéressant.
Qu'a tu réussi à faire, avec 51% de la puissance de calcul d'un coin ?

A tu réussi à miner des blocks du "passé" ?

Je n'ai pas vu ce que tu as expérimenté avec 51% de la puissance de calcul du coin en question.
J'me serait amusé à refuser l'inclusion de certaines transactions. (Mais juste une fois, pour tester et voir si ça marche  #noevil)

[darosior]

COMBIEN cela t'a t-il couté ?


En heures ? Journée ?

COMBIEN DE ROI SI REVENTE ILLEGALE ?

 

Coût :
- en électricité : de quoi faire tourner un L3 à balle pendant ~48h (et c'etait pas moi c'etait un autre membre de Crypto Lyon)
- en temps : beaucoup parceque c'était pas mal d'experimentation, je n'ai jamais vu de how-to pour faire cette attaque (c'est d'ailleurs la raison pour laquelle j'en ai fait un). Pour être tout à fait honnête je n'étais même pas sûr d'y arriver.

ROI :
De l'expérience. Les insacoins n'ont pas de valeur et j'ai créé ce réseau juste pour de l'expérimentation.

Intéressant.
Qu'a tu réussi à faire, avec 51% de la puissance de calcul d'un coin ?

A tu réussi à miner des blocks du "passé" ?

Je n'ai pas vu ce que tu as expérimenté avec 51% de la puissance de calcul du coin en question.
J'me serait amusé à refuser l'inclusion de certaines transactions. (Mais juste une fois, pour tester et voir si ça marche  #noevil)

J'ai reminé la totalité des blocs depuis le genesis. Ça marche j'aurais juste pu refuser de les accepter dans ma mempool, mais bon y a pas beaucoup de transactions sur Insacoin, juste quand on fait des meetups x).

[TheWolf666]

Combien de full nodes tu as attaqué, et donc combien d'instances ont été nécessaire pour obtenir les 51%

[yogg]

Combien de full nodes tu as attaqué, et donc combien d'instances ont été nécessaire pour obtenir les 51%

Euh...
J'ai du mal à saisir le rapport entre le nombre de nodes et les 51% ?

Le nombre de full nodes, c'est juste le nombre de PC avec le coin, qui ont la blockchain.
L'attaque à 51% s'en prend elle au consensus de preuve de travail. Les noeuds du réseau "suivent" ce que les mineurs trouvent et leur donnent.

[TheWolf666]

Donc si tu as 1 seule instance full node, que tu mines sur un stratum (on ne peut plus solo miner avec 0.18)
Si le réseau total a un hashrate de 10 T/s et que tu mines avec 6 T/s tu peux inclure dans ton bloc des transaction factices... si ta chaine est plus longue de COINBASE_MATURITY transactions.
Dans ce cas, ta chaine sera retenue comme étant la plus longue et remplacera la chaine qui se trouve sur tous les full node.
Ainsi toutes les transactions peuvent être modifiée?

Combien de full nodes tu as attaqué, et donc combien d'instances ont été nécessaire pour obtenir les 51%

Euh...
J'ai du mal à saisir le rapport entre le nombre de nodes et les 51% ?

Le nombre de full nodes, c'est juste le nombre de PC avec le coin, qui ont la blockchain.
L'attaque à 51% s'en prend elle au consensus de preuve de travail. Les noeuds du réseau "suivent" ce que les mineurs trouvent et leur donnent.

[yogg]

Donc si tu as 1 seule instance full node, que tu mines sur un stratum (on ne peut plus solo miner avec 0.18)
Si le réseau total a un hashrate de 10 T/s et que tu mines avec 6 T/s tu peux inclure dans ton bloc des transaction factices... si ta chaine est plus longue de COINBASE_MATURITY transactions.
Dans ce cas, ta chaine sera retenue comme étant la plus longue et remplacera la chaine qui se trouve sur tous les full node.
Ainsi toutes les transactions peuvent être modifiée?

Une seule full node, c'est pas un consensus. 
Je pense que tu peux pas raisonner comme ça.

Effectivement, localement, tu va produire une chaîne qui est tout aussi valide que celle d'origine, et puis le fait que la chaîne avec le + de PoW cumulée devient "la" chaîne de référence pour les clients du coin, ça va se produire comme toi tu le dis.

Maintenant, il faut pas oublier que bitcoin doit composer avec le reste des noeuds du réseau et les mineurs. Hah, et les devs. ^^

Si il était aussi simple de faire ça que ce que tu as expliqué dans ton exemple, il n'aurait pas un tel succès et c'est d'ailleurs là sa principale force.
La preuve de travail.

[TheWolf666]

En fait je suis d'accord avec toi, je posais la question a l'OP qui postait a l'origine.

Ce scenario ne peut se produire, pour plusieurs raisons, mais l'une d'elle sont les checkpoint. Les blockchains qui ont des problèmes d'attaques a 51% sont celles qui ne sont pas maintenues.
Il y a 2 types de checkpoints qui sont codés dans les wallets et donc qui vérifient que les transactions a certaines hauteur de block sont valide, genre hash du block x = y
Si les hash divergent le consensus est rejeté.
Donc pour voler one blockchain en totalité comme le fait l'OP dans son example, il faut aussi faire un fork du wallet et que + 50% des nodes soient des wallets forkés ce qui est vraiment difficile.

En ce qui concerne une attaque a 51%, il est possible d’insérer dans la blockchain un block miné qui ne bénéficie qu'a celui qui a fait l'attaque. Mais cela ne met pas la blockchain en peril, cela vole juste l'argent des mineurs en quelque sorte mais cela a un prix, le hashing nécessaire est très élevé, et donc cela coûte très cher a faire.

Ce genre de problèmes sont intéressant, j'ai fais 2 blockchains, et toute information utile est bienvenue, vue que mes blockchains sont toute jeune et avec un travail peu élevé...

Hier par exemple j'ai eut une attaque a 51% sur notre pool de minage.

Donc si tu as 1 seule instance full node, que tu mines sur un stratum (on ne peut plus solo miner avec 0.18)
Si le réseau total a un hashrate de 10 T/s et que tu mines avec 6 T/s tu peux inclure dans ton bloc des transaction factices... si ta chaine est plus longue de COINBASE_MATURITY transactions.
Dans ce cas, ta chaine sera retenue comme étant la plus longue et remplacera la chaine qui se trouve sur tous les full node.
Ainsi toutes les transactions peuvent être modifiée?

Une seule full node, c'est pas un consensus. 
Je pense que tu peux pas raisonner comme ça.

Effectivement, localement, tu va produire une chaîne qui est tout aussi valide que celle d'origine, et puis le fait que la chaîne avec le + de PoW cumulée devient "la" chaîne de référence pour les clients du coin, ça va se produire comme toi tu le dis.

Maintenant, il faut pas oublier que bitcoin doit composer avec le reste des noeuds du réseau et les mineurs. Hah, et les devs. ^^

Si il était aussi simple de faire ça que ce que tu as expliqué dans ton exemple, il n'aurait pas un tel succès et c'est d'ailleurs là sa principale force.
La preuve de travail.

[darosior]

En fait je suis d'accord avec toi, je posais la question a l'OP qui postait a l'origine.

Ce scenario ne peut se produire, pour plusieurs raisons, mais l'une d'elle sont les checkpoint. Les blockchains qui ont des problèmes d'attaques a 51% sont celles qui ne sont pas maintenues.
Il y a 2 types de checkpoints qui sont codés dans les wallets et donc qui vérifient que les transactions a certaines hauteur de block sont valide, genre hash du block x = y
Si les hash divergent le consensus est rejeté.
Donc pour voler one blockchain en totalité comme le fait l'OP dans son example, il faut aussi faire un fork du wallet et que + 50% des nodes soient des wallets forkés ce qui est vraiment difficile.

En ce qui concerne une attaque a 51%, il est possible d’insérer dans la blockchain un block miné qui ne bénéficie qu'a celui qui a fait l'attaque. Mais cela ne met pas la blockchain en peril, cela vole juste l'argent des mineurs en quelque sorte mais cela a un prix, le hashing nécessaire est très élevé, et donc cela coûte très cher a faire.

Ce genre de problèmes sont intéressant, j'ai fais 2 blockchains, et toute information utile est bienvenue, vue que mes blockchains sont toute jeune et avec un travail peu élevé...

Hier par exemple j'ai eut une attaque a 51% sur notre pool de minage.

Donc si tu as 1 seule instance full node, que tu mines sur un stratum (on ne peut plus solo miner avec 0.18)
Si le réseau total a un hashrate de 10 T/s et que tu mines avec 6 T/s tu peux inclure dans ton bloc des transaction factices... si ta chaine est plus longue de COINBASE_MATURITY transactions.
Dans ce cas, ta chaine sera retenue comme étant la plus longue et remplacera la chaine qui se trouve sur tous les full node.
Ainsi toutes les transactions peuvent être modifiée?

Une seule full node, c'est pas un consensus.  
Je pense que tu peux pas raisonner comme ça.

Effectivement, localement, tu va produire une chaîne qui est tout aussi valide que celle d'origine, et puis le fait que la chaîne avec le + de PoW cumulée devient "la" chaîne de référence pour les clients du coin, ça va se produire comme toi tu le dis.

Maintenant, il faut pas oublier que bitcoin doit composer avec le reste des noeuds du réseau et les mineurs. Hah, et les devs. ^^

Si il était aussi simple de faire ça que ce que tu as expliqué dans ton exemple, il n'aurait pas un tel succès et c'est d'ailleurs là sa principale force.
La preuve de travail.

Salut,

les checkpoints ont été ajoutés puis retirés, seuls certains forks pas à jour en ont encore. Ce système (qui reposait trop sur la confiance en les core devs) a été abandonné au profit de `assumevalid`, qui offre le même avantage que les checkpoints (à savoir ne pas vérifier les signatures précédent un certain bloc) mais n'a pas le même postulat de confiance que les checkpoints : si le bloc n'est pas dans la block chain, les signatures seront toutes vérifiées au lieu de la refuser.

Combien de full nodes tu as attaqué, et donc combien d'instances ont été nécessaire pour obtenir les 51%

Il devait y avoir environ 4-5 node sur ce réseau de test. De toutes façons même s'il y en avait plus, la nouvelle chain aurait juste mis plus de temps à se propager (et à être vérifiée) : une seule instance est nécessaire, seule la puissance de calcul compte.

Edit modo : fusion double post
Archive

[yogg]

Merci pour tes précisions.
C'est très intéressant !

Combien de full nodes tu as attaqué, et donc combien d'instances ont été nécessaire pour obtenir les 51%

Il devait y avoir environ 4-5 node sur ce réseau de test. De toutes façons même s'il y en avait plus, la nouvelle chain aurait juste mis plus de temps à se propager (et à être vérifiée) : une seule instance est nécessaire, seule la puissance de calcul compte.

Une est tout à fait indispensable, mais je pense que pour constater des forks, il aurait fallu plusieurs noeuds et voir sur quelle chain est quel noeud après tes tentatives.
Avec un seul noeud, tu sera toujours sur "une branche" de la chain en cas de forks. Tu sauras pas si il y'a réellement eu un fork ou pas.

Après je me trompe peut être et quelque chose m'échappe 

[Saint-loup]

Merci pour tes précisions.
C'est très intéressant !

Combien de full nodes tu as attaqué, et donc combien d'instances ont été nécessaire pour obtenir les 51%

Il devait y avoir environ 4-5 node sur ce réseau de test. De toutes façons même s'il y en avait plus, la nouvelle chain aurait juste mis plus de temps à se propager (et à être vérifiée) : une seule instance est nécessaire, seule la puissance de calcul compte.

Une est tout à fait indispensable, mais je pense que pour constater des forks, il aurait fallu plusieurs noeuds et voir sur quelle chain est quel noeud après tes tentatives.
Avec un seul noeud, tu sera toujours sur "une branche" de la chain en cas de forks. Tu sauras pas si il y'a réellement eu un fork ou pas.

Après je me trompe peut être et quelque chose m'échappe  

C'est là que meuh nous manque, il aurait certainement une astuce à nous donner .... 
 mais sinon avec ce genre de commande, on doit pouvoir voir normalement si on est sur la même chaîne que les autres nodes du réseau non?

https://bitcoin.org/en/developer-reference#getpeerinfo

[yogg]

C'est là que meuh nous manque, il aurait certainement une astuce à nous donner ....
 mais sinon avec ce genre de commande, on doit pouvoir voir normalement si on est sur la même chaîne que les autres nodes du réseau non?

https://bitcoin.org/en/developer-reference#getpeerinfo

Quelque chose avec getpeerinfo, ça pourrait le faire.

Sinon avoir plusieurs full nodes, a différents endroits dans le monde.
Au début, tu t'arranges pour que tout soit sync. Ce process peut être automatisé en comparant les différentes block height et hash (identifiant) des précédents blocks.

Dès que ça ne matche plus quelque part, c'est qu'il y'a un fork.

C'est comme ça que je le ferais. Je vois pas trop comment faire autrement pour te rendre compte d'un fork.
En tout les cas, avec un seul nœud, ça me paraît difficile.

[asche]

Dès que ça ne matche plus quelque part, c'est qu'il y'a un fork.

C'est comme ça que je le ferais. Je vois pas trop comment faire autrement pour te rendre compte d'un fork.
En tout les cas, avec un seul nœud, ça me paraît difficile.

Au lieu de mesurer la variance sur le sync tu peux la mesurer sur le hashrate. C'est à mon avis plus facile à mesurer, les soucis de sync peuvent arriver assez fréquemment. Ca demanderait pas mal d'intelligence/d'analyse d'analyser pas mal de bugs/hangs par rapport à la simple puissance de minage.

[TheWolf666]

Dès que ça ne matche plus quelque part, c'est qu'il y'a un fork.

C'est comme ça que je le ferais. Je vois pas trop comment faire autrement pour te rendre compte d'un fork.
En tout les cas, avec un seul nœud, ça me paraît difficile.

Au lieu de mesurer la variance sur le sync tu peux la mesurer sur le hashrate. C'est à mon avis plus facile à mesurer, les soucis de sync peuvent arriver assez fréquemment. Ca demanderait pas mal d'intelligence/d'analyse d'analyser pas mal de bugs/hangs par rapport à la simple puissance de minage.

La variance sur le hashrate est plus efficace en effet. Une tentative d'attaque a 51% devrait pouvoir être détectée par une hausse soudaine du hashrate de plusieurs nodes. A moins que l'attaquant utilise un grand nombre de nodes, les nodes des attaquants devraient être facile a identifier car ils devraient centraliser un hashrate extrêmement élevé.
Le consensus sur une transaction pourrait etre invalidé dans le cas d'un hashrate trop elevé.

Cependant, comme le hashrate d'un node est transmit par le logiciel de minage a travers le stratum du pool, c'est facile de masquer la vrai valeur du hashrate en modifiant le logiciel de minage pour qu'il envoie des données bidon, ou en utilisant son propre pool avec un stratum modifié.

[yogg]

Dès que ça ne matche plus quelque part, c'est qu'il y'a un fork.

C'est comme ça que je le ferais. Je vois pas trop comment faire autrement pour te rendre compte d'un fork.
En tout les cas, avec un seul nœud, ça me paraît difficile.

Au lieu de mesurer la variance sur le sync tu peux la mesurer sur le hashrate. C'est à mon avis plus facile à mesurer, les soucis de sync peuvent arriver assez fréquemment. Ca demanderait pas mal d'intelligence/d'analyse d'analyser pas mal de bugs/hangs par rapport à la simple puissance de minage.

La variance sur le hashrate est plus efficace en effet. Une tentative d'attaque a 51% devrait pouvoir être détectée par une hausse soudaine du hashrate de plusieurs nodes. A moins que l'attaquant utilise un grand nombre de nodes, les nodes des attaquants devraient être facile a identifier car ils devraient centraliser un hashrate extrêmement élevé.
Le consensus sur une transaction pourrait etre invalidé dans le cas d'un hashrate trop elevé.

Cependant, comme le hashrate d'un node est transmit par le logiciel de minage a travers le stratum du pool, c'est facile de masquer la vrai valeur du hashrate en modifiant le logiciel de minage pour qu'il envoie des données bidon, ou en utilisant son propre pool avec un stratum modifié.

Oui, peut être plus facile, mais ce n'est pas fiable.
Vous pouvez regarder ce que fait BitMEX sur son site de monitoring des forks :
https://forkmonitor.info/nodes/btc

Ils ont des clients différents, et ils comparent les blocks reçus par les différents clients.

Comme l'a dit TheWolf, la hashrate peut être fausse, et comparer les blocks est plus sur.

[darosior]

Salut, je reviens répondre encore avec un mois de retard... Mieux vaut tard que jamais ! :-)

Merci pour tes précisions.
C'est très intéressant !

Combien de full nodes tu as attaqué, et donc combien d'instances ont été nécessaire pour obtenir les 51%

Il devait y avoir environ 4-5 node sur ce réseau de test. De toutes façons même s'il y en avait plus, la nouvelle chain aurait juste mis plus de temps à se propager (et à être vérifiée) : une seule instance est nécessaire, seule la puissance de calcul compte.

Une est tout à fait indispensable, mais je pense que pour constater des forks, il aurait fallu plusieurs noeuds et voir sur quelle chain est quel noeud après tes tentatives.
Avec un seul noeud, tu sera toujours sur "une branche" de la chain en cas de forks. Tu sauras pas si il y'a réellement eu un fork ou pas.

Après je me trompe peut être et quelque chose m'échappe 

Oui quelquechose t'échappe mais ce qui t'échappe m'échappe :-).

Je ne comprends pas pourquoi tu pense qu'il faut plusieurs noeuds. Chaque noeud faisait tourner la même version du client : ils agissent donc tous de la même manière, selon les mêmes règles de consensus pré-définies et c'est la raison pour laquelle l'attaque fonctionne.

Concernant le "savoir si il y a eu un fork", en pratique bitcoin-core (dont a été forké le client que j'utilisais) avertira (dans les logs) si il y a une réorg de la block chain : ça arrive régulièrement.

Merci pour tes précisions.
C'est très intéressant !

Combien de full nodes tu as attaqué, et donc combien d'instances ont été nécessaire pour obtenir les 51%

Il devait y avoir environ 4-5 node sur ce réseau de test. De toutes façons même s'il y en avait plus, la nouvelle chain aurait juste mis plus de temps à se propager (et à être vérifiée) : une seule instance est nécessaire, seule la puissance de calcul compte.

Une est tout à fait indispensable, mais je pense que pour constater des forks, il aurait fallu plusieurs noeuds et voir sur quelle chain est quel noeud après tes tentatives.
Avec un seul noeud, tu sera toujours sur "une branche" de la chain en cas de forks. Tu sauras pas si il y'a réellement eu un fork ou pas.

Après je me trompe peut être et quelque chose m'échappe 

C'est là que meuh nous manque, il aurait certainement une astuce à nous donner ....
 mais sinon avec ce genre de commande, on doit pouvoir voir normalement si on est sur la même chaîne que les autres nodes du réseau non?

https://bitcoin.org/en/developer-reference#getpeerinfo

Non, `getpeerinfo` ne renverra toujours que la version actuelle et ne comparera pas avec le passé. Par contre si tu as un service qui tourne à côté de ton nom et qui "poll" (qui fait des requêtes toutes les `n` secondes)  `bitcoin-cli getblockhash $(bitcoin-cli getblockcount)` pourrait facilement se rendre compte que le hash a changé pour la même hauteur de la chain. Le plus simple serait juste que ce service regarde les logs.

En tout les cas, avec un seul nœud, ça me paraît difficile.

Effectivement et de toute façon avec un seul noeud il n'y a pas de réseau donc....

Dès que ça ne matche plus quelque part, c'est qu'il y'a un fork.

C'est comme ça que je le ferais. Je vois pas trop comment faire autrement pour te rendre compte d'un fork.
En tout les cas, avec un seul nœud, ça me paraît difficile.

Au lieu de mesurer la variance sur le sync tu peux la mesurer sur le hashrate. C'est à mon avis plus facile à mesurer, les soucis de sync peuvent arriver assez fréquemment. Ca demanderait pas mal d'intelligence/d'analyse d'analyser pas mal de bugs/hangs par rapport à la simple puissance de minage.

Oui, c'est comme ça que c'est fait en pratique pour "prévoir" (en partant déjà de l'hypothèse que les machines qui agissent mal étaient déjà honnêtes avant...) : regarder si un hash de bloc a changé à une hauteur donnée de la chain c'est "après coup".

Dès que ça ne matche plus quelque part, c'est qu'il y'a un fork.
La variance sur le hashrate est plus efficace en effet. Une tentative d'attaque a 51% devrait pouvoir être détectée par une hausse soudaine du hashrate de plusieurs nodes. A moins que l'attaquant utilise un grand nombre de nodes, les nodes des attaquants devraient être facile a identifier car ils devraient centraliser un hashrate extrêmement élevé.

Cependant, comme le hashrate d'un node est transmit par le logiciel de minage a travers le stratum du pool, c'est facile de masquer la vrai valeur du hashrate en modifiant le logiciel de minage pour qu'il envoie des données bidon, ou en utilisant son propre pool avec un stratum modifié.

Non c'est justement l'inverse : c'est l'absence soudaine d'une grande partie du hashrate sur la main chain. On ne peut pas se rendre compte du hashrate si on n'a pas connaissance de la chain alternative.

Concernant le masquage du hashrate : il n'est possible que lorsque l'on n'a pas encore publié les blocs, si tu publie un bloc tu informe (statistiquement) sur ton hashrate. Dans le cas d'une attaque à "51" le hashrate est masqué avant la publication d'une chain avec une énorme preuve de travail. A ce moment c'est déjà trop tard.