O ecossistema Cosmos, mundialmente conhecido como uma das maiores e mais notáveis redes blockchain, prioriza a interoperabilidade blockchain. Este foco é fundamental para facilitar a comunicação contínua entre diversas blockchains. O ecossistema é lar de vários projetos líderes como Celestia e dYdX v4, todos desenvolvidos usando o Cosmos SDK e o protocolo IBC. A crescente preferência dos desenvolvedores pelos componentes do Cosmos tem levado a um impacto ampliado de questões de segurança dentro do ecossistema. Um exemplo é a vulnerabilidade do Dragonfruit no Cosmos SDK, que perturbou operações em inúmeras blockchains públicas mainstream.

Dada a natureza descentralizada dos componentes principais do Cosmos, os desenvolvedores muitas vezes precisam adaptar e estender esses componentes com base em necessidades funcionais específicas. Isso leva a uma fragmentação dos desafios de segurança dentro do ecossistema Cosmos. Consequentemente, há uma necessidade premente de uma abordagem estruturada para compreender e abordar essas preocupações de segurança. Este artigo tem como objetivo fornecer uma análise abrangente da paisagem de segurança atual no ecossistema Cosmos e delinear estratégias de resposta eficazes.

A equipa CertiK está empenhada em reforçar a segurança da rede Cosmos e do ecossistema mais amplo da Web3 através de investigação e desenvolvimento contínuos. Estamos entusiasmados por partilhar os nossos resultados e perceções convosco através de relatórios de segurança regulares e atualizações de pesquisa técnica. Se tiver alguma dúvida, a nossa equipa está sempre disponível para contacto.

Aqui está o texto completo do “Guia de Segurança do Ecossistema Cosmos” 👇.

Visão Geral do Cosmos

Considerado como um dos ecossistemas blockchain mais proeminentes do mundo, o Cosmos destaca-se pelas suas capacidades de rede de código aberto, escalável e interligada. Desenvolvido pela equipa CometBFT, originalmente conhecida como Tendermint, o Cosmos tem como objetivo eliminar silos de informação e facilitar a interoperabilidade entre blockchains diversas. Num período em que múltiplas redes blockchain coexistem, a necessidade de interação entre cadeias é mais premente do que nunca.

O Cosmos distingue-se por oferecer um modelo de interligação eficiente, especialmente benéfico para cadeias públicas com focos verticais específicos. Sua infraestrutura modular de blockchain capacita os desenvolvedores de aplicativos, proporcionando-lhes a flexibilidade para selecionar e utilizar cadeias públicas que estejam alinhadas com seus requisitos específicos.

No centro do ecossistema Cosmos está o Protocolo de Comunicação Inter-Blockchain (IBC), que conecta aplicações e protocolos em diferentes blockchains independentes. Isso não só facilita a transferência contínua de ativos e dados, mas também se alinha com a visão da Cosmos de criar uma 'internet de blockchains'. Este conceito idealiza uma vasta rede de blockchains autônomas e facilmente desenvolvidas, interligadas para expansão e interação.

Envolvimento e Pesquisa da CertiK na Segurança da Cosmos

Por um longo período, a CertiK tem estado profundamente envolvida na pesquisa do ecossistema Cosmos. Nossa equipe adquiriu uma experiência substancial em lidar com desafios de segurança dentro deste ambiente. Neste relatório, compartilharemos nossas visões e descobertas sobre a segurança do ecossistema Cosmos, focando em quatro áreas-chave: segurança do Cosmos SDK, segurança do protocolo IBC, segurança do CometBFT e segurança do CosmWasm. Nossa discussão abrangerá tudo, desde os componentes fundamentais do ecossistema Cosmos até suas cadeias fundamentais e de aplicação. Ao examinar e extrapolar questões relacionadas, pretendemos apresentar uma análise abrangente, de baixo para cima, dos aspectos críticos de segurança dentro do ecossistema Cosmos.

Dada a complexidade e diversidade do ecossistema Cosmos, ele enfrenta um amplo espectro de desafios de segurança. Este relatório concentra-se principalmente nas ameaças mais características e significativas para a cadeia ecológica da Cosmos. Para mais informações ou discussões sobre outros aspetos de segurança, encorajamos a contactar os engenheiros de segurança da CertiK.

Antecedentes

CometBFT: Melhorando a escalabilidade intercadeias no seu núcleo

No centro da escalabilidade da Interchain está o CometBFT, um algoritmo de consenso de ponta essencial para garantir a segurança, descentralização e integridade do ecossistema Interchain. Este algoritmo é composto por dois componentes principais: o núcleo do CometBFT, que atua como o motor de consenso fundamental, e uma interface universal de blockchain de aplicação (ABCI). Ao combinar elementos de PBFT (Tolerância a Falhas Bizantinas Práticas) e Prova de Participação Garantida (PoS), o CometBFT sincroniza nós para manter registros precisos de transações, desempenhando assim um papel crucial no consenso do validador dentro do ambiente Interchain.

Cosmos SDK: Acelerando o Desenvolvimento Blockchain com Modularidade

O Cosmos SDK destaca-se como um conjunto de ferramentas poderoso que simplifica e acelera o desenvolvimento de blockchain. Seu design modular e recursos plugáveis capacitam os desenvolvedores a construir suas próprias blockchains ou componentes funcionais sobre o algoritmo de consenso CometBFT. Esta abordagem não só facilita o desenvolvimento, mas também encurta significativamente o ciclo de desenvolvimento. A eficácia do SDK é evidenciada pela sua adoção em inúmeros projetos, incluindo Cronos, Kava e o recentemente lançado dYdX V4. Olhando para o futuro, o Cosmos SDK planeja aprimorar sua modularidade e introduzir novos recursos, permitindo a criação de aplicativos mais sofisticados e modulares, nutrindo assim um ecossistema mais amplo e robusto.

Protocolo IBC: Impulsionando a Interoperabilidade e a Escalabilidade entre Blockchains

O protocolo de Comunicação Inter-Blockchain (IBC) é fundamental para facilitar a transferência de dados segura, descentralizada e sem permissão entre blockchains dentro da rede Cosmos. Dado que o Cosmos é uma rede descentralizada composta por múltiplas blockchains independentes e paralelas conectadas através da tecnologia de relé, o papel do protocolo IBC em melhorar a escalabilidade e interoperabilidade é central. O foco atual da Fundação Interchain está em melhorar esses aspectos do protocolo IBC, com o objetivo de reforçar interações sem falhas entre blockchains, aplicações e contratos inteligentes dentro do ecossistema Cosmos.

CosmWasm: Facilitando a Implementação de Aplicações Descentralizadas

CosmWasm (Cosmos WebAssembly) é um quadro de contrato inteligente adaptado para o ecossistema Cosmos. Com base em WebAssembly, permite aos desenvolvedores implantar aplicações descentralizadas sem precisar de permissões específicas. Este quadro permite aos desenvolvedores de blockchain desacoplar o desenvolvimento do produto do desenvolvimento do blockchain, reduzindo o fardo nas atualizações do validador. As funcionalidades do CosmWasm incluem uma arquitetura modular, integração com o Cosmos SDK e capacidades de comunicação entre cadeias. O Cosmos SDK e o protocolo IBC, sendo relativamente maduros, são amplamente utilizados no atual ecossistema Cosmos.

Adaptar e Personalizar dentro do Ecossistema Cosmos

Para os desenvolvedores de cadeias no ecossistema Cosmos, o Cosmos SDK satisfaz a maioria das necessidades de personalização. Durante as atividades de intercadeia, os desenvolvedores de cadeias podem adaptar seus módulos IBC para operações especiais ou otimização de desempenho. Enquanto algumas cadeias modificam motores subjacentes como o CometBFT Core, as restrições de espaço impedem uma discussão detalhada de tais modificações neste relatório. Portanto, esta pesquisa foca principalmente nas nuances técnicas e considerações de segurança do Cosmos SDK e do protocolo IBC.

Guia de Segurança do Cosmos SDK

O Guia de Segurança do Cosmos SDK fornece uma visão abrangente dos aspectos de segurança do Cosmos SDK, uma estrutura avançada para o desenvolvimento de aplicações blockchain e protocolos descentralizados. Criado pela Fundação Interchain, este framework é fundamental para a rede Cosmos, que é uma rede ampla de blockchains interconectadas.

No seu âmago, o Cosmos SDK é projetado para simplificar a criação de aplicações de blockchain personalizadas, ao mesmo tempo que facilita a interação contínua entre diversas blockchains. As suas características notáveis incluem uma estrutura modular, extensa capacidade de personalização, integração com o CometBFT Core para consenso e a implementação de interfaces IBC, todas contribuindo para o seu apelo aos desenvolvedores. Uma das principais vantagens do Cosmos SDK é a sua dependência do mecanismo de consenso CometBFT Core, que fornece robustas medidas de segurança. Este mecanismo desempenha um papel vital na defesa da rede contra ataques maliciosos e na proteção dos ativos e dados dos utilizadores. A natureza modular do SDK capacita os utilizadores a criar módulos personalizados com facilidade. No entanto, os desenvolvedores devem permanecer vigilantes, pois vulnerabilidades de segurança ainda podem surgir ao implantar aplicações usando o Cosmos SDK.

Do ponto de vista da auditoria de segurança, é essencial avaliar minuciosamente as potenciais ameaças de segurança a partir de múltiplas perspetivas. Pelo contrário, na pesquisa de segurança, a ênfase desloca-se para identificar vulnerabilidades que poderiam ter repercussões significativas. Esta abordagem visa mitigar rapidamente as principais ameaças de segurança, oferecendo assim uma assistência mais eficaz aos serviços que integram o SDK. É crucial identificar e examinar vulnerabilidades que representam riscos severos e têm amplas implicações.

Um ponto focal dentro do Cosmos SDK é a interface ABCI, que é fundamental para o ecossistema Cosmos. Esta interface é composta por quatro componentes-chave: BeginBlock, EndBlock, CheckTx e DeliverTx. BeginBlock e EndBlock estão diretamente envolvidos na lógica de execução de blocos individuais. Em contraste, CheckTx e DeliverTx estão preocupados com o processamento de sdk.Msg, a estrutura de dados fundamental para a transmissão de mensagens dentro do ecossistema Cosmos.

Para compreender e abordar as vulnerabilidades de segurança mencionadas, é primeiro necessário compreender o ciclo de vida da transação no ecossistema Cosmos. As transações originam-se de agentes de usuário, onde são criadas, assinadas e depois transmitidas para os nós blockchain. O método CheckTx é utilizado pelos nós para validar os detalhes da transação, como assinaturas, saldo do remetente, sequência da transação e o gás fornecido. Transações válidas são enfileiradas no mempool, aguardando inclusão em um bloco, enquanto as inválidas são rejeitadas, com mensagens de erro transmitidas aos usuários. Durante o processamento do bloco, o método DeliverTx é aplicado para garantir consistência e determinismo transacionais.

No Cosmos SDK, o ciclo de vida da transação é um processo de várias etapas, que abrange a criação, validação, inclusão num bloco, alterações de estado e compromisso final. Este processo pode ser delineado nos seguintes passos:

1. Criação de Transação: Os utilizadores geram transações utilizando várias ferramentas, como Interfaces de Linha de Comando (CLI) ou clientes de interface.

2. Adição à Mempool: Uma vez criadas, as transações entram na mempool. Aqui, os nós enviam uma mensagem ABCI (Interface BlockChain da Aplicação), conhecida como CheckTx, para a camada de aplicação para verificação de validade. As transações passam por uma descodificação do formato byte para o formato Tx. Cada sdk.Msg dentro da transação é sujeito a verificações preliminares sem estado pela função ValidateBasic(). Além disso, se a aplicação incluir um anteHandler, a sua lógica é executada antes da função runTx, que leva à função RunMsgs() para processamento do conteúdo sdk.Msg. O sucesso do CheckTx resulta na transação ser colocada na mempool local, pronta para ser incluída no próximo bloco, e simultaneamente transmitida para os nós pares via P2P.

3. Inclusão num Bloco Proposto: Durante o início de cada rodada, o proponente monta um bloco contendo transações recentes. Os validadores, que são responsáveis pela manutenção do consenso, aprovam este bloco ou optam por um bloco vazio.

4. Mudanças de Estado: Semelhante ao CheckTx, o processo DeliverTx itera através das transações de bloco. No entanto, opera no modo 'Deliver', executando alterações de estado. O MsgServiceRouter direciona mensagens de transação diferentes para módulos específicos, onde cada mensagem é processada no Msg Server. Após a execução da mensagem, verificações adicionais garantem a validade da transação. Se alguma verificação falhar, o estado reverte para a sua condição anterior. Um medidor de gás acompanha o gás consumido durante a execução. Erros relacionados com o gás, como gás insuficiente, levam a uma reversão das alterações de estado, semelhante a falhas de execução.

5. Compromisso de Bloqueio: Após receber votos suficientes do validador, um nó compromete o novo bloco à blockchain. Esta ação finaliza as transições de estado na camada de aplicação, marcando a conclusão do processo de transação.

)

[Esta secção inclui um diagrama que representa o ciclo de vida das transações no ecossistema Cosmos.]

[A seguinte seção fornece a lógica de execução específica da chave ABCI no Cosmos SDK, útil para entender e analisar as vulnerabilidades discutidas posteriormente.]

)

Categorias Comuns de Vulnerabilidades

Antes de entender a classificação das vulnerabilidades, precisamos ter uma divisão básica do nível de perigo das vulnerabilidades. Isso ajuda a identificar melhor as vulnerabilidades de segurança de alto risco e evitar possíveis riscos de segurança.

)

Considerando o nível de perigo e o alcance do impacto, focamos principalmente em vulnerabilidades de segurança classificadas como Críticas e Principais, que geralmente podem causar os seguintes riscos:

1. Operação de paragem da cadeia
2. Perda financeira
3. Afetando o estado do sistema ou a operação normal

As causas destes perigos são frequentemente os seguintes tipos de vulnerabilidades de segurança:

1. Negação de Serviço
2. Definições de estado incorretas
3. Falta de verificação ou verificação irrazoável
4. Problemas de singularidade
5. Problemas de algoritmo de consenso
6. Falhas lógicas na implementação
7. Questões de recursos de idioma

Análise de Vulnerabilidades no Ecossistema Cosmos

O ecossistema Cosmos, conhecido por sua estrutura modular, frequentemente encontra inter-uso e inter-chamadas de módulos dentro de suas cadeias. Essa complexidade leva a cenários onde o caminho de acionamento da vulnerabilidade e as variáveis de localização são inconsistentes. Ao entender essas vulnerabilidades, é crucial não apenas considerar o caminho de acionamento, mas também o caminho controlável das variáveis críticas da vulnerabilidade. Esse foco duplo auxilia na melhor definição e categorização do modelo de vulnerabilidade.

Operação de Paragem de Corrente: Causas e Tipos

As paragens de cadeia são tipicamente devidas a problemas encontrados durante a execução de um único bloco. No entanto, a história da Cosmos inclui casos em que vulnerabilidades de segurança de consenso necessitaram de paragens ativas da cadeia para reparos. Estes problemas caem em duas categorias distintas.

O primeiro tipo é comumente visto em Vulnerabilidades de Negação de Serviço: Estas são frequentemente o resultado de tratamento de falhas inadequado e operações de limite de loop influenciadas pelo usuário. Tais vulnerabilidades podem levar à pausa ou desaceleração significativa da cadeia.

Cosmos SDK e CometBFT, infraestruturas-chave no ecossistema Cosmos, são utilizados não apenas pelas cadeias base no Cosmos, mas também por várias cadeias de aplicações com base na sua arquitetura. Todas elas seguem as regras de interface ABCI do CometBFT. O foco da sua superfície de ataque também incide sobre a sua interface ABCI, e a maioria das vulnerabilidades de segurança que podem causar a paragem da cadeia são problemas que podem afetar diretamente a execução do código do bloco. Portanto, os caminhos de ocorrência podem geralmente ser rastreados até às interfaces BeginBlock e EndBlock.

O segundo tipo de situação envolve Vulnerabilidades que Afetam o Consenso: Estas frequentemente estão relacionadas com a implementação em várias cadeias e incluem questões na validação do processamento lógico, calibração do tempo e aleatoriedade. Estas vulnerabilidades atingem o cerne do princípio de descentralização da blockchain. Embora possam não parecer graves inicialmente, nas mãos de um ator malicioso, representam uma ameaça à segurança substancial.

Exemplos do Primeiro Tipo

Exemplo 1: Análise de Vulnerabilidades do Projeto SuperNova

Antecedentes da vulnerabilidade: No processo de distribuição de cunhagem dentro do Projeto SuperNova, surge um problema crítico devido à ausência de verificação de endereço. Esta falha pode levar a falhas de funcionamento e, consequentemente, a perdas financeiras. Especificamente, o módulo de cunhagem, crucial para a geração de tokens, depende do montante apostado. No entanto, este processo é suscetível a erros. Por exemplo, se o pool designado não existir ou se houver uma entrada errada do endereço do contrato, pode levar a disfunções no módulo de cunhagem. Tais erros têm o potencial de interromper toda a operação da blockchain. Além disso, no módulo de pool de recompensas, há uma falta de verificação para o endereço do contrato do pool. Esta falha significa que qualquer falha na operação de distribuição poderia causar uma paragem imediata na blockchain.

Localização da vulnerabilidade: SuperNova GitHub Link

Trecho de código vulnerável:

Caminho de acionamento da vulnerabilidade:

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

Guardião.DistribuirMoedaCunhada

Keeper.distributeLPIncentivePools

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

Patch de vulnerabilidade:

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

O patch está localizado no módulo de tratamento de mensagens do poolincentive (x/poolincentive/types/msgs.go), não no módulo de cunhagem. Foi adicionada verificação de endereço à mensagem MsgCreateCandidatePool para eliminar a possibilidade de endereços incorretos a partir da raiz.

Exemplo 2: Projeto de Segurança Interchain Cosmos

Endereço do projeto: Link do GitHub Cosmos Interchain Security

Antecedentes da vulnerabilidade: Os validadores podem atrasar a cadeia do fornecedor ao enviar várias mensagens AssignConsumerKey no mesmo bloco. No arquivo x/ccv/provider/keeper/key_assignment.go, a função AssignConsumerKey permite que os validadores atribuam diferentes consumerKeys a cadeias de consumidores aprovadas. A AddressList consumerAddrsToPrune aumenta em um elemento para realizar esta operação. Uma vez que esta AddressList é iterada no EndBlocker em x/ccv/provider/keeper/relay.go, os atacantes podem explorá-la para atrasar a cadeia do fornecedor. Para este ataque, o ator malicioso pode criar transações com várias mensagens AssignConsumerKey e enviá-las para a cadeia do fornecedor. A cardinalidade da AddressList consumerAddrsToPrune será a mesma que as mensagens AssignConsumerKey enviadas. Portanto, a execução do EndBlocker levará mais tempo e recursos do que o esperado, atrasando ou até mesmo parando a cadeia do fornecedor.

Localização da vulnerabilidade: Cosmos Interchain Security Link do GitHub

Segmento de Código de Vulnerabilidade:

Caminho de acionamento da vulnerabilidade:

msgServer.AssignConsumerKey

Keeper.AssignConsumerKey

AppModule.EndBlock

EndBlockCIS

HandleLeadingVSCMaturedPackets

HandleVSCMaturedPacket

PruneKeyAssignments

Exemplo 3: Projeto Quicksilver - Módulo de Airdrop

Antecedentes da vulnerabilidade: BeginBlocker e EndBlocker são métodos opcionais que os desenvolvedores de módulos podem implementar em seus módulos. Eles são acionados no início e no final de cada bloco, respectivamente. Usar crashes para lidar com erros nos métodos BeginBlock e EndBlock pode fazer com que a cadeia pare em caso de erros. O EndBlocker não considerou se o módulo tinha tokens suficientes para liquidar airdrops inacabados, o que poderia desencadear um crash e parar a cadeia.

Localização da vulnerabilidade: Quicksilver GitHub Link

Segmento de código de vulnerabilidade:

Patch de vulnerabilidade: AppModule.EndBlock

Guardião.Finalizador

Keeper.EndZoneDrop

Patch de vulnerabilidade: https://github.com/quicksilver-zone/quicksilver/blob/20dc658480b1af1cb323b4ab4a8e5925ee79a0ed/x/airdrop/keeper/abci.go#L16

O código de tratamento de pânico foi removido e substituído pelo registo de erros.

Exemplo 4: Projeto de Segurança Interchain Cosmos

Endereço do projeto: Cosmos Interchain Security GitHub Link

Antecedentes da vulnerabilidade: Os atacantes podem realizar um ataque de Negação de Serviço enviando múltiplos tokens para o endereço de recompensa da cadeia do provedor. No fluxo de execução do EndBlocker da cadeia do consumidor, a função SendRewardsToProvider definida em x/ccv/consumer/keeper/distribution.go recupera o saldo de todos os tokens em tstProviderAddr e os envia para a cadeia do provedor. Para conseguir isso, é necessário iterar por todos os tokens encontrados no endereço de recompensa e enviá-los via IBC para a cadeia do provedor. Como qualquer pessoa pode enviar tokens para o endereço de recompensa, os atacantes podem criar e enviar um grande número de tokens de denom diferentes, por exemplo, usando uma cadeia com um módulo de fábrica de tokens, para iniciar um ataque de Negação de Serviço. Portanto, a execução do EndBlocker levará mais tempo e recursos do que o esperado, atrasando ou até mesmo parando a cadeia do consumidor.

Localização da vulnerabilidade: Link do GitHub da Segurança Interchain da Cosmos

Segmento de Código de Vulnerabilidade:

Caminho de acionamento da vulnerabilidade:

AppModule.EndBlock

EndBlock

EndBlockRD

EnviarRecompensasAoFornecedor

Segundo Tipo de Situação

Este tipo de questão de consenso pode não trazer um dano grave imediato, mas ao considerar os princípios fundamentais e o sistema de toda a blockchain, ou ao analisar essas vulnerabilidades a partir de cenários específicos, o seu impacto e dano pode não ser inferior ao de outras vulnerabilidades convencionais. Além disso, essas vulnerabilidades têm características comuns.

Exemplo 1

Antecedentes da vulnerabilidade: Aviso de segurança Cosmos SDK Jackfruit

Comportamento não determinístico no método ValidateBasic do módulo x/authz no Cosmos SDK pode facilmente levar a uma paragem de consenso. A estrutura de mensagem MsgGrant no módulo x/authz inclui um campo de concessão, que contém o tempo de expiração concedido pela autorização definida pelo utilizador. No processo de validação do ValidateBasic() na estrutura de concessão, compara as informações de tempo com as informações de tempo locais do nó em vez das informações de tempo do bloco. Como o tempo local é não determinístico, os carimbos de tempo podem diferir entre os nós, levando a problemas de consenso.

Anúncio de vulnerabilidade:

• Cosmos Fórum Link 1

• Link do Fórum Cosmos 2

• Link de Aviso de Segurança do GitHub do Cosmos SDK

Segmento de Código de Vulnerabilidade:

Pacote de correcção de vulnerabilidades: Link de Comparação do Cosmos SDK GitHub

Problemas como carimbos de data/hora não aparecem apenas em componentes fundamentais como o Cosmos SDK, mas também ocorreram em várias cadeias de aplicativos.

Exemplo 2

Antecedentes da vulnerabilidade: SuperNova, projeto nova

Endereço do projeto: SuperNova GitHub Link

Ao usar time.Now() é devolvido o timestamp do sistema operativo. O tempo local é subjetivo e, portanto, não determinístico. Como pode haver pequenas diferenças nos timestamps dos nós individuais, a cadeia pode não atingir consenso. No módulo ICAControl, a função de envio de transações utiliza time.Now() para obter o timestamp.

Localização da vulnerabilidade: https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/icacontrol/keeper/send_msgs.go#L14

Segmento de Código de Vulnerabilidade:

Pacote de correção de vulnerabilidades:

Alterado de usar timestamp local para usar o tempo de bloco.

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))

Caso Três:

Antecedentes da Vulnerabilidade: Módulo Oracle no Projeto BandChain

URL do projeto: Repositório do GitHub da BandChain

Os comentários no repositório de código indicam que o módulo oracle deve ser executado antes da aposta para implementar medidas de punição para os infratores do protocolo oracle. No entanto, no código, a sequência é invertida: na função SetOrderEndBlockers, o módulo de staking é executado antes do módulo oracle. Se o módulo de staking for executado antes do módulo oracle, seria impossível aplicar penalidades com base nas verificações concluídas no módulo oracle.

Localização da Vulnerabilidade: Trecho de código do GitHub da BandChain

Segmento de Código de Vulnerabilidade:

A vulnerabilidade reside na implementação real e nos comentários contraditórios, onde o módulo do oráculo deve ser colocado antes do módulo de staking.

Caso Quatro:

Antecedentes da Vulnerabilidade: Módulo de Controle de Acesso no Projeto Sei Cosmos

URL do projeto: Veja o Repositório GitHub da Cosmos

Em várias instâncias nos repositórios de código relacionados ao Cosmos, há o uso do tipo de mapa da linguagem Go e a iteração sobre ele. Devido à natureza não determinística da iteração de mapas do Go, isso poderia levar a nós atingindo estados diferentes, potencialmente causando problemas de consenso e consequentemente interrompendo o funcionamento da cadeia. Um método mais apropriado seria ordenar as chaves do mapa em uma fatia e iterar sobre as chaves ordenadas. Tais problemas são comuns, decorrentes da aplicação de recursos da linguagem.

Na implementação do BuildDependencyDag em x/accesscontrol/keeper/keeper.go, há iteração sobre os nós anteDepSet. Devido ao comportamento não-determinístico da iteração de mapas em Go, ValidateAccessOp poderia resultar em dois tipos diferentes de erros, potencialmente levando a uma falha de consenso.

Localização da Vulnerabilidade: Snippet de Código do GitHub do Cosmos

Segmento de Código de Vulnerabilidade:

Dos casos apresentados, é evidente que as vulnerabilidades que levam a uma cadeia parar de funcionar passivamente são frequentemente as mais prejudiciais. A sua lógica causal pode ser rastreada até afetar diretamente o fluxo de execução de blocos individuais numa blockchain. Por outro lado, as vulnerabilidades de segurança de consenso normalmente resultam na cadeia parar ativamente para implementar correções, com a sua lógica causal rastreada até afetar o fluxo operacional geral e o estado da blockchain. Isto difere do foco das vulnerabilidades que levam a perdas financeiras, onde o impacto perigoso específico não é avaliado com base no caminho lógico da ocorrência do problema, mas sim se concentra nos proprietários dos fundos, na quantidade de dinheiro envolvida, no alcance e nos métodos que afetam os fundos.

perda de fundos

Questões de perda de capital são comumente vistas no manuseio lógico de mensagens sdk.Msg e IBC. Claro, também existem algumas vulnerabilidades que podem causar perda de capital entre as razões que podem interromper a operação de uma blockchain. O impacto específico depende da vulnerabilidade particular, e aqui nos concentramos na primeira. Além disso, uma vez que o IBC é um componente muito importante do ecossistema Cosmos, envolve inevitavelmente algumas vulnerabilidades no IBC. Detalhes sobre a superfície de ataque do IBC e as vulnerabilidades correspondentes serão discutidos no próximo capítulo.

As perdas de capital são comumente encontradas em cenários como consumo de gás, fundos bloqueados e incapazes de serem retirados, perda de fundos durante transferência, erros na lógica de computação levando à perda de fundos, e falha em garantir a singularidade dos IDs de armazenamento de fundos.

Aqui, tomamos o projeto SuperNova como exemplo para analisar três vulnerabilidades relacionadas.

Antecedentes da Vulnerabilidade: Projeto SuperNova

URL do projeto: https://github.com/Carina-labs/nova

Se os lugares decimais numa zona excederem 18, os fundos podem ficar bloqueados. No código deste projeto, não há limite superior para os lugares decimais de uma zona, que podem exceder os 18. Em ClaimSnMessage, quando os utilizadores querem reclamar as suas tokens de participação, é utilizado o ClaimShareToken. No entanto, se os lugares decimais da zona excederem os 18, a conversão falhará e será impossível extrair ativos do sistema. Assim, ao controlar os lugares decimais de uma zona, é possível desencadear diretamente uma falha e crash na transação.

Localização da Vulnerabilidade: https://github.com/Carina-labs/nova/blob/v0.6.3/x/gal/keeper/claim.go#L167

Fragmento de Código de Vulnerabilidade:

Caminho de desencadeamento de vulnerabilidades:

msgServer.ReivindicarAtivoSn

Keeper.ClaimShareToken

Keeper.ConvertWAssetToSnAssetDecimal

precisãoMultiplicador

• Antecedentes da vulnerabilidade: projeto SuperNova

Endereço do projeto: https://github.com/Carina-labs/nova/

A singularidade da zona não está verificada. Em regiões registadas, utilize o ID da região para verificar a singularidade do token base (BaseDenom). O BaseDenom de cada região deve ser único. Se o valor do token base estiver definido incorretamente, resultará numa perda de fundos. Antes de definir o token base no RegisterZone, o projeto não garantiu que o BaseDenom fosse único em todas as zonas principais. Caso contrário, existiria a possibilidade de os utilizadores armazenarem fundos noutra zona maliciosa contendo um BaseDenom com o mesmo nome, resultando numa perda de fundos.

Localização da vulnerabilidade: https://github.com/Carina-labs/nova/blob/v0.6.3/x/icacontrol/keeper/msg_server.go#L99

Trecho de código vulnerável:

Correção de bug: Adicionada verificação de DenomDuplicateCheck

Além disso, o primeiro caso no primeiro caso em que a cadeia pára de funcionar deve-se a uma falha que leva ao fracasso da cunhagem, que também é uma forma de perda de capital.

• Antecedentes da vulnerabilidade: projeto Supernova

Endereço do projeto: https://github.com/Carina-labs/nova/

Faltam atualizações de status. No método IcaWithdraw(), se a transação falhar e o status da versão não for modificado, o WithdrawRecord será inacessível e os fundos correspondentes não poderão ser retirados. Uma compreensão mais popular é que o estado é definido antes do SendTx e não é modificado após a falha, causando a falha na retirada dos fundos e impossibilitando a retirada novamente na próxima vez.

Localização da vulnerabilidade: https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/gal/keeper/msg_server.go#L356

Trecho de código vulnerável:

Com base neste excerto, podemos discernir que a lógica principal das operações relacionadas com fundos depende principalmente do tratamento de várias mensagens. Claro que também existem casos como o primeiro cenário envolvendo operações de cunhagem no processo de execução BeginBlock. Quando estas operações falham, também podem levar a perdas financeiras. No geral, ao concentrarmos a nossa auditoria nos módulos de código que envolvem operações financeiras, podemos aumentar significativamente a probabilidade de descobrir essas vulnerabilidades.

Afetando o Estado do Sistema ou a Operação Normal

A gama desta categoria de questões é bastante ampla. Os primeiros dois tipos de riscos que discutimos também podem ser considerados como subconjuntos de vulnerabilidades que afetam o estado do sistema ou a operação normal. Além destes, mais perigosas são várias vulnerabilidades lógicas. Em grande parte, estas vulnerabilidades geram diferentes riscos de segurança de acordo com a lógica de negócios do projeto. No entanto, devido às semelhanças na construção dos componentes do Cosmos SDK e sua natureza modular, erros semelhantes frequentemente ocorrem em implementações de código específicas. Aqui listamos alguns tipos comuns de vulnerabilidades:

- Validação de variável incompleta no tipo sdk.Msg:

Uma vez que vários projetos implementaram uma variedade de tipos derivados baseados em sdk.Msg, nem todos os elementos dos tipos existentes foram verificados adequadamente no Cosmos SDK. Isso levou à omissão de verificações críticas de variáveis incorporadas, o que acarreta certos riscos de segurança.

Estudo de caso: Aviso de segurança do Cosmos SDK Barberry

Antecedentes da vulnerabilidade: O MsgCreatePeriodicVestingAccount.ValidateBasic carece de mecanismos para avaliar o estado de uma conta, como se está ativa. Na PeriodicVestingAccount definida em x/auth, um atacante poderia inicializar a conta de uma vítima para uma conta maliciosamente controlada. Esta conta permite depósitos, mas proíbe levantamentos. Quando os utilizadores depositam fundos na sua conta, esses fundos ficarão permanentemente bloqueados, e o utilizador não conseguirá retirá-los.

Pacote de correção de vulnerabilidades:

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

Trecho de código vulnerável:

Além disso, problemas na fase ValidateBasic também estavam presentes no Cosmos-SDK Security Advisory Elderflower e no Cosmos-SDK Security Advisory Jackfruit. O primeiro sofreu de uma omissão direta da chamada ValidateBasic, enquanto o último envolveu problemas com a verificação da variável de timestamp dentro da mensagem. Em cadeias de aplicativos, tais problemas são ainda mais comuns. Projetos como ethermint, pstake-native e quicksilver todos encontraram vulnerabilidades de segurança semelhantes em suas medidas de verificação de processamento de mensagens.

Além dos tipos de verificação, também existem problemas encontrados na lógica de tratamento do sdk.Msg, tais como operações envolvendo um consumo extensivo de gás, loops e tratamento de falhas irrazoável. Uma vez que a cadeia de processamento de mensagens tem mecanismos de recuperação correspondentes, o seu nível de perigo é um pouco menor do que uma paralisação completa da cadeia. No entanto, ainda podem impactar o funcionamento normal do sistema ou levar à perda de fundos na cadeia.

Tipos Comuns de Vulnerabilidades

Excluindo vulnerabilidades únicas para operações de projeto específicas, existem alguns modelos de vulnerabilidade mais comuns. Por exemplo, o terceiro caso de perda de fundos é uma operação que altera o estado antes de enviar uma mensagem. Este tipo de vulnerabilidade é semelhante àquelas em contratos inteligentes, onde a alteração do estado antes da transferência de fundos pode levar a problemas como reentrada ou estados erróneos persistentes. Cenários onde a definição de estado está intimamente ligada à transmissão de mensagens são bastante comuns em blockchain, e muitas vulnerabilidades significativas têm origem em tais problemas. Além disso, existem vulnerabilidades de segurança computacional como erros de divisão por zero, bypasses de consumo de gás e uso de versões com vulnerabilidades conhecidas, todos os quais podem afetar o estado ou a operação normal do sistema.

Problemas de Singularidade

Devido às inúmeras operações de leitura e escrita na cadeia de blocos, a singularidade na nomenclatura é extremamente importante em algumas funcionalidades. Por exemplo, o segundo caso de perda de fundos mencionado anteriormente é um problema de singularidade. Além disso, a composição de prefixos em variáveis que representam chaves, como strings ou matrizes de bytes, pode representar riscos. Uma pequena falha poderia resultar em nomes sendo mal interpretados, levando a problemas como perda de fundos ou erros de consenso.

Questões de Recursos de Idioma

Estes são mais amplos, mas têm características identificáveis, tornando-os mais fáceis de detetar. Exemplos incluem problemas com iteração de mapas em Golang ou mecanismos de pânico em Rust. É aconselhável listar esses fatores de risco específicos do idioma e prestar especial atenção a eles durante o uso ou auditoria para minimizar tais erros.

Resumo

Da nossa exploração dos problemas de segurança subjacentes no ecossistema Cosmos, está claro que esses problemas não são únicos para o Cosmos e podem ser aplicados a outros ecossistemas de blockchain também. Aqui estão algumas recomendações e conclusões sobre os problemas de segurança no ecossistema Cosmos:

• Preste atenção às vulnerabilidades da infraestrutura: Componentes principais como CometBFT e Cosmos SDK também podem ter vulnerabilidades, portanto, atualizações regulares e manutenção são necessárias para segurança.

• Revise bibliotecas de terceiros imediatamente: os desenvolvedores do Cosmos geralmente usam bibliotecas de terceiros para estender as funcionalidades de seus aplicativos. Essas bibliotecas podem conter vulnerabilidades potenciais, exigindo revisão e atualizações para mitigar riscos.

• Tenha cuidado com ataques de nós maliciosos: os nós de consenso são cruciais no ecossistema Cosmos. Os algoritmos de tolerância a falhas bizantinas desses nós podem ser suscetíveis a ataques, portanto, garantir a segurança do nó é essencial para prevenir comportamentos maliciosos.

• Considere a segurança física: São necessárias medidas de segurança física para hardware e servidores que executam nós do Cosmos para evitar acesso não autorizado e possíveis ataques.

• Conduzir as revisões de código necessárias: Dada a abertura dos ecossistemas Cosmos SDK e CometBFT, os desenvolvedores e auditores devem rever tanto o código principal quanto o código escrito em módulos personalizados para identificar e corrigir possíveis problemas de segurança.

• Prestar atenção às ferramentas do ecossistema: O ecossistema Cosmos inclui muitas ferramentas e aplicações, que também precisam passar por revisões de segurança e atualizações regulares para garantir sua segurança.

Guia de Segurança do Protocolo IBC

Este módulo foca nos aspetos de segurança do protocolo de Comunicação Inter-Blockchain (IBC), um componente crucial no ecossistema Cosmos. O protocolo IBC serve como uma ponte para interações entre diferentes blockchains. Enquanto outras pontes inter-cadeias fornecem soluções para questões específicas e isoladas, o protocolo IBC oferece uma solução fundamental unificada e suporte técnico subjacente para interações entre cadeias. O IBC é um protocolo que permite a transferência de quaisquer dados entre blockchains heterogéneas de forma fiável, ordenada e com um mínimo de confiança.

Desde o advento do Bitcoin, o campo da blockchain tem experimentado um crescimento explosivo. Inúmeras novas redes surgiram, cada uma com a sua proposta de valor única, mecanismos de consenso, ideologias, apoiantes e razões de existência. Antes da introdução do IBC, estas blockchains operavam de forma independente, como em contentores fechados, incapazes de comunicar entre si, um modelo fundamentalmente insustentável.

Se as blockchains forem vistas como países com populações em crescimento e atividades comerciais movimentadas, algumas se destacam na agricultura, outras na pecuária. Naturalmente, elas buscam um comércio e cooperação mutuamente benéficos, aproveitando suas respectivas forças. Não é exagero dizer que o IBC abriu um novo mundo de possibilidades ilimitadas, permitindo que diferentes blockchains interoperem, transfiram valor, troquem ativos e serviços, e estabeleçam conexões, sem serem prejudicadas pelos problemas inerentes de escalabilidade das grandes redes de blockchains de hoje.

Então, como é que o IBC satisfaz estas necessidades e desempenha um papel tão crucial? As razões fundamentais são que o IBC é:

1. Confiança minimizada

2. Capaz de suportar blockchains heterogéneas

3. Personalizável na camada de aplicação

4. Uma tecnologia madura e testada

A base do protocolo IBC reside em clientes leves e relayers. As Cadeias A e B comunicam-se através do IBC, cada uma possuindo clientes leves do ledger da outra. A Cadeia A, sem precisar confiar em uma terceira parte, pode alcançar consenso sobre o estado da Cadeia B verificando os cabeçalhos de bloco. As cadeias que interagem através do IBC (especialmente os módulos) não enviam diretamente mensagens uma à outra. Em vez disso, a Cadeia A sincroniza certas mensagens em um pacote de dados para o seu estado. Posteriormente, os relayers detectam esses pacotes de dados e transferem-nos para a cadeia de destino.

No geral, o protocolo IBC pode ser dividido em duas camadas: IBC TAO e IBC APP.

• IBC TAO: Define os padrões para a transmissão de pacotes de dados, autenticação e ordenação, essencialmente a camada de infraestrutura. No ICS (Padrões Interligados), isto consiste em categorias de núcleo, cliente e retransmissor.

• IBC APP: Define os padrões para manipuladores de aplicativos de pacotes de dados transmitidos através da camada de transporte. Estes incluem, mas não se limitam a, transferências de tokens fungíveis (ICS-20), transferências de tokens não fungíveis (ICS-721) e contas intercadeias (ICS-27), e podem ser encontrados na categoria de aplicativos do ICS.

Protocolo IBC (Do Portal do Desenvolvedor Cosmos)

O protocolo IBC (Comunicação Inter-Blockchain) é a pedra angular da visão do ecossistema Cosmos de um “Internet de Blockchains”. Neste contexto, as escolhas de design do IBC são influenciadas pelos padrões TCP/IP. Da mesma forma que o TCP/IP define padrões para comunicação de computadores, o IBC especifica um conjunto de abstrações universais que permitem que as blockchains comuniquem entre si. Assim como o TCP/IP não restringe o conteúdo dos pacotes de dados transmitidos pela rede, o IBC opera da mesma forma. Além disso, da mesma forma que protocolos de aplicação como HTTP e SMTP são construídos em cima do TCP/IP, aplicações como transferências de ativos homogeneizados/não fungíveis ou chamadas de contratos inteligentes entre cadeias também usam o protocolo IBC como uma camada fundamental.

Os principais problemas atualmente vistos com o protocolo IBC estão relacionados com a transmissão de canais e processamento de pacotes. Houve problemas significativos na verificação de provas, mas estes são relativamente menos comuns. Este artigo concentra-se nas questões comuns do protocolo IBC. Graças ao design modular do protocolo IBC, os desenvolvedores de aplicativos IBC não precisam se preocupar com detalhes subjacentes, como clientes, conexões e verificação de provas. No entanto, eles precisam implementar a interface IBCModule e os métodos de manipulação correspondentes do Keeper. Portanto, muitos problemas relacionados ao protocolo IBC surgem nos caminhos de código das interfaces IBCModule para receber e processar pacotes (onRecvPacket, OnAcknowledgementPacket, OnTimeoutPacket, etc.).

Classificações Comuns de Vulnerabilidades

No ecossistema Cosmos, o protocolo IBC funciona como um hub de conexão. Os tipos de vulnerabilidades associadas ao protocolo IBC são diversos e complexos devido à estreita integração de suas implementações com módulos como Cosmos-SDK e CometBFT. Além disso, como o IBC é usado principalmente no ecossistema Cosmos, sua linguagem de programação principal é Golang, conforme detalhado na documentação ibc-go.

Devido a restrições de espaço, este artigo não se aprofunda na análise detalhada de todos os aspectos e componentes do protocolo IBC. Em vez disso, classifica algumas das vulnerabilidades de segurança existentes. Para uma análise mais detalhada e abrangente, convidamo-lo a contactar os nossos engenheiros de segurança da CertiK para discussão.

Classificações Comuns de Vulnerabilidades:

1. Vulnerabilidades de Nomeação

   ① Vulnerabilidades de manipulação de strings

   ② Vulnerabilidades de Manipulação de Bytecode

2. Vulnerabilidades no Processo de Transmissão

   ① Vulnerabilidades na Ordem dos Pacotes

   ② Vulnerabilidades de Tempo Limite de Pacote

   ③ Vulnerabilidades de Autenticação de Pacotes

   ④ Outras Vulnerabilidades de Pacotes

3. Vulnerabilidades Lógicas

   ① Atualização do Estado das Vulnerabilidades

   ② Vulnerabilidades de Votação e Consenso

   ③ Outras Vulnerabilidades Lógicas

4. Vulnerabilidades de Consumo de Gás

O protocolo IBC existente, em termos de auditoria e análise da sua segurança, partilha muitas semelhanças com os processos de auditoria dos protocolos Web2. Esta análise irá dissecar algumas das questões de segurança e riscos potenciais do protocolo IBC do ponto de vista do estabelecimento do protocolo, implementação e expansão da aplicação. Uma vez que a formulação do protocolo é frequentemente concluída por algumas pessoas e organizações, para várias organizações blockchain, mais trabalho gira em torno da implementação e expansão da aplicação do protocolo. Portanto, este artigo irá focar-se nas questões de segurança destes aspetos. Esta abordagem deriva da consideração da ampla gama de riscos de segurança abrangidos pelo protocolo IBC, permitindo uma melhor categorização de diferentes tipos de questões de segurança em estágios e módulos correspondentes.

Análise de Vulnerabilidades

Formulação do Protocolo IBC

Estudo de caso 1: Protocolo ICS-07, Vulnerabilidade Lógica

Antecedentes da Vulnerabilidade: Utilização Incorreta do Período de Desvinculação

No código, existe a seguinte validação:

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

De acordo com o modelo de segurança do Tendermint, para um bloco (cabeçalho) no tempo t, os validadores em NextValidators precisam operar corretamente antes de t+TrustingPeriod. Depois disso, eles podem exibir outros comportamentos. No entanto, a verificação aqui é para UnbondingPeriod, não TrustingPeriod, onde UnbondingPeriod > TrustingPeriod. Se o prazo de consState estiver entre TrustingPeriod e UnbondingPeriod, então este cabeçalho será aceite como referência para validar um dos cabeçalhos conflitantes que constituem má conduta. Durante este período, os validadores em consState.NextValidators já não são considerados confiáveis, e ex-validadores hostis podem encerrar o cliente sem qualquer risco.

Endereço do Projeto: https://github.com/cosmos/ibc/tree/e01da1d1346e578297148c9833ee4412e1b2f254/spec/ics-007-tendermint-client

Localização da Vulnerabilidade:

• 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

Trecho de Código Vulnerável:

função de definição de protocolo

Código

Implementação do Protocolo IBC

A fase de implementação do protocolo IBC é uma fase em que as questões são propensas a surgir, uma vez que desempenha um papel de ponte crítico. Não só precisa evitar ambiguidades nas especificações do protocolo, como também precisa fornecer interfaces básicas e convenientes para a aplicação subsequente e expansão do protocolo. Portanto, as principais questões na fase de implementação do protocolo IBC podem ser ainda categorizadas em:

1. Ambiguidades e questões não padronizadas na implementação do protocolo.

2. Erros nas definições do protocolo.

Ambiguidades e Questões Não Padrão na Implementação do Protocolo

Estudo de caso 1: Protocolo ICS-20, Vulnerabilidade de Nomenclatura

Antecedentes da vulnerabilidade: Conflito de endereço custodial. O GetEscrowAddress()a função gera um SHA256 truncado de 20 bytes (ID da porta + ID do canal). Este método tem três problemas:

1. Falta de separação de domínio entre portas e canais. O método de concatenação de strings não separa os domínios da porta e do canal. Por exemplo, as combinações de porta/canal ("transfer", "channel") e ("trans", "ferchannel") resultarão no mesmo endereço de custódia, ou seja, o SHA256 truncado ("transferchannel"). Se módulos específicos com funções de biblioteca puderem selecionar identificadores de porta e canal, podem surgir vulnerabilidades.

2. Conflitos entre endereços de conta de módulo. Seqüências alfanuméricas arbitrárias são usadas no pré-imagem do SHA-256, com um tamanho de pós-imagem de 160 bits. Esta pequena pós-imagem combinada com uma função de hash rápida torna um ataque de aniversário viável, pois sua segurança é reduzida para apenas 80 bits. Significa que aproximadamente 2^80 conjecturas são necessárias para encontrar uma colisão entre dois endereços de conta custodial diferentes. Em 2018, foi realizada uma análise de custos detalhada do ataque à truncagem do SHA256 no contexto do Tendermint, provando que tal ataque é viável do ponto de vista do custo. Encontrar uma colisão significa que duas contas custodiais diferentes são mapeadas para o mesmo endereço da conta. Isso poderia levar a riscos de roubo de fundos de contas custodiais. Para mais detalhes, consulte o domínio de pré-imagem do ICS20 GetEscrowAddress sobrepõe-se com chaves públicasT:BUG.

3. Conflitos entre endereços de contas de módulos e não-módulos. A construção de endereços de contas públicas é a mesma que os 20 bytes de SHA-256 das chaves públicas Ed25519. Embora a segurança de 160 bits seja suficiente para prevenir ataques de colisão em endereços públicos específicos, a segurança contra ataques de aniversário é apenas de 80 bits. Esta situação é semelhante a um modo de ataque semi-aniversário, onde um endereço é gerado pelo rápido SHA-256, e o outro endereço é gerado pelos cálculos de chaves públicas Ed25519 relativamente mais lentos. Embora esta situação seja mais segura, ainda representa potenciais ataques em contas custodiais e públicas.

Endereço do projeto: https://github.com/cosmos/ibc/tree/e01da1d1346e578297148c9833ee4412e1b2f254/spec/ics-020-fungible-token-transfer

Localização da vulnerabilidade: 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

Trecho de código vulnerável:

Problema de configuração de protocolo

• Caso 1: IBC Security Advisory Dragonberry, vulnerabilidade no processo de transmissão

Antecedentes da vulnerabilidade: IBC utilizará uma estrutura de pacote ao processar pacotes de dados de aplicativos. De acordo com o mecanismo de tempo limite, mecanismos de confirmação síncrona e assíncrona e o processo de verificação de certificação correspondente, o pacote de dados será dividido em dois processos de execução:

1. Situação normal: Sucesso dentro do tempo limite

2. Situação de Timeout: falha de timeout

Gráfico de fluxo de transmissão de pacotes de aplicação IBC

Quando ocorre um timeout, significa que a transmissão falhou e o protocolo IBC iniciará um processo de reembolso. Deve-se notar que o IBC possui um mecanismo de timeout configurável pelo usuário. A vulnerabilidade Dragonberry tem origem no ICS-23 (IBC). A causa raiz dessa vulnerabilidade é que os usuários podem forjar provas de inexistência no processo de verificação (ou seja, falsas provas de que nenhum pacote de dados foi recebido), contornando assim as verificações de segurança e forjando uma situação de timeout IBC “razoável” é usada para enganar o protocolo IBC, fazendo com que o repetidor envie pacotes de timeout com certificados falsos e pode escalar para um problema de duplo gasto ICS-20. O processo específico de acionamento da vulnerabilidade pode ser visto na figura abaixo.

Princípio de vulnerabilidade do Dragonberry fluxograma

Endereço do projeto: https://github.com/cosmos/ibc-go/tree/00a680cda52690a4ba835bf37f53acc41c01bc7a/modules/core/04-channel

Localização da vulnerabilidade: https://github.com/cosmos/ibc-go/blob/00a680cda52690a4ba835bf37f53acc41c01bc7a/modules/core/04-channel/keeper/timeout.go#L117C28-L117C54

Trecho de código vulnerável:

• Caso 2: Aviso de Segurança IBC Huckleberry, vulnerabilidade no processo de transmissão

Antecedentes da Vulnerabilidade: UnreceivedPackets apenas constrói uma resposta encontrando o recibo do pacote correspondente para cada número de sequência incluído na consulta. Isso só funciona para canais fora de ordem, pois os canais ordenados usam nextSequenceRecv em vez de recibos de pacotes. Portanto, em um canal ordenado, a consulta do número de sequência via GetPacketReceipt não encontrará o recibo dentro dele.

A gravidade deste problema é menor porque o canal transmitido pelo ICS-20 FT está na maioria das vezes desativado e o repetidor não depende deste endpoint grpc para determinar quais pacotes desencadeiam o timeout. No entanto, se houver um grande número de pacotes na cadeia de destino, e o canal ordenado estiver configurado para transmissão IBC, e a resposta grpc não for paginada, isso criará um risco de causar a degradação ou até mesmo a falha no desempenho do nó de serviço. O processo específico de desencadeamento pode ser visto na figura abaixo.

Princípio de vulnerabilidade do fluxo de gráfico de Huckleberry

Endereço do projeto: https://github.com/cosmos/ibc-go/blob/11297aaa61e651c16e6d4147a15be24ce55ba7cc/modules/core/04-channel/

Localização da vulnerabilidade: https://github.com/cosmos/ibc-go/blob/11297aaa61e651c16e6d4147a15be24ce55ba7cc/modules/core/04-channel/keeper/grpc_query.go#L408

Trecho de código vulnerável:

Aplicação e extensão do protocolo IBC

• Caso 1: vulnerabilidade de airdrop de passo, vulnerabilidade lógica

Antecedentes da Vulnerabilidade: A função TryUpdateAirdropClaimconverte o endereço do remetente de um pacote IBC num endereço Stride chamadosenderStrideAddress, e extrai airdropIde o novo endereço de airdrop novoEndereçoStridedos metadados do pacote. Em seguida, chamaAtualizarEndereçoAirdroppara atualizar osenderStrideAddresseReivindicação de RegistroCom a atualização do ReivindicarRegistro, novoEndereçoStrideserá capaz de reivindicar o airdrop. No entanto, esta função de atualização apenas verifica se o endereço do remetente do pedido está vazio e não validanewStrideAddress. Como o IBC permite que conexões de máquinas individuais implementem cadeias habilitadas para IBC, isso representa um risco de segurança onde é possível atualizar qualquer outro endereço de conta como o endereço do airdrop.

Endereço do projeto: https://github.com/Stride-Labs/stride/tree/3a5c7bfcc3b8c5e7dd870f01bebeb9d949492203/x/autopilot

Localização da vulnerabilidade: 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

Trecho de código vulnerável:

• Caso 2: vulnerabilidade do módulo ibc neutron, vulnerabilidade de consumo de gás

Antecedentes da vulnerabilidade: No contexto dos contratos inteligentes, há um problema na forma como as taxas são verificadas para confirmar ou expirar eventos IBC (Comunicação Inter-Blockchain). Essa falha permite que contratos inteligentes maliciosos desencadeiem um 'ErroOutOfGas'. Esse erro ocorre durante o processamento de mensagens 'OnAcknowledgementPacket' e 'OnTimeoutPacket'. Quando esse erro ocorre, não é possível resolvê-lo através do método usual 'outOfGasRecovery'. Como resultado, as transações afetadas falham em ser incluídas no bloco da blockchain. Essa falha pode fazer com que os retransmissores IBC tentem repetidamente enviar essas mensagens. Tais envios repetidos podem levar a perdas financeiras para os retransmissores e sobrecarregar a rede com um número excessivo de pacotes não processados ('abandonados'), o que representa um risco para a estabilidade da rede.

Endereço do projeto: https://github.com/neutron-org/neutron/blob/64868908b21f648ad5e8a9b48179134619544e2a/

Localização da vulnerabilidade:

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

Trecho de código vulnerável:

Resumo

A análise e discussão das questões de segurança relativas ao protocolo de Comunicação Inter-Blockchain (IBC), tal como apresentado no texto anterior, destacam a natureza generalizada e variada destas preocupações. Os desafios principais parecem originar-se predominantemente da fase de implementação e da expansão de aplicações que utilizam o protocolo IBC. À medida que várias cadeias de aplicações melhoram e refinam progressivamente as suas funcionalidades de módulos tradicionais, incorporam simultaneamente diversas implementações de código nos seus módulos IBC. Isto é feito para aumentar o desempenho e responder a requisitos comerciais específicos.

Para além das questões de segurança anteriormente mencionadas no componente IBC, estão a surgir novos desafios, particularmente no middleware IBC. Estas preocupações em evolução prevê-se que se tornem cada vez mais significativas no futuro, especialmente no que diz respeito à segurança global do ecossistema Cosmos. Esta mudança indica uma ênfase crescente na garantia de medidas de segurança robustas no módulo IBC.

Conclusão

A nossa investigação sobre a segurança do ecossistema Cosmos, envolvendo auditorias detalhadas, sumarizações e categorizações, centrou-se nos seus dois componentes mais críticos: o Cosmos SDK e o protocolo IBC. Baseando-nos na nossa extensa experiência prática, compilámos uma coleção abrangente de expertise geral em auditoria.

Este relatório sublinha os desafios únicos colocados por uma rede heterogénea como o Cosmos, especialmente dada a sua capacidade de suportar interações entre cadeias. A complexidade e natureza dispersa dos seus componentes tornam a tarefa de garantir a sua segurança formidável. Isso não só exige a aplicação do nosso conhecimento existente sobre riscos de segurança, mas também a adaptação a novos cenários de segurança para abordar questões emergentes.

Apesar destes obstáculos, estamos otimistas. Ao documentar e analisar cenários comuns e desafios de segurança, como fizemos neste relatório, estamos a abrir caminho para melhorar progressivamente o enquadramento geral de segurança dentro do diversificado ecossistema Cosmos.

Aviso:

1. Este artigo é reproduzido a partir de [CertiK]. Todos os direitos de autor pertencem ao autor original [CertiK]. Se houver objeções a esta reimpressão, por favor entre em contato com o Gate Aprenderequipa e eles vão tratar disso prontamente.
2. Aviso de responsabilidade: As opiniões expressas neste artigo são exclusivamente do autor e não constituem qualquer conselho de investimento.
3. As traduções do artigo para outros idiomas são feitas pela equipa Gate Learn. Salvo indicação em contrário, é proibido copiar, distribuir ou plagiar os artigos traduzidos.