L'écosystème Cosmos, renommé mondialement comme l'un des plus grands et des plus remarquables réseaux blockchain, privilégie l'interopérabilité blockchain. Cet accent est essentiel pour faciliter la communication transparente entre les diverses blockchains. L'écosystème abrite plusieurs projets phares tels que Celestia et dYdX v4, tous développés à l'aide du Cosmos SDK et du protocole IBC. La préférence croissante des développeurs pour les composants de Cosmos a entraîné un impact amplifié des problèmes de sécurité au sein de l'écosystème. Un exemple en est la vulnérabilité Dragonfruit dans le Cosmos SDK, qui a perturbé les opérations dans de nombreuses blockchains publiques grand public.

Étant donné la nature décentralisée des composants principaux de Cosmos, les développeurs sont souvent tenus de s'adapter et d'étendre ces composants en fonction des besoins fonctionnels spécifiques. Cela entraîne une fragmentation des défis de sécurité au sein de l'écosystème Cosmos. Par conséquent, il est urgent d'adopter une approche structurée pour comprendre et traiter ces préoccupations en matière de sécurité. Cet article vise à fournir une analyse complète du paysage de sécurité actuel dans l'écosystème Cosmos et à définir des stratégies de réponse efficaces.

L'équipe CertiK est déterminée à renforcer la sécurité du réseau Cosmos et de l'écosystème Web3 plus large grâce à des recherches et développements continus. Nous sommes ravis de partager nos découvertes et nos points de vue avec vous grâce à des rapports de sécurité réguliers et des mises à jour techniques de recherche. Si vous avez des questions, notre équipe est toujours disponible pour vous contacter.

Voici le texte complet du “Guide de sécurité de l'écosystème Cosmos” 👇.

Aperçu de Cosmos

Considéré comme l'un des écosystèmes de blockchain les plus importants au monde, Cosmos se distingue par ses capacités de réseau open-source, évolutif et inter-chaînes. Développé par l'équipe CometBFT, initialement connue sous le nom de Tendermint, Cosmos vise à éliminer les silos d'information et à faciliter l'interopérabilité entre les différentes blockchains. À une époque où de multiples réseaux de blockchain coexistent, le besoin d'interaction inter-chaînes est plus pressant que jamais.

Cosmos se distingue en offrant un modèle de chaîne croisée efficace, particulièrement bénéfique pour les chaînes publiques avec des focus verticaux spécifiques. Son infrastructure blockchain modulaire permet aux développeurs d'applications de sélectionner et d'utiliser les chaînes publiques qui correspondent à leurs besoins spécifiques.

Au cœur de l'écosystème Cosmos se trouve le protocole de communication inter-blockchains (IBC), qui connecte les applications et les protocoles de différents blockchains indépendants. Cela facilite non seulement le transfert transparent des actifs et des données, mais correspond également à la vision de Cosmos de créer un 'internet des blockchains'. Ce concept envisage un vaste réseau de blockchains autonomes et facilement développés, interconnectés pour l'expansion et l'interaction.

Implication et recherche de CertiK dans la sécurité de Cosmos

Pendant une période prolongée, CertiK s'est profondément impliqué dans la recherche sur l'écosystème Cosmos. Notre équipe a acquis une expérience substantielle dans la résolution des défis de sécurité au sein de cet environnement. Dans ce rapport, nous partagerons nos idées et découvertes sur la sécurité de l'écosystème Cosmos, en nous concentrant sur quatre domaines clés : la sécurité du SDK Cosmos, la sécurité du protocole IBC, la sécurité de CometBFT et la sécurité de CosmWasm. Notre discussion couvrira tout, des composants fondamentaux de l'écosystème Cosmos aux chaînes fondamentales et d'application. En examinant et en extrapolant les problèmes connexes, nous visons à présenter une analyse complète, du bas vers le haut, des aspects critiques de sécurité au sein de l'écosystème Cosmos.

Étant donné la complexité et la diversité de l'écosystème Cosmos, il est confronté à un large éventail de défis en matière de sécurité. Ce rapport se concentre principalement sur les menaces les plus caractéristiques et significatives pour la chaîne écologique de Cosmos. Pour plus d'informations ou de discussions sur d'autres aspects de sécurité, nous vous encourageons à contacter les ingénieurs en sécurité de CertiK.

Contexte

CometBFT: Améliorer la scalabilité inter-chaînes au cœur de celle-ci

Au coeur de la scalabilité interchaîne se trouve CometBFT, un algorithme de consensus de pointe indispensable pour garantir la sécurité, la décentralisation et l'intégrité de l'écosystème Interchain. Cet algorithme est un composite de deux composants principaux : le noyau CometBFT, qui sert de moteur de consensus fondamental, et une interface universelle de blockchain d'application (ABCI). En combinant des éléments de PBFT (tolérance aux fautes byzantines pratiques) et Bonded Proof of Stake (PoS), CometBFT synchronise les nœuds pour maintenir des enregistrements de transactions précis, jouant ainsi un rôle crucial dans le consensus des validateurs au sein de l'environnement Interchain.

Cosmos SDK: Accélérer le développement de la blockchain avec la modularité

Le Cosmos SDK se présente comme une boîte à outils puissante qui simplifie et accélère le développement de la blockchain. Sa conception modulaire et ses fonctionnalités enfichables permettent aux développeurs de construire leurs propres blockchains ou composants fonctionnels au-dessus de l'algorithme de consensus CometBFT. Cette approche non seulement facilite le développement, mais raccourcit également considérablement le cycle de développement. L'efficacité du SDK est démontrée par son adoption dans de nombreux projets, notamment Cronos, Kava, et le récemment lancé dYdX V4. À l'avenir, le Cosmos SDK prévoit d'améliorer sa modularité et d'introduire de nouvelles fonctionnalités, permettant la création d'applications plus sophistiquées et modulaires, favorisant ainsi un écosystème plus vaste et robuste.

Protocole IBC : Favoriser l'interopérabilité et la scalabilité à travers les blockchains

Le protocole de communication inter-blockchains (IBC) est crucial pour faciliter le transfert de données sécurisé, décentralisé et sans autorisation entre les blockchains au sein du réseau Cosmos. Étant donné que Cosmos est un réseau décentralisé composé de plusieurs blockchains indépendantes et parallèles connectées par une technologie de relais, le rôle du protocole IBC dans l'amélioration de la scalabilité et de l'interopérabilité est central. L'objectif actuel de la Fondation Interchain est d'améliorer ces aspects du protocole IBC, visant à renforcer les interactions fluides entre les blockchains, les applications et les contrats intelligents au sein de l'écosystème Cosmos.

CosmWasm: Facilitating Decentralized Application Deployment

CosmWasm (Cosmos WebAssembly) est un cadre de contrat intelligent adapté à l'écosystème Cosmos. Basé sur WebAssembly, il permet aux développeurs de déployer des applications décentralisées sans avoir besoin d'autorisations spécifiques. Ce cadre permet aux développeurs de blockchain de découpler le développement de produits du développement de la blockchain, réduisant le fardeau des mises à niveau du validateur. Les fonctionnalités de CosmWasm comprennent une architecture modulaire, une intégration avec le Cosmos SDK et des capacités de communication inter-chaîne. Le Cosmos SDK et le protocole IBC, étant relativement matures, sont largement utilisés dans l'écosystème actuel de Cosmos.

Adaptation et personnalisation au sein de l'écosystème Cosmos

Pour les développeurs de chaînes dans l'écosystème Cosmos, le Cosmos SDK répond à la plupart des besoins de personnalisation. Lors d'activités inter-chaînes, les développeurs de chaînes peuvent adapter leurs modules IBC pour des opérations spéciales ou une optimisation des performances. Alors que certaines chaînes modifient les moteurs sous-jacents comme CometBFT Core, les contraintes d'espace empêchent une discussion détaillée de telles modifications dans ce rapport. Par conséquent, cette recherche se concentre principalement sur les subtilités techniques et les considérations de sécurité du Cosmos SDK et du protocole IBC.

Guide de sécurité Cosmos SDK

Le guide de sécurité du Cosmos SDK fournit un aperçu complet des aspects de sécurité du Cosmos SDK, un cadre avancé pour le développement d'applications blockchain et de protocoles décentralisés. Créé par la Fondation Interchain, ce cadre est essentiel au réseau Cosmos, qui est un réseau étendu de blockchains interconnectées.

Au cœur, le SDK Cosmos est conçu pour rationaliser la création d'applications blockchain sur mesure tout en facilitant l'interaction transparente entre les blockchains diverses. Ses caractéristiques notables englobent une structure modulaire, une personnalisation étendue, une intégration avec le noyau CometBFT pour le consensus, et la mise en œuvre des interfaces IBC, contribuant toutes à son attrait pour les développeurs. Une force clé du Cosmos SDK est sa dépendance au moteur de consensus CometBFT Core, qui offre des mesures de sécurité robustes. Ce moteur joue un rôle vital dans la défense du réseau contre les attaques malveillantes et dans la protection des actifs et des données des utilisateurs. La nature modulaire du SDK permet aux utilisateurs de créer facilement des modules sur mesure. Cependant, les développeurs doivent rester vigilants car des vulnérabilités de sécurité peuvent encore survenir lors du déploiement d'applications utilisant le Cosmos SDK.

Du point de vue de l'audit de sécurité, il est essentiel d'évaluer minutieusement les menaces potentielles de sécurité sous plusieurs perspectives. En revanche, dans la recherche en sécurité, l'accent se déplace vers l'identification des vulnérabilités qui pourraient avoir des répercussions significatives. Cette approche vise à atténuer rapidement les menaces de sécurité majeures, offrant ainsi une assistance plus efficace aux services intégrant le SDK. Il est crucial d'identifier et d'examiner les vulnérabilités présentant des risques graves et des implications étendues.

Un point central au sein du Cosmos SDK est l'interface ABCI, qui est essentielle à l'écosystème Cosmos. Cette interface comprend quatre composants clés : BeginBlock, EndBlock, CheckTx et DeliverTx. BeginBlock et EndBlock sont directement impliqués dans la logique d'exécution des blocs individuels. En revanche, CheckTx et DeliverTx sont concernés par le traitement de sdk.Msg, la structure de données fondamentale pour la transmission des messages au sein de l'écosystème Cosmos.

Pour comprendre et traiter les vulnérabilités de sécurité mentionnées, il faut d'abord saisir le cycle de vie des transactions dans l'écosystème Cosmos. Les transactions proviennent des agents utilisateurs, où elles sont créées, signées, puis diffusées aux nœuds de la blockchain. La méthode CheckTx est utilisée par les nœuds pour valider les détails de la transaction tels que les signatures, le solde de l'expéditeur, la séquence de la transaction et le gaz fourni. Les transactions valides sont mises en attente dans le mempool, en attente d'inclusion dans un bloc, tandis que les non valides sont rejetées, avec des messages d'erreur relayés aux utilisateurs. Lors du traitement du bloc, la méthode DeliverTx est appliquée pour garantir la cohérence transactionnelle et le déterminisme.

Dans le SDK Cosmos, le cycle de vie de la transaction est un processus à plusieurs étapes, comprenant la création, la validation, l'inclusion dans un bloc, les changements d'état et l'engagement final. Ce processus peut être décrit dans les étapes suivantes:

1. Création de transaction: Les utilisateurs génèrent des transactions à l'aide de divers outils tels que les Interfaces en Ligne de Commande (CLI) ou les clients frontend.

2. Ajout au Mempool: Une fois créées, les transactions entrent dans le mempool. Ici, les nœuds envoient un message ABCI (Application BlockChain Interface), appelé CheckTx, à la couche d'application pour vérification de la validité. Les transactions subissent un décodage du format byte au format Tx. Chaque sdk.Msg dans la transaction est soumis à des vérifications préliminaires sans état par la fonction ValidateBasic(). De plus, si l'application inclut un anteHandler, sa logique est exécutée avant la fonction runTx, ce qui conduit à la fonction RunMsgs() pour traiter le contenu sdk.Msg. Un CheckTx réussi entraîne la mise en file d'attente de la transaction dans le mempool local, prête à être incluse dans le prochain bloc, et simultanément diffusée aux nœuds pairs via P2P.

3. Inclusion dans un bloc proposé: Au début de chaque tour, le proposant assemble un bloc contenant les transactions récentes. Les validateurs, qui sont responsables de maintenir le consensus, approuvent ce bloc ou optent pour un bloc vide.

4. Changements d'état: Similaire à CheckTx, le processus DeliverTx itère à travers les transactions de bloc. Cependant, il fonctionne en mode 'Deliver', exécutant des changements d'état. Le MsgServiceRouter dirige différents messages de transaction vers des modules respectifs, où chaque message est traité dans le serveur Msg. Après l'exécution du message, des vérifications supplémentaires assurent la validité de la transaction. Si une vérification échoue, l'état revient à sa condition précédente. Un compteur de gaz suit le gaz consommé pendant l'exécution. Les erreurs liées au gaz, telles qu'un gaz insuffisant, entraînent une réversion des changements d'état, similaire aux échecs d'exécution.

5. Engagement de bloc: Dès réception des votes suffisants des validateurs, un nœud valide le nouveau bloc dans la blockchain. Cette action finalise les transitions d'état au niveau de l'application, marquant ainsi l'achèvement du processus de transaction.

)

[Cette section comprend un diagramme représentant le cycle de vie des transactions dans l'écosystème Cosmos.]

[La section suivante fournit une logique d'exécution spécifique de la clé ABCI dans Cosmos SDK, utile pour comprendre et analyser les vulnérabilités discutées ultérieurement.]

)

Catégories de vulnérabilités courantes

Avant de comprendre la classification des vulnérabilités, nous devons avoir une division de base du niveau de danger des vulnérabilités. Cela aide à mieux identifier les vulnérabilités de sécurité à haut risque et à éviter les risques potentiels pour la sécurité.

)

Compte tenu du niveau de danger et de l'ampleur de l'impact, nous nous concentrons principalement sur les vulnérabilités de sécurité classées Critiques et Majeures, qui peuvent généralement entraîner les risques suivants :

1. Opération d'arrêt de la chaîne
2. Perte financière
3. Affectant l'état du système ou le fonctionnement normal

Les causes de ces dangers sont souvent les types de vulnérabilités de sécurité suivants :

1. Deni de service
2. Paramètres d'état incorrects
3. Manque de vérification ou vérification déraisonnable
4. Problèmes d'unicité
5. Problèmes d'algorithme de consensus
6. Défauts logiques dans la mise en œuvre
7. Problèmes de fonctionnalités linguistiques

Analyse des vulnérabilités dans l'écosystème Cosmos

L'écosystème Cosmos, connu pour sa structure modulaire, rencontre souvent des cas d'inter-utilisation et d'inter-appel de modules au sein de ses chaînes. Cette complexité conduit à des scénarios où le chemin de déclenchement de la vulnérabilité et les variables de localisation sont incohérents. Pour comprendre ces vulnérabilités, il est crucial de prendre en compte non seulement le chemin de déclenchement, mais aussi le chemin contrôlable des variables critiques de la vulnérabilité. Cette double focalisation aide à mieux définir et catégoriser le modèle de vulnérabilité.

Opération d'arrêt de chaîne : causes et types

Les arrêts de chaîne sont généralement dus à des problèmes rencontrés lors de l'exécution d'un seul bloc. Cependant, l'histoire de Cosmos inclut des cas où des vulnérabilités de sécurité du consensus ont rendu nécessaires des arrêts actifs de la chaîne pour des réparations. Ces problèmes relèvent de deux catégories distinctes.

Le premier type est couramment observé dans les vulnérabilités de déni de service : celles-ci sont souvent le résultat d'une gestion de crash inadéquate et d'opérations de boucle influencées par l'utilisateur. Ces vulnérabilités peuvent entraîner une pause ou un ralentissement significatif de la chaîne.

Cosmos SDK et CometBFT, des infrastructures clés dans l'écosystème Cosmos, sont non seulement utilisés par les chaînes de base dans Cosmos mais aussi par diverses chaînes d'application basées sur leur architecture. Toutes suivent les règles de l'interface ABCI de CometBFT. La surface d'attaque principale se situe également sur leur interface ABCI, et la plupart des vulnérabilités de sécurité pouvant entraîner l'arrêt de la chaîne sont des problèmes qui peuvent affecter directement l'exécution du code de bloc. Par conséquent, leurs chemins d'occurrence peuvent généralement être retracés jusqu'aux interfaces BeginBlock et EndBlock.

Le deuxième type de situation concerne les vulnérabilités affectant le consensus : elles sont souvent liées à la mise en œuvre sur diverses chaînes et incluent des problèmes de validation du traitement logique, de calibration du temps et d'aléatoire. Ces vulnérabilités frappent au cœur du principe de décentralisation de la blockchain. Bien qu'elles puissent ne pas sembler graves initialement, entre les mains d'un acteur malveillant, elles représentent une menace sérieuse pour la sécurité.

Exemples du premier type

Exemple 1: Analyse de vulnérabilité du projet SuperNova

Contexte de vulnérabilité : Dans le processus de distribution de frappe au sein du projet SuperNova, un problème critique découle de l'absence de vérification de l'adresse. Cet oubli peut entraîner un échec de l'opération et, par conséquent, une perte financière. En particulier, le module de frappe, qui est essentiel pour la génération de jetons, repose sur le montant mis en jeu. Cependant, ce processus est susceptible d'erreurs. Par exemple, si le pool désigné n'existe pas ou s'il y a une entrée erronée de l'adresse du contrat, cela peut entraîner des dysfonctionnements dans le module de frappe. De telles erreurs ont le potentiel d'interrompre l'ensemble de l'opération de la blockchain. De plus, dans le module de pool de récompenses, il manque une vérification de l'adresse du contrat de pool. Cet oubli signifie que tout échec de l'opération de distribution pourrait entraîner l'arrêt immédiat de la blockchain.

Emplacement de la vulnérabilité : Lien GitHub SuperNova

Extrait de code vulnérable :

Chemin de déclenchement de la vulnérabilité :

BeginBlocker (/x/mint/keeper/abci.go)

Keeper.DistributeMintedCoin

Keeper.distributeLPIncentivePools

PoolIncentiveKeeper.GetAllIncentivePool (/x/mint/keeper/keeper.go)

Correctif de vulnérabilité :

https://github.com/Carina-labs/nova/commit/538abc771dea68e33fd656031cbcf2b8fe006be0

Le correctif se trouve dans le module de gestion des messages de poolincentive (x/poolincentive/types/msgs.go), et non dans le module de création. Il a ajouté une vérification d'adresse au message MsgCreateCandidatePool pour éliminer la possibilité d'adresses incorrectes à partir de la racine.

Exemple 2: Projet de sécurité interchaîne Cosmos

Adresse du projet: Lien GitHub de la sécurité interchaînes de Cosmos

Contexte de vulnérabilité : Les validateurs peuvent ralentir la chaîne du fournisseur en soumettant plusieurs messages AssignConsumerKey dans le même bloc. Dans le fichier x/ccv/provider/keeper/key_assignment.go, la fonction AssignConsumerKey permet aux validateurs d'assigner différents consumerKeys aux chaînes de consommateurs approuvées. La liste d'adresses consumerAddrsToPrune augmente d'un élément pour effectuer cette opération. Comme cette liste d'adresses est itérée dans l'EndBlocker dans x/ccv/provider/keeper/relay.go, les attaquants peuvent l'exploiter pour ralentir la chaîne du fournisseur. Pour cette attaque, l'acteur malveillant peut créer des transactions avec plusieurs messages AssignConsumerKey et les envoyer à la chaîne du fournisseur. La cardinalité de la liste d'adresses consumerAddrsToPrune sera la même que celle des messages AssignConsumerKey envoyés. Par conséquent, l'exécution de l'EndBlocker prendra plus de temps et de ressources que prévu, ralentissant voire arrêtant la chaîne du fournisseur.

Emplacement de la vulnérabilité : Cosmos Interchain Security GitHub Link

Segment de code de vulnérabilité :

Chemin de déclenchement de la vulnérabilité :

msgServer.AssignConsumerKey

Keeper.AffecterClefConsommateur

AppModule.EndBlock

EndBlockCIS

Gérer les paquets matures HandleLeadingVSCMaturedPackets

HandleVSCMaturedPacket

PruneKeyAssignments

Exemple 3: Projet Quicksilver - Module de largage aérien

Contexte de vulnérabilité : BeginBlocker et EndBlocker sont des méthodes optionnelles que les développeurs de modules peuvent implémenter dans leur module. Ils sont déclenchés au début et à la fin de chaque bloc, respectivement. L'utilisation de plantages pour gérer les erreurs dans les méthodes BeginBlock et EndBlock peut entraîner l'arrêt de la chaîne en cas d'erreurs. L'EndBlocker n'a pas pris en compte si le module avait suffisamment de jetons pour régler les largages aériens inachevés, ce qui pourrait déclencher un plantage et arrêter la chaîne.

Emplacement de la vulnérabilité : Lien GitHub Quicksilver

Segment de code de vulnérabilité :

Correctif de vulnérabilité : AppModule.EndBlock

Keeper.EndBlocker

Gardien.EndZoneDrop

Correctif de vulnérabilité :https://github.com/quicksilver-zone/quicksilver/blob/20dc658480b1af1cb323b4ab4a8e5925ee79a0ed/x/airdrop/keeper/abci.go#L16

Le code de gestion de la panique a été supprimé et remplacé par un journal d'erreurs.

Exemple 4: Projet de sécurité interchaîne Cosmos

Adresse du projet: Cosmos Interchain Security GitHub Link

Contexte de vulnérabilité: Les attaquants peuvent effectuer une attaque par déni de service en envoyant plusieurs jetons à l'adresse de récompense de la chaîne du fournisseur. Dans le flux d'exécution EndBlocker de la chaîne du consommateur, la fonction SendRewardsToProvider définie dans x/ccv/consumer/keeper/distribution.go récupère le solde de tous les jetons en tstProviderAddr et les envoie à la chaîne du fournisseur. Pour ce faire, il doit itérer à travers tous les jetons trouvés à l'adresse de récompense et envoyer chacun d'eux via IBC à la chaîne du fournisseur. Étant donné que n'importe qui peut envoyer des jetons à l'adresse de récompense, les attaquants peuvent créer et envoyer un grand nombre de jetons de dénominations différentes, par exemple, en utilisant une chaîne avec un module de création de jetons, pour initier une attaque par déni de service. Par conséquent, l'exécution de EndBlocker prendra plus de temps et de ressources que prévu, ralentissant voire arrétant la chaîne du consommateur.

Emplacement de la vulnérabilité : Lien GitHub sur la sécurité inter-chaînes de Cosmos

Segment de code de vulnérabilité :

Chemin de déclenchement de la vulnérabilité :

AppModule.EndBlock

EndBlock

EndBlockRD

SendRewardsToProvider

Deuxième type de situation

Ce type de problème de consensus peut ne pas causer de dommages graves immédiats, mais en considérant les principes fondamentaux et le système de l'ensemble de la blockchain, ou en examinant ces vulnérabilités à partir de scénarios spécifiques, leur impact et leurs dommages peuvent ne pas être inférieurs à ceux d'autres vulnérabilités conventionnelles. De plus, ces vulnérabilités ont des caractéristiques communes.

Exemple 1

Contexte de la vulnérabilité : Avis de sécurité Cosmos SDK Jackfruit

Le comportement non déterministe dans la méthode ValidateBasic du module x/authz dans Cosmos SDK peut facilement entraîner un arrêt du consensus. La structure du message MsgGrant dans le module x/authz inclut un champ Grant, qui contient le temps d'expiration accordé par l'autorisation définie par l'utilisateur. Dans le processus de validation de ValidateBasic() dans la structure Grant, il compare ses informations temporelles avec celles de l'heure locale du nœud plutôt qu'avec les informations temporelles du bloc. Étant donné que l'heure locale est non déterministe, les horodatages peuvent différer entre les nœuds, ce qui entraîne des problèmes de consensus.

Annonce de vulnérabilité :

• Lien du Forum Cosmos 1

• Lien du Forum Cosmos 2

• Lien de l'avis de sécurité GitHub Cosmos SDK

Segment de code de vulnérabilité :

Correctif de vulnérabilité : Lien de comparaison GitHub Cosmos SDK

Des problèmes tels que les horodatages n'apparaissent pas seulement dans des composants fondamentaux comme Cosmos SDK, mais se sont également produits dans diverses chaînes d'application.

Exemple 2

Contexte de la vulnérabilité : SuperNova, projet nova

Adresse du projet: Lien GitHub SuperNova

En utilisant time.Now(), vous obtenez le timestamp du système d'exploitation. L'heure locale est subjective et donc non déterministe. Comme il peut y avoir de petites différences dans les horodatages des nœuds individuels, la chaîne peut ne pas parvenir à un consensus. Dans le module ICAControl, la fonction d'envoi de transaction utilise time.Now() pour obtenir le timestamp.

Emplacement de la vulnérabilité : https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/icacontrol/keeper/send_msgs.go#L14

Segment de code de vulnérabilité :

Correctif de vulnérabilité:

Passé de l'utilisation de l'horodatage local à l'utilisation du temps de bloc.

timeoutTimestamp := time.Now().Add(time.Minute * 10).UnixNano() _, err = k.IcaControllerKeeper.SendTx(ctx, chanCap, connectionId, portID, packetData, uint64(timeoutTimestamp)

timeoutTimestamp := uint64(ctx.BlockTime().UnixNano() + 10*time.Minute.Nanoseconds()) _, err = k.IcaControllerKeeper.SendTx(ctx, chanCap, connectionId, portID, packetData, uint64(timeoutTimestamp)

Cas Trois:

Contexte de la vulnérabilité : Module Oracle dans le projet BandChain

URL du projet: Dépôt GitHub de BandChain

Les commentaires dans le référentiel de code indiquent que le module oracle doit être exécuté avant le staking pour mettre en œuvre des mesures de punition pour les contrevenants au protocole oracle. Cependant, dans le code, la séquence est inversée : dans la fonction SetOrderEndBlockers, le module de staking s'exécute avant le module oracle. Si le module de staking est exécuté avant le module oracle, il serait impossible d'appliquer des pénalités basées sur les vérifications effectuées dans le module oracle.

Emplacement de la vulnérabilité : Snippet de code GitHub de BandChain

Segment de code de vulnérabilité:

La vulnérabilité réside dans la mise en œuvre réelle et les commentaires contradictoires, où le module oracle devrait être placé avant le module de mise en jeu.

Cas Quatre :

Contexte de la vulnérabilité: Module de contrôle d'accès dans le projet Sei Cosmos

URL du projet: Sei Cosmos GitHub Repository

Dans de multiples cas dans les dépôts de code liés à Cosmos, on utilise le type de carte du langage Go et on y itère. En raison de la nature non déterministe de l'itération de la carte de Go, cela pourrait conduire à ce que les nœuds atteignent des états différents, entraînant potentiellement des problèmes de consensus et arrêtant par conséquent le fonctionnement de la chaîne. Une méthode plus appropriée serait de trier les clés de la carte dans une tranche et d'itérer sur les clés triées. De tels problèmes sont courants, découlant de l'application des fonctionnalités du langage.

Dans l'implémentation de BuildDependencyDag dans x/accesscontrol/keeper/keeper.go, il y a une itération sur les nœuds anteDepSet. En raison du comportement non déterministe de l'itération de la carte en Go, ValidateAccessOp pourrait entraîner deux types d'erreurs différents, conduisant potentiellement à un échec de consensus.

Emplacement de la vulnérabilité : Snippet de code GitHub de Sei Cosmos

Segment de code de vulnérabilité :

De ces cas, il est évident que les vulnérabilités causant l'arrêt passif d'une chaîne sont souvent les plus nuisibles. Leur logique causale peut être retracée jusqu'à affecter directement le flux d'exécution des blocs individuels d'une blockchain. En revanche, les vulnérabilités de sécurité du consensus entraînent généralement l'arrêt actif de la chaîne pour mettre en œuvre des correctifs, leur logique causale étant retracée jusqu'à affecter le flux opérationnel global et l'état de la blockchain. Cela diffère de l'accent mis sur les vulnérabilités entraînant des pertes financières, où l'impact spécifique dangereux n'est pas jugé sur la base du chemin logique de survenue du problème, mais se concentre plutôt sur les propriétaires des fonds, le montant d'argent impliqué, la portée et les méthodes affectant les fonds.

perte de fonds

Les problèmes de perte de capital sont couramment observés dans la gestion logique des messages sdk.Msg et IBC. Bien sûr, il existe également des vulnérabilités qui peuvent entraîner une perte de capital parmi les raisons pouvant interrompre le fonctionnement d'une blockchain. L'impact spécifique dépend de la vulnérabilité particulière, et ici nous nous concentrons sur la première. De plus, étant donné que l'IBC est un composant très important de l'écosystème Cosmos, il implique inévitablement certaines vulnérabilités dans l'IBC. Les détails sur la surface d'attaque de l'IBC et les vulnérabilités correspondantes seront discutés dans le prochain chapitre.

Les pertes en capital sont couramment rencontrées dans des scénarios tels que la consommation de gaz, le verrouillage des fonds et l'incapacité de les retirer, la perte de fonds lors du transfert, des erreurs dans la logique de calcul entraînant une perte de fonds, et l'incapacité de garantir l'unicité des identifiants de stockage des fonds.

Ici, nous prenons le projet SuperNova comme exemple pour analyser trois vulnérabilités connexes.

Contexte de la vulnérabilité : Projet SuperNova

URL du projet: https://github.com/Carina-labs/nova

Si les décimales dans une zone dépassent 18, les fonds peuvent devenir bloqués. Dans le code de ce projet, il n'y a pas de limite supérieure sur les décimales d'une zone, qui peuvent dépasser 18. Dans ClaimSnMessage, lorsque les utilisateurs veulent réclamer leurs jetons de partage, ClaimShareToken est utilisé. Cependant, si les décimales de la zone dépassent 18, la conversion échouera et il sera impossible d'extraire des actifs du système. Ainsi, en contrôlant les décimales d'une zone, il est possible de déclencher directement un crash et un échec de transaction.

Emplacement de la vulnérabilité : https://github.com/Carina-labs/nova/blob/v0.6.3/x/gal/keeper/claim.go#L167

Fragment de code de vulnérabilité :

Chemin de déclenchement de la vulnérabilité :

msgServer.ClaimSnAsset

Keeper.ClaimShareToken

Keeper.ConvertWAssetToSnAssetDecimal

precisionMultiplier

• Contexte de la vulnérabilité: projet SuperNova

Adresse du projet : https://github.com/Carina-labs/nova/

The uniqueness of the zone is not verified. Sur les régions enregistrées, utilisez l'identifiant de région pour vérifier l'unicité du jeton de base (BaseDenom). Le BaseDenom de chaque région doit être unique. Si la valeur du jeton de base est définie de manière incorrecte, cela entraînera une perte de fonds. Avant de définir le jeton de base dans RegisterZone, le projet n'a pas assuré que le BaseDenom était unique dans toutes les zones principales. Sinon, il y aurait la possibilité pour les utilisateurs de stocker des fonds dans une autre zone malveillante contenant un BaseDenom portant le même nom, entraînant une perte de fonds.

Emplacement de la vulnérabilité : https://github.com/Carina-labs/nova/blob/v0.6.3/x/icacontrol/keeper/msg_server.go#L99

Extrait de code vulnérable :

Correctif de bug : Ajout de la vérification DenomDuplicateCheck

De plus, le premier cas dans le premier cas où la chaîne s'arrête de fonctionner est dû à un crash qui entraîne l'échec de la création de monnaie, ce qui constitue également une forme de perte de capital.

• Contexte de la vulnérabilité : projet Supernova

Adresse du projet : https://github.com/Carina-labs/nova/

Mises à jour de statut manquantes. Dans la méthode IcaWithdraw(), si la transaction échoue et que le statut de la version n'est pas modifié, le WithdrawRecord sera inaccessible et les fonds correspondants ne pourront pas être retirés. Une compréhension plus populaire est que l'état est défini avant SendTx, et que l'état n'est pas modifié après l'échec, ce qui provoque l'échec du retrait des fonds et ne peut pas être retiré à nouveau la prochaine fois.

Emplacement de la vulnérabilité : https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/gal/keeper/msg_server.go#L356

Extrait de code vulnérable :

Basé sur cet extrait, nous pouvons discerner que la logique principale des opérations liées aux fonds dépend principalement du traitement de divers messages. Bien sûr, il y a aussi des cas comme le premier scénario impliquant des opérations de création lors du processus d'exécution BeginBlock. Lorsque ces opérations échouent, elles peuvent également entraîner des pertes financières. Dans l'ensemble, en concentrant notre audit sur les modules de code impliquant des opérations financières, nous pouvons augmenter considérablement la probabilité de découvrir de telles vulnérabilités.

Impactant l'état du système ou le fonctionnement normal

La gamme de cette catégorie de problèmes est assez large. Les deux premiers types de risques que nous avons discutés peuvent également être considérés comme des sous-ensembles de vulnérabilités qui affectent l'état du système ou son fonctionnement normal. En plus de ceux-ci, les vulnérabilités logiques sont encore plus dangereuses. Dans une large mesure, ces vulnérabilités génèrent différents risques de sécurité selon la logique métier du projet. Cependant, en raison des similitudes dans la construction des composants Cosmos SDK et de leur nature modulaire, des erreurs similaires surviennent souvent dans des implémentations de code spécifiques. Ici, nous listons quelques types courants de vulnérabilités :

- Validation incomplète des variables dans le sdk. Type de msg :

Étant donné que divers projets ont mis en œuvre une variété de types dérivés basés sur sdk.Msg, tous les éléments des types existants n'ont pas été vérifiés de manière adéquate dans Cosmos SDK. Cela a conduit à l'omission de vérifications critiques des variables intégrées, ce qui pose certains risques pour la sécurité.

Étude de cas : Avis de sécurité Cosmos SDK Barberry

Contexte de vulnérabilité : Le MsgCreatePeriodicVestingAccount.ValidateBasic manque de mécanismes pour évaluer le statut d'un compte, tel que s'il est actif. Dans le compte à versements périodiques défini par x/auth, un attaquant pourrait initialiser le compte d'une victime vers un compte appartenant malicieusement à l'attaquant. Ce compte autorise les dépôts mais interdit les retraits. Lorsque les utilisateurs déposent des fonds sur leur compte, ces fonds seront verrouillés de façon permanente et l'utilisateur ne pourra pas les retirer.

Correctif de vulnérabilité :

https://forum.cosmos.network/t/cosmos-sdk-security-advisory-barberry/10825

https://github.com/cosmos/cosmos-sdk/security/advisories/GHSA-j2cr-jc39-wpx5

https://github.com/cosmos/cosmos-sdk/compare/v0.47.3-rc.0...v0.47.3

https://github.com/cosmos/cosmos-sdk/pull/16465

Extrait de code vulnérable :

En plus de cela, des problèmes étaient également présents dans la phase ValidateBasic dans les avis de sécurité Elderflower et Jackfruit de Cosmos-SDK. Le premier a souffert d'une omission directe de l'appel ValidateBasic, tandis que le second impliquait des problèmes de vérification de la variable de timestamp dans le message. Dans les chaînes d'application, de tels problèmes sont encore plus courants. Des projets comme ethermint, pstake-native et quicksilver ont tous rencontré des vulnérabilités de sécurité similaires dans leurs mesures de vérification du traitement des messages.

Outre les types de vérification, il existe également des problèmes rencontrés dans la logique de traitement de sdk.Msg, tels que des opérations impliquant une consommation extensive de gaz, des boucles et une gestion de crash déraisonnable. Étant donné que la chaîne de traitement des messages dispose de mécanismes de récupération correspondants, leur niveau de danger est quelque peu inférieur à un arrêt complet de la chaîne. Cependant, ils peuvent toujours avoir un impact sur le fonctionnement normal du système ou entraîner une perte de fonds sur la chaîne.

Types de vulnérabilités courants

À l'exclusion des vulnérabilités propres aux opérations spécifiques à un projet, il existe des modèles de vulnérabilité plus courants. Par exemple, le troisième cas de perte de fonds est une opération qui modifie l'état avant d'envoyer un message. Ce type de vulnérabilité est similaire à celles des contrats intelligents, où le changement d'état avant le transfert de fonds peut entraîner des problèmes tels que la réentrance ou des états erronés persistants. Les scénarios où le réglage de l'état est étroitement lié à la transmission de messages sont assez courants dans la blockchain, et de nombreuses vulnérabilités significatives proviennent de tels problèmes. En outre, il existe des vulnérabilités de sécurité computationnelle telles que les erreurs de division par zéro, les contournements de la consommation de gaz et l'utilisation de versions présentant des vulnérabilités connues, qui peuvent toutes affecter l'état ou le fonctionnement normal du système.

Problèmes d'unicité

En raison de nombreuses opérations de lecture et d'écriture sur la blockchain, l'unicité dans la désignation est extrêmement importante dans certaines fonctionnalités. Par exemple, le deuxième cas de perte de fonds mentionné précédemment est un problème d'unicité. De plus, la composition des préfixes dans les variables représentant des clés, telles que des chaînes de caractères ou des tableaux d'octets, peut poser des risques. Un léger oubli pourrait entraîner des noms mal interprétés, entraînant des problèmes tels que des pertes de fonds ou des erreurs de consensus.

Problèmes de fonctionnalités linguistiques

Ceux-ci sont plus larges mais ont des caractéristiques identifiables, ce qui les rend plus faciles à détecter. Les exemples incluent des problèmes avec l'itération de carte en Golang ou des mécanismes de panique en Rust. Il est conseillé de répertorier ces facteurs de risque spécifiques à la langue et d'y prêter une attention particulière lors de l'utilisation ou de l'audit afin de minimiser de telles erreurs.

Résumé

De notre exploration des problèmes de sécurité sous-jacents dans l'écosystème Cosmos, il est clair que ces problèmes ne sont pas propres à Cosmos et peuvent s'appliquer à d'autres écosystèmes blockchain également. Voici quelques recommandations et conclusions concernant les problèmes de sécurité dans l'écosystème Cosmos:

• Faites attention aux vulnérabilités de l'infrastructure : des composants essentiels comme CometBFT et Cosmos SDK pourraient également présenter des vulnérabilités, il est donc nécessaire de procéder à des mises à jour régulières et à un entretien pour des raisons de sécurité.

• Examinez rapidement les bibliothèques tierces : les développeurs de Cosmos utilisent souvent des bibliothèques tierces pour étendre les fonctionnalités de leurs applications. Ces bibliothèques pourraient contenir des vulnérabilités potentielles, nécessitant ainsi un examen et des mises à jour pour atténuer les risques.

• Méfiez-vous des attaques de nœuds malveillants : les nœuds de consensus sont cruciaux dans l'écosystème Cosmos. Les algorithmes de tolérance aux fautes byzantines de ces nœuds pourraient être vulnérables aux attaques, il est donc essentiel de garantir la sécurité des nœuds pour prévenir tout comportement malveillant.

• Considérez la sécurité physique : Des mesures de sécurité physique sont nécessaires pour le matériel et les serveurs exécutant des nœuds Cosmos afin de prévenir l'accès non autorisé et les attaques potentielles.

• Effectuer les révisions de code nécessaires: Compte tenu de l'ouverture des écosystèmes Cosmos SDK et CometBFT, les développeurs et les auditeurs doivent examiner à la fois le code central et le code écrit dans des modules personnalisés pour identifier et corriger les problèmes de sécurité potentiels.

• Faites attention aux outils de l'écosystème : L'écosystème Cosmos comprend de nombreux outils et applications, qui doivent également subir des examens de sécurité et des mises à jour régulières pour garantir leur sécurité.

Guide de sécurité du protocole IBC

Ce module se concentre sur les aspects de sécurité du protocole de communication inter-blockchains (IBC), un composant crucial de l'écosystème Cosmos. Le protocole IBC sert de pont pour les interactions entre différentes blockchains. Alors que d'autres ponts inter-chaînes fournissent des solutions pour des problèmes spécifiques et isolés, le protocole IBC offre une solution fondamentale unifiée et un support technique sous-jacent pour les interactions inter-chaînes. L'IBC est un protocole qui permet aux blockchains hétérogènes de transférer des données de manière fiable, ordonnée et peu fiable.

Depuis l'avènement de Bitcoin, le domaine de la blockchain a connu une croissance explosive. D'innombrables nouveaux réseaux ont émergé, chacun avec sa proposition de valeur unique, ses mécanismes de consensus, ses idéologies, ses partisans et ses raisons d'être. Avant l'introduction de l'IBC, ces blockchains fonctionnaient de manière indépendante, comme dans des conteneurs fermés, incapables de communiquer entre eux, un modèle fondamentalement insoutenable.

Si les blockchains sont considérées comme des pays avec des populations croissantes et des activités commerciales animées, certaines excellent dans l'agriculture, d'autres dans l'élevage. Naturellement, ils cherchent un commerce et une coopération mutuellement bénéfiques, en tirant parti de leurs forces respectives. Il n'est pas exagéré de dire que l'IBC a ouvert un nouveau monde de possibilités illimitées, permettant aux différentes blockchains d'interopérer, de transférer de la valeur, d'échanger des actifs et des services, et d'établir des connexions, sans être entravées par les problèmes de scalabilité inhérents aux grands réseaux de blockchain d'aujourd'hui.

Alors, comment l'IBC répond-il à ces besoins et joue-t-il un rôle aussi crucial? Les raisons fondamentales sont que l'IBC est:

1. Minimisation de la confiance

2. Capable de supporter des blockchains hétérogènes

3. Personnalisable au niveau de l'application

4. Une technologie mature et testée

La fondation du protocole IBC repose sur des clients légers et des relayers. Les chaînes A et B communiquant à travers l'IBC possèdent chacune des clients légers du grand livre de l'autre. La chaîne A, sans avoir besoin de faire confiance à un tiers, peut parvenir à un consensus sur l'état de la chaîne B en vérifiant ses en-têtes de bloc. Les chaînes interagissant via l'IBC (en particulier les modules) ne s'envoient pas directement des messages. Au lieu de cela, la chaîne A synchronise certains messages dans un paquet de données vers son état. Par la suite, les relayers détectent ces paquets de données et les transfèrent vers la chaîne cible.

Dans l'ensemble, le protocole IBC peut être divisé en deux couches : IBC TAO et IBC APP.

• IBC TAO: Définit les normes de transmission de paquets de données, d'authentification et de classement, essentiellement la couche d'infrastructure. Dans ICS (normes inter-chaînes), cela se compose de catégories de base, de client et de relais.

• APPLICATION IBC : Définit les normes pour les gestionnaires d'application des paquets de données transmis à travers la couche de transport. Cela inclut, sans toutefois s'y limiter, les transferts de jetons fongibles (ICS-20), les transferts de jetons non fongibles (ICS-721) et les comptes inter-chaînes (ICS-27), et peut être trouvé dans la catégorie d'application de l'ICS.

Protocole IBC (Du Portail des Développeurs de Cosmos)

Le protocole IBC (Inter-Blockchain Communication) est un pilier de la vision de l'écosystème Cosmos d'un 'Internet des blockchains'. Dans ce contexte, les choix de conception de l'IBC sont influencés par les normes TCP/IP. Tout comme TCP/IP définit des normes pour la communication entre ordinateurs, l'IBC spécifie un ensemble d'abstractions universelles qui permettent aux blockchains de communiquer entre elles. De la même manière que TCP/IP ne restreint pas le contenu des paquets de données relayés à travers le réseau, l'IBC fonctionne de la même manière. De plus, tout comme les protocoles d'application tels que HTTP et SMTP sont construits sur TCP/IP, les applications telles que les transferts d'actifs homogénéisés/non fongibles ou les appels de contrats intelligents inter-chaînes utilisent également le protocole IBC comme couche fondamentale.

Les principaux problèmes actuellement rencontrés avec le protocole IBC sont liés à la transmission des canaux et au traitement des paquets. Il y a eu d'importants problèmes de vérification de la preuve, mais ceux-ci sont relativement moins courants. Cet article met l'accent sur les problèmes courants du protocole IBC. Grâce à la conception modulaire du protocole IBC, les développeurs d'applications IBC n'ont pas besoin de se préoccuper des détails sous-jacents tels que les clients, les connexions et la vérification de la preuve. Cependant, ils doivent implémenter l'interface IBCModule et les méthodes de manipulation du gestionnaire correspondant. Par conséquent, de nombreux problèmes liés au protocole IBC apparaissent dans les chemins de code des interfaces IBCModule pour la réception et le traitement des paquets (onRecvPacket, OnAcknowledgementPacket, OnTimeoutPacket, etc.).

Classifications de vulnérabilités courantes

Dans l'écosystème Cosmos, le protocole IBC sert de hub de connexion. Les types de vulnérabilités associés au protocole IBC sont divers et complexes en raison de l'intégration étroite de ses implémentations avec des modules tels que Cosmos-SDK et CometBFT. De plus, comme l'IBC est principalement utilisé dans l'écosystème Cosmos, son langage de programmation principal est le Golang, comme détaillé dans la documentation ibc-go.

En raison de contraintes d'espace, cet article ne plonge pas dans une analyse détaillée de chaque aspect et composant du protocole IBC. Au lieu de cela, il classe certaines des vulnérabilités de sécurité existantes. Pour une analyse plus détaillée et complète, n'hésitez pas à contacter nos ingénieurs en sécurité CertiK pour en discuter.

Classifications courantes des vulnérabilités :

1. Vulnérabilités de dénomination

   ① Vulnérabilités de manipulation de chaîne

   ② Vulnérabilités de manipulation du bytecode

2. Vulnérabilités du processus de transmission

   ① Vulnérabilités de commande de paquets

   ② Vulnérabilités de délai d'expiration du paquet

   ③ Vulnérabilités d'authentification de paquet

   ④ Autres vulnérabilités de paquets

3. Vulnérabilités logiques

   ① Mises à jour des vulnérabilités de l'État

   ② Vulnérabilités de vote et de consensus

   ③ Autres vulnérabilités logiques

4. Vulnérabilités de la consommation de gaz

Le protocole IBC existant, en termes d'audit et d'analyse de sa sécurité, présente de nombreuses similitudes avec les processus d'audit des protocoles Web2. Cette analyse dissèquera certains des problèmes de sécurité et des risques potentiels du protocole IBC du point de vue de l'établissement du protocole, de sa mise en œuvre et de l'expansion de son application. Étant donné que la formulation du protocole est souvent achevée par quelques individus et organisations, pour diverses organisations blockchain, davantage de travail tourne autour de la mise en œuvre et de l'expansion de l'application du protocole. Par conséquent, cet article se concentrera sur les problèmes de sécurité de ces aspects. Cette approche découle de la prise en compte de la vaste gamme de risques de sécurité couverts par le protocole IBC, permettant une meilleure catégorisation des différents types de problèmes de sécurité selon les étapes et les modules correspondants.

Analyse de vulnérabilité

Formulation de la Protocole IBC

Étude de cas 1 : Protocole ICS-07, Vulnérabilité Logique

Contexte de la vulnérabilité : Utilisation incorrecte de la période de déliaison

Dans le code, la validation suivante existe :

si currentTimestamp.Sub(consState.Timestamp) >= clientState.UnbondingPeriod

Selon le modèle de sécurité Tendermint, pour un bloc (en-tête) au temps t, les validateurs de NextValidators doivent fonctionner correctement avant t+TrustingPeriod. Après cela, ils peuvent présenter d'autres comportements. Cependant, la vérification ici concerne UnbondingPeriod, et non TrustingPeriod, où UnbondingPeriod > TrustingPeriod. Si la date limite de consState est entre TrustingPeriod et UnbondingPeriod, alors cet en-tête sera accepté comme référence pour valider l'un des en-têtes conflictuels constituant un acte répréhensible. Pendant cette période, les validateurs de consState.NextValidators ne sont plus considérés comme dignes de confiance, et d'anciens validateurs hostiles peuvent fermer le client sans aucun risque.

Adresse du projet: https://github.com/cosmos/ibc/tree/e01da1d1346e578297148c9833ee4412e1b2f254/spec/ics-007-tendermint-client

Emplacement de la vulnérabilité :

• https://github.com/cosmos/ibc/tree/e01da1d1346e578297148c9833ee4412e1b2f254/spec/ics-007-tendermint-client#misbehaviour-predicate

• https://github.com/cosmos/cosmos-sdk/blob/6344d626db1fbdba5e0f67425703c1584021bf5b/x/ibc/light-clients/07-tendermint/types/misbehaviour_handle.go#L96

Extrait de code vulnérable :

fonction de définition de protocole

Code

Mise en œuvre du protocole IBC

La phase de mise en œuvre du protocole IBC est une phase où les problèmes sont susceptibles de survenir, car elle joue un rôle de pont critique. Elle doit non seulement éviter les ambiguïtés dans les spécifications du protocole, mais aussi fournir des interfaces de base et pratiques pour l'application ultérieure et l'extension du protocole. Par conséquent, les principaux problèmes à la phase de mise en œuvre du protocole IBC peuvent être davantage catégorisés en :

1. Ambiguïtés et problèmes non standard dans l'implémentation du protocole.

2. Erreurs dans les paramètres du protocole.

Ambiguïtés et problèmes non standard dans l'implémentation du protocole

Étude de cas 1: Protocole ICS-20, Vulnérabilité de dénomination

Contexte de la vulnérabilité : Conflit d'adresse de garde. GetEscrowAddress()la fonction génère un hachage tronqué SHA256 de 20 octets (ID de port + ID de canal). Cette méthode présente trois problèmes :

1. Manque de séparation de domaine entre les ports et les canaux. La méthode de concaténation de chaînes ne sépare pas les domaines du port et du canal. Par exemple, les combinaisons port/canal ("transfert", "canal") et ("trans", "ferchannel") donneront la même adresse de garde, c'est-à-dire le SHA256 tronqué ("transferchannel"). Si certains modules avec des fonctions de bibliothèque sont autorisés à sélectionner des identifiants de port et de canal, des vulnérabilités peuvent survenir.

2. Conflits entre les adresses de compte de module. Des chaînes alphanumériques arbitraires sont utilisées dans le pré-image du SHA-256, avec une taille de post-image de 160 bits. Cette petite post-image combinée à une fonction de hachage rapide rend une attaque par anniversaire faisable, car sa sécurité est réduite à seulement 80 bits. Cela signifie qu'environ 2^80 tentatives sont nécessaires pour trouver une collision entre deux adresses de compte d'entiercement différentes. En 2018, une analyse détaillée du coût de l'attaque de la troncature de SHA256 dans le contexte de Tendermint a été réalisée, prouvant qu'une telle attaque est réalisable d'un point de vue coût. Trouver une collision signifie que deux comptes d'entiercement différents sont mappés à la même adresse de compte. Cela pourrait entraîner des risques de vol de fonds sur les comptes d'entiercement. Pour plus de détails, voir le chevauchement de domaine d'image pré ICS20 GetEscrowAddress avec les clés publiquesT: BUG.

3. Conflits entre les adresses de compte module et non-module. La construction des adresses de compte public est la même que les clés publiques Ed25519 de 20 octets SHA-256. Bien que la sécurité de 160 bits soit suffisante pour prévenir les attaques de collision sur des adresses publiques spécifiques, la sécurité contre les attaques d'anniversaire n'est que de 80 bits. Cette situation est similaire à un mode d'attaque semi-anniversaire, où une adresse est générée par le rapide SHA-256, et l'autre adresse est générée par les calculs de clé publique Ed25519 relativement plus lents. Bien que cette situation soit plus sécurisée, elle expose encore à des attaques potentielles sur les comptes de garde et les comptes publics.

Adresse du projet: https://github.com/cosmos/ibc/tree/e01da1d1346e578297148c9833ee4412e1b2f254/spec/ics-020-fungible-token-transfer

Emplacement de la vulnérabilité : https://github.com/cosmos/cosmos-sdk/blob/6cbbe0d4ef90f886dfc356979b89979ddfcd00d8/x/ibc/applications/transfer/types/keys.go#L40-L47

https://github.com/cosmos/cosmos-sdk/blob/6cbbe0d4ef90f886dfc356979b89979ddfcd00d8/x/ibc/applications/transfer/keeper/relay.go

Extrait de code vulnérable :

Problème de configuration du protocole d'erreur

• Cas 1 : Avis de sécurité IBC Dragonberry, vulnérabilité du processus de transmission

Contexte de la vulnérabilité : IBC utilisera une structure de paquet lors du traitement des paquets de données d'application. Selon le mécanisme de temporisation, les mécanismes de confirmation synchrone et asynchrone et le processus de vérification de certification correspondant, le paquet de données sera divisé en deux processus d'exécution :

1. Situation normale : Succès dans le délai d’attente

2. Situation de délai d'attente : échec de délai d'attente

Schéma de flux de transmission de paquet d'application IBC

Lorsqu’un délai d’attente se produit, cela signifie que la transmission a échoué et que le protocole IBC lance un processus de remboursement. Il convient de noter que l’IBC dispose d’un mécanisme de délai d’expiration configurable par l’utilisateur. La vulnérabilité Dragonberry provient d’ICS-23 (IBC). La cause première de cette vulnérabilité est que les utilisateurs peuvent falsifier des preuves d’inexistence dans le processus de vérification (c’est-à-dire de fausses preuves qu’aucun paquet de données n’a été reçu), contournant ainsi les contrôles de sécurité et falsifiant Une situation de délai d’expiration IBC « raisonnable » est utilisée pour tromper le protocole IBC, ce qui amène le répéteur à envoyer des paquets de délai d’expiration avec de faux certificats, et peut dégénérer en un problème de double dépense ICS-20. Le processus de déclenchement spécifique de la vulnérabilité peut être vu dans la figure ci-dessous.

Principe de vulnérabilité Dragonberry diagramme de flux

Adresse du projet: https://github.com/cosmos/ibc-go/tree/00a680cda52690a4ba835bf37f53acc41c01bc7a/modules/core/04-channel

Emplacement de la vulnérabilité : https://github.com/cosmos/ibc-go/blob/00a680cda52690a4ba835bf37f53acc41c01bc7a/modules/core/04-channel/keeper/timeout.go#L117C28-L117C54

Extrait de code vulnérable :

• Cas 2: Avis de sécurité IBC Huckleberry, vulnérabilité du processus de transmission

Contexte de vulnérabilité : UnreceivedPackets ne construit une réponse qu'en trouvant le reçu de paquet correspondant à chaque numéro de séquence inclus dans la requête. Cela ne fonctionne que pour les canaux désordonnés, car les canaux ordonnés utilisent nextSequenceRecv au lieu des reçus de paquets. Par conséquent, sur un canal ordonné, interroger le numéro de séquence via GetPacketReceipt ne trouvera pas le reçu à l'intérieur de celui-ci.

La gravité de ce problème est mineure car le canal transmis par l'ICS-20 FT est principalement hors service et le répéteur ne dépend pas de ce point de terminaison grpc pour déterminer quels paquets déclenchent le délai d'attente. Cependant, s'il y a un grand nombre de paquets dans la chaîne cible, et que le canal ordonné est configuré pour la transmission IBC, et que la réponse grpc n'est pas paginée, cela créera un risque de dégradation des performances du nœud de service voire de crash. Le processus de déclenchement spécifique peut être vu dans la figure ci-dessous.

Schéma de flux de principe de vulnérabilité de Huckleberry

Adresse du projet :https://github.com/cosmos/ibc-go/blob/11297aaa61e651c16e6d4147a15be24ce55ba7cc/modules/core/04-channel/

Emplacement de la vulnérabilité: https://github.com/cosmos/ibc-go/blob/11297aaa61e651c16e6d4147a15be24ce55ba7cc/modules/core/04-channel/keeper/grpc_query.go#L408

Extrait de code vulnérable :

Application et extension du protocole IBC

• Cas 1: vulnérabilité de largage aérien de stride, vulnérabilité logique

Contexte de vulnérabilité: La fonction TryUpdateAirdropClaimconvertit l'adresse de l'expéditeur d'un paquet IBC en une adresse Stride nommée adresseStrideExpéditeur, et extrait airdropIdet la nouvelle adresse de largage aérien nouvelleAdresseStridedes métadonnées du paquet. Il appelle ensuite Mettre à jour l'adresse de largage aérienmettre à jour leadresseStrideExpéditeuretClaimRecordAvec la mise à jour de la RéclamationEnregistrement, nouvelleAdresseStridepourra réclamer l'airdrop. Cependant, cette fonction de mise à jour vérifie uniquement si l'adresse de l'expéditeur de la demande est vide et ne valide pasnouvelleAdresseStride. Étant donné que l’IBC permet aux connexions de machines individuelles d’implémenter des chaînes compatibles IBC, cela présente un risque de sécurité lorsqu’il est possible de mettre à jour toute autre adresse de compte en tant qu’adresse de largage.

Adresse du projet : https://github.com/Stride-Labs/stride/tree/3a5c7bfcc3b8c5e7dd870f01bebeb9d949492203/x/autopilot

Emplacement de la vulnérabilité : https://github.com/Stride-Labs/stride/blob/3a5c7bfcc3b8c5e7dd870f01bebeb9d949492203/x/autopilot/module_ibc.go#L119

https://github.com/Stride-Labs/stride/blob/3a5c7bfcc3b8c5e7dd870f01bebeb9d949492203/x/autopilot/keeper/airdrop.go#L17

Extrait de code vulnérable :

• Cas 2 : vulnérabilité du module ibc neutron, vulnérabilité de la consommation de gaz

Contexte de la vulnérabilité : Dans le contexte des contrats intelligents, il y a un problème avec la vérification des frais pour confirmer ou dépasser les événements IBC (Communication Inter-Blockchain). Cette faille permet aux contrats intelligents malveillants de déclencher un crash 'ErrorOutOfGas'. Ce crash se produit lors du traitement des messages 'OnAcknowledgementPacket' et 'OnTimeoutPacket'. Lorsque cette erreur se produit, il n'est pas possible de la résoudre par la méthode habituelle de 'récupération de gaz épuisé'. En conséquence, les transactions affectées échouent à être incluses dans le bloc de la blockchain. Cet échec peut entraîner les relais IBC à tenter à plusieurs reprises de soumettre ces messages. De telles soumissions répétées pourraient entraîner des pertes financières pour les relais et surcharger le réseau avec un nombre excessif de paquets non traités ('abandonnés'), ce qui représente un risque pour la stabilité du réseau.

Adresse du projet : https://github.com/neutron-org/neutron/blob/64868908b21f648ad5e8a9b48179134619544e2a/

Emplacement de la vulnérabilité :

https://github.com/neutron-org/neutron/blob/64868908b21f648ad5e8a9b48179134619544e2a/x/interchaintxs/keeper/ibc_handlers.go#L62

Extrait de code vulnérable :

Résumé

L'analyse et la discussion des problèmes de sécurité liés au protocole de communication inter-blockchains (IBC), tels qu'ils sont présentés dans le texte précédent, mettent en lumière la nature étendue et variée de ces préoccupations. Les principaux défis semblent provenir principalement de la phase de mise en œuvre et de l'expansion des applications utilisant le protocole IBC. Alors que diverses chaînes d'application améliorent progressivement et affinent leurs fonctionnalités de module traditionnel, elles intègrent simultanément des implémentations de code diverses dans leurs modules IBC. Cela est fait pour améliorer les performances et répondre aux exigences commerciales spécifiques.

En plus des problèmes de sécurité mentionnés précédemment dans le composant IBC, de nouveaux défis émergent, en particulier dans le middleware IBC. Ces préoccupations évolutives devraient devenir de plus en plus importantes à l'avenir, notamment en ce qui concerne la sécurité globale de l'écosystème Cosmos. Ce changement indique un accent croissant sur la garantie de mesures de sécurité robustes dans le module IBC.

Conclusion

Notre enquête sur la sécurité de l'écosystème Cosmos, impliquant des audits détaillés, des synthèses et des catégorisations, s'est centrée sur ses deux composants les plus critiques : le Cosmos SDK et le protocole IBC. En s'appuyant sur notre vaste expérience pratique, nous avons compilé une collection complète d'expertise générale en audit.

Ce rapport souligne les défis uniques posés par un réseau hétérogène comme Cosmos, surtout compte tenu de son support pour les interactions inter-chaînes. La complexité et la nature dispersée de ses composants rendent la tâche d'assurer leur sécurité redoutable. Cela nécessite non seulement d'appliquer nos connaissances existantes sur les risques de sécurité, mais aussi de s'adapter à de nouveaux scénarios de sécurité pour résoudre les problèmes émergents.

Malgré ces obstacles, nous sommes optimistes. En documentant et en analysant les scénarios courants et les défis en matière de sécurité, comme nous l'avons fait dans ce rapport, nous ouvrons la voie à l'amélioration progressive du cadre de sécurité global au sein du diversifié Cosmos écosystème.

Avertissement：

1. Cet article est repris de [GateCertiK]. Tous les droits d'auteur appartiennent à l'auteur original [CertiK]. Si des objections sont faites à cette republication, veuillez contacter le Porte Apprendrel'équipe, et ils s'en occuperont rapidement.
2. Responsabilité déniée: Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, il est interdit de copier, distribuer ou plagier les articles traduits.