La violation de sécurité se termine bien pour SpankChain

Le pirate qui a volé 165 ETH (32 000 $) à SpankChain a accepté de rendre leurs gains mal acquis. Le Ethereum , basée sur la plateforme de divertissement pour adultes, l'a confirmé dans une série de tweets aujourd'hui.

https://twitter.com/SpankChain/status/1050533900001243136

Voici, dans son intégralité, son billet Medium sur la brèche de sécurité : « A 18h HNP samedi, un attaquant inconnu a drainé 165,38 ETH (~ 38 000 $) de notre contrat intelligent de canal de paiement, ce qui a également entraîné l'immobilisation de $4,000 de BOOTY sur le contrat. Sur les ETH/BOOTY volés/immobilisés, 34,99 ETH (~ 8 000 $) et 1271,88 BOOTY appartiennent aux utilisateurs (~ 9 300 $ au total), et le reste appartenait à SpankChain.

Malheureusement, comme nous étions au milieu d'enquêter sur d'autres bogues de contrat intelligent, nous ne nous sommes pas rendu compte que le hack avait eu lieu avant 19h00 HNP dimanche, à ce moment-là nous avons pris Spank.Live hors ligne pour empêcher des fonds supplémentaires d'être déposés dans le contrat intelligent canaux de paiement.

Notre priorité immédiate a été de fournir des remboursements complets à tous les utilisateurs qui ont perdu des fonds. Nous préparons un aérodrome ETH pour couvrir la totalité des 9 300 $ de ETH et BOOTY appartenant aux utilisateurs. Les fonds seront envoyés directement sur les comptes SpankPay des utilisateurs et seront disponibles dès que nous redémarrons Spank.Live.

Notre plan est de maintenir le camping en bas au cours des 2-3 prochains jours (mais peut-être plus) pendant que nous :

1. Redéployez le contrat intelligent de canal de paiement avec un correctif pour éviter tout piratage futur
2. Mettez à jour Spank.Live pour utiliser le nouveau contrat de canal de paiement
3. Airdrop ETH équivalent à 100 % de l'ETH+BOOTY perdu par chaque utilisateur sur leurs comptes SpankPay
4. Correction des bogues que nous travaillions à l'origine autour de la mise à niveau BOOTY

Au moment où nous redémarrons Spank.Live, tous les téléspectateurs et les interprètes auront 100 % de la valeur totale de BOOTY+ETH qu'ils avaient dans leur SpankPay aéroporté à leurs adresses SpankPay actuelles, donc les utilisateurs n'ont pas besoin de faire quoi que ce soit.

Le site continuera à fonctionner exactement comme il l'était auparavant, à une seule exception près : en raison des 4 000 BOOTY actuellement immobilisés, nous réduirons temporairement la limite BOOTY pour chaque spectateur à 10 BOOTY. Cela signifie que les téléspectateurs ne pourront donner un pourboire qu'à 10 BOOTY à la fois, et en dépensant les 10 BOOTY, ils rechargeront automatiquement leur 10 BOOTY avec n'importe quel ETH supplémentaire qu'ils auront déposé, jusqu'à ce qu'ils épuisent complètement leur solde ETH.

Au cours des prochains jours, notre équipe prépare une enquête approfondie sur l'attaque.

Voici ce que nous savons jusqu'à présent :

Bref, l'attaque a capitalisé sur un bug de « réentrance », un peu comme celui exploité dans The DAO. L'attaquant a créé un contrat malveillant se déguisant en jeton ERC20, où la fonction de « transfert » a rappelé plusieurs fois dans le contrat de canal de paiement, drainant des ETH à chaque fois.

Le contrat malveillant a d'abord appelé CreateChannel pour configurer le canal, puis LCopentimeout à plusieurs reprises par réentrance. Le LCopentimeout est là pour permettre aux utilisateurs de quitter rapidement les canaux de paiement qui n'ont pas encore été rejoint par la contrepartie.

LCopentimeOut transfère à l'utilisateur son solde initial de dépôt ETH et son solde de dépôt jeton, tous deux définis initialement dans la fonction CreateChannel. De façon critique, la fonction LCopentimeOut supprime uniquement les données de canal sur chaîne (ce qui réduit à zéro les soldes de canal) après la fonction de transfert de jeton. Cela permet à la fonction de transfert du contrat malveillant d'appeler LCopentimeOut dans une boucle, chaque fois que l'attaquant ETH équivaut à son équilibre de canal.

Contrat de canal de paiement :   https://etherscan.io/address/0xf91546835f756da0c10cfa0cda95b15577b84aa7#code

Adresse de l'attaquant :   https://etherscan.io/address/0xcf267ea3f1ebae3c29fea0a3253f94f3122c2199

Txs internes (réentrance) à partir du compte de l'attaquant :   https://etherscan.io/address/0xcf267ea3f1ebae3c29fea0a3253f94f3122c2199#internaltx

Contrat malveillant de l'attaquant :   https://etherscan.io/address/0xc5918a927c4fb83fe99e30d6f66707f4b396900e

Txs internes (réentrance) du contrat malveillant de l'attaquant :   https://etherscan.io/address/0xc5918a927c4fb83fe99e30d6f66707f4b396900e#internaltx

Nous avons décidé de renoncer à un audit de sécurité pour le contrat de canal de paiement. Nous avons fait réaliser à Zeppelin une vérification qui a coûté 17 000 $ pour l'ancienne bibliothèque des canaux de paiement unidirectionnels. Nous avons estimé que cela était très coûteux, étant donné que le plus grand nombre de fonds jamais détenus dans le cadre de ce contrat n'atteignait que $17,000 au total.

Pour ce contrat beaucoup plus sophistiqué de canal de paiement non gardien, nous avons été cités entre 30 000 $ et 50 000 $ pour des vérifications de sécurité, mais en tenant compte à la fois de la valeur de perception et du coût d'opportunité du temps passé à réagir au piratage, cela aurait valu la peine. Cela est dû à notre processus de développement agile, au fait que le site est en version bêta, et à la rapidité avec laquelle nous avons itéré et redéployé les contrats (dont nous mettons en œuvre toutes les 2 à 3 semaines). Cela a identifié un problème dans notre processus de développement et de déploiement, et nous apporterons les changements appropriés pour nous assurer que cela ne se reproduira pas, tout en continuant d'innover au rythme que vous connaissez tous.

À mesure que nous progresserons et que nous progresserons, nous renforcerons nos pratiques de sécurité et nous veillerons à obtenir de multiples audits internes pour tout code de contrat intelligent que nous publions, ainsi qu'au moins un audit externe professionnel. »