L'équipe à l'origine de l'exploit du jeton H affirme qu'une machine de développement infectée par un logiciel malveillant a conduit à la compromission de sept clés privées, permettant à un attaquant de prendre le contrôle de l'infrastructure du pont et de déclencher l'un des incidents de jetons les plus importants du mois.
D'après le rapport d'autopsie du projet, l'agresseur s'est vidé 141 millions de jetons H sur Ethereum et j'en ai frappé un autre 300 millions de jetons H sur BNB Chain après avoir pris le contrôle des autorisations administratives du pont.
Le rapport souligne qu'il n'y a aucune vulnérabilité dans les contrats de pont, les contrats de jetons ou l'architecture multisig elle-même.
« Il n'y a eu aucun bug dans le pont, le jeton ou le coffre-fort », a écrit l'équipe.
Au lieu de cela, l'exploit a été attribué à un appareil de développeur compromis sur lequel plusieurs clés privées de production auraient été sauvegardées.
L'attaquant a pris le contrôle du pont administratif
Le rapport indique que l'attaquant a d'abord compromis un compte externe lié à l'administration du pont avant de prendre possession des contrats ProxyAdmin du protocole.
Cela a permis à l'exploiteur de :
- mettre à niveau les implémentations de ponts,
- drainer des liquidités sur Ethereum,
- et frappez de grandes quantités de jetons H sur BNB Chain.
L'équipe a déclaré que le côté chaîne BNB de l'offre de jetons est désormais considéré comme « irrécupérable » car l'attaquant contrôle toujours les autorisations de pont clés liées à l'infrastructure compromise.
L’incident a effectivement transformé une compromission de clé privée en une prise de contrôle complète de l’administration du pont.
Le rapport souligne une défaillance de la sécurité opérationnelle
Contrairement à de nombreux exploits DeFi impliquant des bogues de contrats intelligents ou des failles de logique de protocole, l'incident H semble être principalement lié à des défaillances de sécurité opérationnelle.
Le rapport indique qu'une seule machine infectée par un logiciel malveillant a exposé sept clés de production liées aux systèmes de pont et d'administration.
Ce compromis a permis à l'attaquant d'opérer avec des autorisations légitimes plutôt que de contourner directement les mécanismes de sécurité du protocole.
Cet exploit s’ajoute aux inquiétudes croissantes du secteur selon lesquelles les infrastructures décentralisées peuvent encore échouer de manière catastrophique lorsque la gestion des clés privées et la sécurité des points finaux restent centralisées.
L'exploit a déclenché une surveillance plus large en ligne
L’incident a également déclenché une discussion plus large sur Crypto Twitter. L'enquêteur sur la chaîne, ZachXBT, a remis en question les activités de tenue de marché et de gré à gré du projet avant de préciser plus tard que l'exploit lui-même ne semblait pas lié.
Dans une série de messages, ZachXBT a initialement fait part de ses inquiétudes concernant les accords de tenue de marché actifs et les activités de promotion symbolique entourant le projet.
Cependant, il a déclaré plus tard qu'une analyse plus approfondie suggérait que le « compromis de clé privée » et l'activité « fragmentaire MM/OTC » semblaient « indépendants les uns des autres et non liés ».
Ces commentaires reflétaient un scepticisme plus large sur le marché alors que les traders cherchaient à déterminer si l'exploit provenait d'une activité interne ou d'une véritable compromission de l'infrastructure.
Résumé final
- L'exploit du jeton H a été attribué à une machine de développement infectée par un logiciel malveillant qui a exposé sept clés privées utilisées pour l'administration du pont.
- ZachXBT a ensuite précisé que les préoccupations distinctes concernant la tenue de marché et les activités de gré à gré n'étaient pas directement liées au compromis sur la clé privée.