Au cours de l’année écoulée, la Fondation Ethereum a considérablement élargi son équipe de chercheurs et d’ingénieurs dédiés à la sécurité. Les membres ont rejoint une variété d’horizons allant de la cryptographie, de l’architecture de sécurité, de la gestion des risques, du développement d’exploits ainsi que d’avoir travaillé dans des équipes rouges et bleues. Les membres viennent de différents domaines et ont travaillé sur la sécurisation de tout, des services Internet dont nous dépendons tous chaque jour, aux systèmes de santé nationaux et aux banques centrales.
À l’approche de The Merge, l’équipe consacre beaucoup d’efforts à l’analyse, à l’audit et à la recherche de la couche Consensus de diverses manières, ainsi que de The Merge lui-même. Un échantillon de l’œuvre se trouve ci-dessous.
- 1 Audits de mise en œuvre client 🛡️
- 2 Fuzzing 🦾
- 3 Simulation et test au niveau du réseau 🕸️
- 4 Recherche sur la diversité des clients et des infrastructures 🔬
- 5 Programme Bug Bounty 🐛
- 6 Sécurité opérationnelle 🔒
- 7 Surveillance du réseau Ethereum 🩺
- 8 Analyse des menaces 🩻
- 9 Groupe de sécurité client Ethereum 🤝
- 10 Réponse aux incidents 🚒
- 11 Merci et impliquez-vous 💪
Audits de mise en œuvre client 🛡️
Les membres de l’équipe auditent les différentes implémentations des clients avec une variété d’outils et de techniques.
Analyses automatisées 🤖
Les analyses automatisées des bases de code visent à détecter les fruits à portée de main tels que les vulnérabilités de dépendance (et les vulnérabilités potentielles) ou les zones d’amélioration du code. Certains des outils utilisés pour l’analyse statique sont CodeQL, semgrep, ErrorProne et Nosy.
Comme il existe de nombreuses langues différentes utilisées entre les clients, nous utilisons des scanners génériques et spécifiques à la langue pour les bases de code et les images. Ceux-ci sont interconnectés via un système qui analyse et rapporte les nouvelles découvertes de tous les outils dans les canaux pertinents. Ces analyses automatisées permettent d’obtenir rapidement des rapports sur les problèmes que les adversaires potentiels sont susceptibles de trouver facilement, augmentant ainsi les chances de résoudre les problèmes avant qu’ils ne puissent être exploités.
Audits manuels 🔨
Les audits manuels des composants de la pile sont également une technique importante. Ces efforts incluent l’audit des dépendances partagées critiques (BLS), libp2p, de nouvelles fonctionnalités dans hardforks (par exemple, les comités de synchronisation dans Altair), un audit approfondi d’une implémentation client spécifique ou l’audit des L2 et des ponts.
De plus, lorsque des vulnérabilités sont signalées via le Programme de primes de bogues Ethereumles chercheurs peuvent recouper les problèmes avec tous les clients pour voir s’ils sont également concernés par le problème signalé.
Audits tiers 🧑🔧
Parfois, des sociétés tierces sont engagées pour auditer divers composants. Les audits tiers sont utilisés pour obtenir un regard externe sur les nouveaux clients, les spécifications de protocole mises à jour, les mises à niveau de réseau à venir ou tout autre élément jugé de grande valeur.
Lors des audits tiers, les développeurs de logiciels et les chercheurs en sécurité de notre équipe collaborent avec les auditeurs pour les informer et les assister tout au long.
Fuzzing 🦾
Il existe de nombreux efforts de fuzzing en cours menés par nos chercheurs en sécurité, les membres des équipes clientes, ainsi que les contributeurs de l’écosystème. La majorité des outils sont open source et fonctionnent sur une infrastructure dédiée. Les fuzzers ciblent les surfaces d’attaque critiques telles que les gestionnaires RPC, les implémentations de transition d’état et de choix de fourche, etc. Des efforts supplémentaires incluent Nosy Neighbor (génération de harnais de fuzz automatique basée sur AST) qui est basé sur CI et construit à partir de la bibliothèque Go Parser.
Simulation et test au niveau du réseau 🕸️
Les chercheurs en sécurité de notre équipe créent et utilisent des outils pour simuler, tester et attaquer des environnements réseau contrôlés. Ces outils peuvent rapidement créer des réseaux de test locaux et externes (« attacknets ») fonctionnant sous diverses configurations pour tester des scénarios exotiques contre lesquels les clients doivent être renforcés (par exemple, DDOS, ségrégation par les pairs, dégradation du réseau).
Les Attacknets fournissent un environnement efficace et sûr pour tester rapidement différentes idées/attaques dans un cadre privé. Les réseaux d’attaque privés ne peuvent pas être surveillés par des adversaires potentiels et nous permettent de casser des choses sans perturber l’expérience utilisateur des réseaux de test publics. Dans ces environnements, nous utilisons régulièrement des techniques perturbatrices telles que la pause des threads et le partitionnement du réseau pour étendre davantage les scénarios.
Recherche sur la diversité des clients et des infrastructures 🔬
Diversité des clients et des infrastructures a reçu beaucoup d’attention de la part de la communauté. Nous avons mis en place des outils pour surveiller la diversité à partir des statistiques d’un client, d’un système d’exploitation, d’un FAI et d’un robot d’exploration. De plus, nous analysons les taux de participation au réseau, les anomalies de synchronisation d’attestation et la santé générale du réseau. Ces informations sont partagé de l’autre côté plusieurs emplacements pour mettre en évidence les risques potentiels.
Programme Bug Bounty 🐛
L’EF héberge actuellement deux programmes de primes de bogues ; l’un ciblant le Couche d’exécution et un autre ciblant les Couche de consensus. Les membres de l’équipe de sécurité surveillent les rapports entrants, vérifient leur exactitude et leur impact, puis recoupent tout problème avec d’autres clients. Récemment, nous avons publié une divulgation de tous vulnérabilités précédemment signalées.
Bientôt, ces deux programmes seront fusionnés en un seul, la plate-forme générale sera améliorée et des récompenses supplémentaires seront fournies aux chasseurs de primes. Restez à l’écoute pour plus d’informations à ce sujet bientôt!
Sécurité opérationnelle 🔒
La sécurité opérationnelle englobe de nombreux efforts à l’EF. Par exemple, la surveillance des actifs a été configurée pour surveiller en permanence l’infrastructure et les domaines à la recherche de vulnérabilités connues.
Surveillance du réseau Ethereum 🩺
Un nouveau système de surveillance du réseau Ethereum est en cours de développement. Ce système fonctionne comme un SIEM et est conçu pour écouter et surveiller le réseau Ethereum pour les règles de détection préconfigurées ainsi que la détection dynamique des anomalies qui recherche les événements aberrants. Une fois en place, ce système fournira des alertes précoces sur les perturbations du réseau en cours ou à venir.
Analyse des menaces 🩻
Notre équipe a mené une analyse des menaces axée sur The Merge afin d’identifier les domaines pouvant être améliorés en matière de sécurité. Dans le cadre de ce travail, nous avons collecté et audité les pratiques de sécurité pour les revues de code, la sécurité de l’infrastructure, la sécurité des développeurs, la sécurité des builds (DAST, SCA et SAST intégrés à CI, etc.), la sécurité des référentiels, etc. des équipes clientes. De plus, cette analyse a étudié comment prévenir la désinformation, à partir de laquelle les catastrophes peuvent survenir et comment la communauté pourrait se rétablir dans divers scénarios. Certains efforts liés aux exercices de reprise après sinistre sont également intéressants.
Groupe de sécurité client Ethereum 🤝
À l’approche de la fusion, nous avons formé un groupe de sécurité composé de membres d’équipes clientes travaillant à la fois sur la couche d’exécution et sur la couche de consensus. Ce groupe se réunira régulièrement pour discuter de questions liées à la sécurité telles que les vulnérabilités, les incidents, les meilleures pratiques, les travaux de sécurité en cours, les suggestions, etc.
Réponse aux incidents 🚒
Les efforts de l’équipe bleue aident à combler le fossé entre la couche d’exécution et la couche de consensus à mesure que la fusion se rapproche. Les salles de guerre pour la réponse aux incidents ont bien fonctionné dans le passé où des discussions surgissaient avec les personnes concernées lors d’incidents, mais avec The Merge vient une nouvelle complexité. D’autres travaux sont en cours pour (par exemple) partager des outils, créer des capacités de débogage et de triage supplémentaires et créer de la documentation.
Merci et impliquez-vous 💪
Ce sont quelques-uns des efforts actuellement déployés sous diverses formes, et nous sommes impatients de partager encore plus avec vous à l’avenir !
Si vous pensez avoir trouvé une faille de sécurité ou un bogue, veuillez envoyer un rapport de bogue au couche d’exécution ou couche consensuelle programmes de primes aux bogues ! 💜🦄
Source https://blog.ethereum.org/en/2022/04/14/secured-no-3