Incidents associés
Les considérations de sécurité l'emportent sur toutes les autres considérations dans les logiciels en général et dans la blockchain en particulier. Si la sécurité échoue, rien d'autre n'a d'importance. La blockchain prouve que les transactions décentralisées et sans confiance fonctionnent, mais de nombreuses vulnérabilités de sécurité de la blockchain subsistent néanmoins.
Les exploits de sécurité existent au niveau de la conception et de l'architecture, au stade du codage et dans la phase opérationnelle. Et au cas où vous vous poseriez la question, oui, la blockchain peut être piratée.
Vulnérabilités de sécurité de la blockchain - D'ici à l'éternité
Les diamants sont éternels et les contrats intelligents existent aussi longtemps que la blockchain sur laquelle ils sont déployés continue d'être utilisée. Par conséquent, tous les bugs et vulnérabilités de sécurité de la blockchain vivent aussi longtemps que le contrat dure.
En règle générale, chaque blockchain fournit son propre langage de programmation pour mettre en œuvre des contrats intelligents. Regardons de plus près.
Langages des contrats intelligents
Les environnements de blockchain incluent leurs propres langages pour développer des contrats intelligents.
La plate-forme Ethereum, par exemple, inclut le langage Solidity pour écrire des contrats intelligents. Les créateurs ont conçu Solidity comme un langage complet de Turing.
Un langage complet de Turing permet essentiellement au programmeur d'implémenter tout ce dont le système sous-jacent est capable. Par conséquent, cela donne aux programmeurs des capacités telles que l'implémentation de boucles dans le code, ce qui peut potentiellement entraîner des vulnérabilités de sécurité de la blockchain.
Complétude de Turing
Les langages complets de Turing contiennent de la complexité par nature, et la complexité invite les bogues et les vulnérabilités.
Le réseau Bitcoin dispose également d'un langage de programmation qu'il appelle Script. Le script n'est volontairement pas complet pour améliorer la sécurité.
Moins il y a d'options données à un programmeur, moins il est probable que les vulnérabilités de sécurité de la blockchain pénètrent dans le système.
Pour minimiser le risque de libérer du code défectueux dans la nature, les programmeurs doivent comprendre les pièges et les anti-modèles courants inhérents à la programmation de contrats intelligents. (Les anti-modèles représentent de mauvaises pratiques de programmation).
Le piratage DAO : le problème de la réentrance
Le problème de réentrance est probablement le plus élevé parmi les programmeurs de vulnérabilités de sécurité de la blockchain codés dans des contrats intelligents. La réentrance draine un compte par le biais de plusieurs dépenses pour la même transaction. Le cas d'utilisation du traitement des remboursements se prête à cet exploit, mais cette faille affecte tout type de transaction si elle n'est pas traitée au stade de la conception et du codage.
Dans l'une des attaques de crypto-monnaie les plus infâmes à ce jour, les pirates du DAO ont exploité la réentrance. Aucun chef d'organisation n'a dicté comment gérer le DAO (ou organisation autonome décentralisée), et le DAO a proposé de donner aux utilisateurs la possibilité de voter sur des projets dans lesquels investir.
Il a levé plus de 150 millions de dollars de financement au cours de son premier mois. Le 17 juin 2016, des pirates ont drainé 50 millions de dollars de l'organisation via la faille de réentrance. Le hard fork d'Ethereum Classic (ETC) à Ethereum (ETH) a abouti à un effort pour résoudre les problèmes créés par ce piratage.
Anti-Pattern vulnérable à la réentrance
Une logique réentrante vulnérable pour le code ressemble à ceci :
fonction pour traiter un paiement () {
(1) vérifier la validité de la transaction, le destinataire et le solde du compte ;
(2) traiter la transaction ;
(3) mettre à jour l'état du système pour montrer que la transaction a été traitée ;
}
À première vue, la logique semble correcte et complète, mais le défaut réside dans l'ordre de faire l'étape 2 avant l'étape 3.
Pendant que le premier appel à la fonction continue de traiter l'étape 2, un autre appel pour la même transaction peut entrer dans la fonction. Étant donné que les informations d'état restent dans leur état initial et n'ont pas encore été traitées à l'étape 3, le deuxième appel est considéré comme une transaction valide à traiter.
Par conséquent, le système dépense de l'argent pour la même obligation une seconde fois. Les pirates envoient plusieurs transactions à la fonction avant que l'état ne soit défini correctement.
Remède contre la réentrance
Cette modification de l'algorithme corrige le problème ci-dessus :
fonction pour traiter un paiement () {
(1) vérifier la validité de la transaction, le destinataire et le solde du compte ;
(2) mettre à jour l'état du système pour montrer que la transaction a été traitée ;
(3) traiter la transaction ;
}
Le code doit tenir compte de toute la gestion des exceptions nécessaires, ainsi que de toutes les dépendances logiques.
Débordement
Le débordement est une autre faille de sécurité courante dont les programmeurs doivent être conscients.
Certains langages de programmation fournissent un typage fort et d'autres un typage faible. Les langages fortement typés refusent d'autoriser les programmeurs à affecter des données de chaîne à une variable numérique, par exemple, et les langages faiblement typés autorisent de telles actions.
Les langages fortement typés appliquent des restrictions de plage. Si un tableau contient dix éléments, les programmeurs ne peuvent pas tenter d'accéder au onzième élément. Les langages faiblement typés permettent un tel comportement, mais des plantages en résultent. Si la valeur maximale autorisée pour une variable est de 99 et que vous lui attribuez une valeur de 100, regardez-la planter lorsque vous l'exécutez !
Par conséquent, le débordement est un exploit utilisé par les pirates. Si un