O ecossistema Cosmos, renomado globalmente como uma das maiores e mais notáveis redes blockchain, prioriza a interoperabilidade blockchain. Esse foco é fundamental para facilitar a comunicação sem falhas 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 Dragonfruit no Cosmos SDK, que interrompeu 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 esboçar estratégias de resposta eficazes.

A equipe da CertiK está dedicada a fortalecer a segurança da rede Cosmos e do ecossistema Web3 mais amplo por meio de pesquisas e desenvolvimento contínuos. Estamos animados para compartilhar nossas descobertas e insights com você por meio de relatórios de segurança regulares e atualizações de pesquisa técnica. Caso tenha alguma dúvida, nossa equipe está sempre disponível para contato.

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

Visão geral do Cosmos

Considerado como um dos ecossistemas de blockchain mais proeminentes do mundo, o Cosmos se destaca por suas capacidades de rede de código aberto, escaláveis e interconectadas. Desenvolvido pela equipe CometBFT, originalmente conhecida como Tendermint, o Cosmos tem como objetivo eliminar silos de informações e facilitar a interoperabilidade entre diversas blockchains. Em uma era em que múltiplas redes de blockchain coexistem, a necessidade de interação entre blockchains é mais urgente do que nunca.

Cosmos se distingue por oferecer um modelo eficiente de interconexão de blockchains, especialmente benéfico para blockchains públicas com foco vertical específico. Sua infraestrutura modular de blockchain capacita os desenvolvedores de aplicativos, oferecendo-lhes a flexibilidade de selecionar e utilizar blockchains públicas que estejam alinhadas com seus requisitos específicos.

No coração do ecossistema Cosmos está o Protocolo de Comunicação Inter-Blockchain (IBC), que conecta aplicativos e protocolos em diferentes blockchains independentes. Isso não apenas facilita a transferência contínua de ativos e dados, mas também está alinhado com a visão da Cosmos de criar uma 'internet de blockchains'. Esse conceito prevê uma vasta rede de blockchains autônomos e facilmente desenvolvidos, interconectados para expansão e interação.

Envolvimento e Pesquisa da CertiK na Segurança da Cosmos

Por um longo período, a CertiK esteve 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 percepções e descobertas sobre a segurança do ecossistema Cosmos, com foco 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á desde os componentes fundamentais do ecossistema Cosmos até suas cadeias fundamentais e de aplicação. Ao examinar e extrapolar questões relacionadas, nosso objetivo é 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 do Cosmos. Para mais informações ou discussões sobre outros aspectos de segurança, encorajamos você a entrar em contato com os engenheiros de segurança da CertiK.

Antecedentes

CometBFT: Aprimorando a escalabilidade entre cadeias em sua essência

No centro da escalabilidade Interchain encontra-se 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 CometBFT, que serve como o motor de consenso fundamental, e uma interface de blockchain de aplicação universal (ABCI). Ao combinar elementos do PBFT (Tolerância a Falhas Bizantinas Práticas) e do PoS com garantia de participação (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 é um conjunto de ferramentas poderoso que simplifica e acelera o desenvolvimento de blockchain. Seu design modular e recursos plugáveis capacitam desenvolvedores a construir suas próprias blockchains ou componentes funcionais sobre o algoritmo de consenso CometBFT. Essa abordagem não só facilita o desenvolvimento, mas também encurta significativamente o ciclo de desenvolvimento. A eficácia do SDK é comprovada por sua adoção em inúmeros projetos, incluindo Cronos, Kava e o dYdX V4, lançado recentemente. Olhando para o futuro, o Cosmos SDK planeja aprimorar sua modularidade e introduzir novos recursos, possibilitando a criação de aplicativos mais sofisticados e modulares, nutrindo assim um ecossistema mais amplo e robusto.

Protocolo IBC: Impulsionando a interoperabilidade e 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 aprimorar a escalabilidade e interoperabilidade é central. O foco atual da Interchain Foundation está em melhorar esses aspectos do protocolo IBC, com o objetivo de fortalecer interações contínuas entre blockchains, aplicativos e contratos inteligentes dentro do ecossistema Cosmos.

CosmWasm: Facilitando a implantação descentralizada de aplicativos

CosmWasm (Cosmos WebAssembly) é um framework de contratos inteligentes adaptado para o ecossistema Cosmos. Baseado em WebAssembly, permite aos desenvolvedores implantar aplicativos descentralizados sem precisar de permissões específicas. Este framework permite que os desenvolvedores de blockchain desvinculem o desenvolvimento do produto do desenvolvimento de blockchain, reduzindo o ônus das atualizações do validador. As características 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.

Adaptando e Personalizando dentro do Ecossistema Cosmos

Para os desenvolvedores de blockchain no ecossistema Cosmos, o Cosmos SDK atende à maioria das necessidades de personalização. Durante as atividades de interconexão de blockchain, os desenvolvedores de blockchain podem adaptar seus módulos IBC para operações especiais ou otimização de desempenho. Enquanto algumas blockchains 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 se concentra 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 aplicativos blockchain e protocolos descentralizados. Criado pela Interchain Foundation, este framework é fundamental para a rede Cosmos, que é uma rede expansiva de blockchains interconectadas.

Em sua essência, o Cosmos SDK é projetado para simplificar a criação de aplicativos de blockchain personalizados, ao mesmo tempo que facilita a interação perfeita entre blockchains diversas. Suas características notáveis englobam uma estrutura modular, extensa customizabilidade, integração com o CometBFT Core para consenso e a implementação de interfaces IBC, todas contribuindo para seu apelo aos desenvolvedores. Uma das principais forças do Cosmos SDK é sua dependência do mecanismo de consenso CometBFT Core, que oferece 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 usuários. A natureza modular do SDK capacita os usuários a criar módulos personalizados com facilidade. No entanto, os desenvolvedores devem estar atentos, pois vulnerabilidades de segurança ainda podem surgir ao implantar aplicativos 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 perspectivas. Em contraste, na pesquisa de segurança, o foco se desloca para identificar vulnerabilidades que poderiam ter repercussões significativas. Esta abordagem visa mitigar prontamente as principais ameaças de segurança, oferecendo assim uma assistência mais eficaz aos serviços que integram o SDK. É crucial identificar e analisar vulnerabilidades que representam riscos graves e têm amplas implicações.

Um ponto focal dentro do SDK Cosmos é 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 entender 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 têm origem nos agentes do usuário, onde são criadas, assinadas e depois transmitidas para os nós da 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 sendo transmitidas aos usuários. Durante o processamento do bloco, o método DeliverTx é aplicado para garantir consistência e determinismo transacional.

No Cosmos SDK, o ciclo de vida da transação é um processo de várias etapas, abrangendo a criação, validação, inclusão em um bloco, mudanças de estado e compromisso final. Esse processo pode ser delineado nas seguintes etapas:

1. Criação de Transação: Os usuários geram transações usando várias ferramentas como Interfaces de Linha de Comando (CLI) ou clientes frontend.

2. Adição à Mempool: Uma vez criadas, as transações entram na mempool. Aqui, os nós enviam uma mensagem ABCI (Interface de Blockchain de Aplicativo) conhecida como CheckTx para a camada de aplicativo para verificação de validade. As transações passam por decodificação do formato de byte para o formato Tx. Cada sdk.Msg dentro da transação é submetido a verificações preliminares sem estado pela função ValidateBasic(). Além disso, se o aplicativo incluir um anteHandler, sua lógica é executada antes da função runTx, o que leva à função RunMsgs() para processar o conteúdo sdk.Msg. O sucesso do CheckTx resulta na transação sendo enfileirada 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 em um 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 por manter o consenso, aprovam este bloco ou optam por um bloco vazio.

4. Mudanças de Estado: Similar to CheckTx, the DeliverTx process iterates through block transactions. However, it operates in ‘Deliver’ mode, executing state changes. The MsgServiceRouter directs different transaction messages to respective modules, where each message is processed in the Msg Server. After message execution, further checks ensure transaction validity. If any check fails, the state reverts to its previous condition. A Gas meter tracks the consumed gas during execution. Gas-related errors, such as insufficient gas, lead to a reversion of state changes, similar to execution failures.

5. Compromisso de Bloqueio: Ao receber votos de validadores suficientes, um nó confirma o novo bloco na blockchain. Essa ação finaliza as transições de estado na camada de aplicação, marcando a conclusão do processo de transação.

)

[Esta seçã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 Vulnerabilidade

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 parada de corrente
2. Perda financeira
3. Afetando o estado do sistema ou a operação normal

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

1. Negação de Serviço
2. Configuraçõ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. Defeitos lógicos 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 uso e chamadas intermodulares dentro de suas cadeias. Essa complexidade leva a cenários em que 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 ajuda a definir e categorizar melhor o modelo de vulnerabilidade.

Operação de Parada da Corrente: Causas e Tipos

As paradas de cadeia geralmente ocorrem devido 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 exigiram paralisações ativas da cadeia para reparos. Esses problemas se enquadram em duas categorias distintas.

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

O SDK Cosmos e o CometBFT, infraestruturas chave no ecossistema Cosmos, não são apenas utilizados pelas cadeias base no Cosmos, mas também por várias cadeias de aplicativos com base em sua arquitetura. Todos eles seguem as regras de interface ABCI do CometBFT. O foco de sua superfície de ataque também está em sua interface ABCI, e a maioria das vulnerabilidades de segurança que podem causar a paralisação da cadeia são problemas que podem afetar diretamente a execução do código de bloco. Portanto, seus caminhos de ocorrência geralmente podem ser rastreados de volta às interfaces BeginBlock e EndBlock.

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

Exemplos do Primeiro Tipo

Exemplo 1: Análise de Vulnerabilidade do Projeto SuperNova

Antecedentes de vulnerabilidade: No processo de distribuição de cunhagem dentro do Projeto SuperNova, surge um problema crítico decorrente da ausência de verificação de endereço. Esta falha pode levar a falhas operacionais e, consequentemente, perdas financeiras. Especificamente, o módulo de cunhagem, que é fundamental para a geração de tokens, depende da quantidade apostada. No entanto, este processo é suscetível a erros. Por exemplo, se o pool designado não existir ou se houver uma entrada errônea do endereço do contrato, pode levar a falhas no módulo de cunhagem. Esses erros têm o potencial de interromper toda a operação da blockchain. Além disso, no módulo de pool de recompensas, falta 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 parada imediata na blockchain.

Localização da vulnerabilidade: SuperNova GitHub Link

Trecho de código vulnerável:

Caminho de gatilho de vulnerabilidade:

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

Keeper.DistributeMintedCoin

Keeper.distributeLPIncentivePools

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

Correção de vulnerabilidades:

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

O patch está localizado no módulo de manipulação de mensagens de poolincentive (x/poolincentive/types/msgs.go), e não no módulo de mint. Ele adicionou 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 da Cosmos

Endereço do projeto: Link do GitHub da Segurança Interchain do Cosmos

Antecedentes de vulnerabilidade: Os validadores podem retardar a cadeia do provedor 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 consumerKeys diferentes a cadeias de consumidores aprovadas. A AddressList consumerAddrsToPrune aumenta em um elemento para realizar essa operação. Uma vez que esta AddressList é iterada no EndBlocker em x/ccv/provider/keeper/relay.go, os atacantes podem explorá-la para retardar a cadeia do provedor. Para esse ataque, o ator malicioso pode criar transações com várias mensagens AssignConsumerKey e enviá-las para a cadeia do provedor. 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, retardando ou até mesmo parando a cadeia do provedor.

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

Segmento de Código de Vulnerabilidade:

Caminho do gatilho da vulnerabilidade:

msgServer.AssignConsumerKey

Keeper.AtribuirChaveConsumidor

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 falhas 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 uma falha e parar a cadeia.

Localização da vulnerabilidade: Quicksilver GitHub Link

Segmento de Código de Vulnerabilidade:

Correção de vulnerabilidade: AppModule.EndBlock

Keeper.BloqueadorFinal

Keeper.EndZoneDrop

Pacote de correção de vulnerabilidades: https://github.com/quicksilver-zone/quicksilver/blob/20dc658480b1af1cb323b4ab4a8e5925ee79a0ed/x/airdrop/keeper/abci.go#L16

O código de manipulação de pânico foi removido e substituído pelo registro de erros.

Exemplo 4: Projeto de segurança entre cadeias do 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 vários 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 um por um 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 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, retardando ou até mesmo interrompendo a cadeia do consumidor.

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

Segmento de Código de Vulnerabilidade:

Caminho de gatilho de vulnerabilidade:

AppModule.EndBlock

EndBlock

EndBlockRD

EnviarRecompensasAoFornecedor

Segundo Tipo de Situação

Esse tipo de problema de consenso pode não trazer danos graves imediatos, 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, seu impacto e dano podem não ser menores do que outras vulnerabilidades convencionais. Além disso, essas vulnerabilidades têm características comuns.

Exemplo 1

Antecedentes da vulnerabilidade: Aviso de segurança do 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 paralisação do consenso. A estrutura da mensagem MsgGrant no módulo x/authz inclui um campo Grant, que contém o tempo de expiração concedido pela autorização definida pelo usuário. No processo de validação do ValidateBasic() na estrutura Grant, ele compara suas informações de tempo com as informações de tempo local do nó, em vez das informações de tempo do bloco. Como o tempo local é não determinístico, os carimbos de data/hora podem diferir entre os nós, levando a problemas de consenso.

Anúncio de vulnerabilidade:

• Link do Fórum Cosmos 1

• Link do Fórum Cosmos 2

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

Segmento de Código de Vulnerabilidade:

Patch de vulnerabilidade: Link de Comparação do Cosmos SDK GitHub

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

Exemplo 2

Antecedentes da vulnerabilidade: SuperNova, projeto nova

Endereço do projeto: Link do GitHub SuperNova

Usar time.Now() retorna o carimbo de data/hora do sistema operacional. O horário local é subjetivo e, portanto, não determinístico. Como pode haver pequenas diferenças nos carimbos de data/hora dos nós individuais, a cadeia pode não atingir consenso. No módulo ICAControl, a função de envio de transação usa time.Now() para obter o carimbo de data/hora.

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:

Patch de vulnerabilidade:

Alterado de usar o timestamp local para usar o horário do 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:

Contexto da Vulnerabilidade: Módulo Oracle no Projeto BandChain

URL do projeto: Repositório do BandChain no GitHub

Os comentários no repositório de código indicam que o módulo oracle deve ser executado antes do staking para implementar medidas de punição para os violadores do protocolo oracle. No entanto, no código, a sequência está invertida: na função SetOrderEndBlockers, o módulo staking é executado antes do módulo oracle. Se o módulo 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 está 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: Sei Cosmos GitHub Repository

Em várias instâncias em 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 mapa do Go, isso poderia levar a nós alcançando estados diferentes, potencialmente causando problemas de consenso e consequentemente interrompendo o funcionamento da cadeia. Um método mais apropriado seria classificar as chaves do mapa em uma fatia e iterar sobre as chaves classificadas. 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: Sei Cosmos GitHub Trecho de Código

Segmento de Código de Vulnerabilidade:

A partir desses casos, é evidente que as vulnerabilidades que fazem com que uma cadeia pare de funcionar passivamente são frequentemente as mais prejudiciais. Sua lógica causativa pode ser rastreada até afetar diretamente o fluxo de execução de blocos individuais em uma blockchain. Em contraste, as vulnerabilidades de segurança do consenso geralmente resultam na interrupção ativa da cadeia para implementar correções, com sua lógica causativa rastreada até afetar o fluxo operacional geral e o estado da blockchain. Isso difere do foco das vulnerabilidades que levam a perdas financeiras, onde o impacto perigoso específico não é julgado com base no caminho lógico da ocorrência do problema, mas sim se concentra nos proprietários dos fundos, na quantia de dinheiro envolvida, no escopo 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 sdk.Msg e mensagens IBC. Claro, também existem algumas vulnerabilidades que podem causar perda de capital entre os motivos que podem interromper a operação de um 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, inevitavelmente envolve 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.

Perdas de capital são comumente encontradas em cenários como o consumo de gás, fundos sendo bloqueados e incapazes de serem retirados, perda de fundos durante a 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 decimais em uma zona excederem 18, os fundos podem ficar bloqueados. No código deste projeto, não há limite superior para os decimais de uma zona, que podem exceder 18. Em ClaimSnMessage, quando os usuários desejam reivindicar suas tokens de participação, ClaimShareToken é usado. No entanto, se os decimais da zona excederem 18, a conversão falhará e será impossível extrair ativos do sistema. Assim, controlando os decimais de uma zona, é possível acionar diretamente uma falha e uma 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 da vulnerabilidade:

msgServer.ClaimSnAsset

Keeper.ClaimShareToken

Keeper.ConvertWAssetToSnAssetDecimal

precisionMultiplier

• Antecedentes da vulnerabilidade: projeto SuperNova

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

A singularidade da zona não é verificada. Nas regiões registradas, use o ID da região para verificar a singularidade do token base (BaseDenom). O BaseDenom para cada região deve ser único. Se o valor do token base for definido incorretamente, isso resultará em 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, haveria a possibilidade de os usuários armazenarem fundos em outra zona maliciosa contendo um BaseDenom com o mesmo nome, resultando em 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 DenomDuplicateCheck

Além disso, o primeiro caso no primeiro caso em que a cadeia para de funcionar é devido a uma falha que leva à falha 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/

Atualizações de status ausentes. 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 uma nova retirada 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 perceber que a lógica principal das operações relacionadas com fundos depende principalmente do tratamento de várias mensagens. Claro, também existem casos como o primeiro cenário que envolve operações de cunhagem no processo de execução BeginBlock. Quando essas operações falham, também podem resultar em perdas financeiras. No geral, ao focarmos a nossa auditoria nos módulos de código que envolvem operações financeiras, podemos aumentar significativamente a probabilidade de descobrir essas vulnerabilidades.

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

A gama desta categoria de questões é bastante ampla. Os dois primeiros 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 medida, essas 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 com base 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 falta de mecanismos para avaliar o status de uma conta, como se está ativa. No PeriodicVestingAccount definido em x/auth, um atacante poderia inicializar a conta de uma vítima para uma conta maliciosamente de propriedade do atacante. Esta conta permite depósitos, mas proíbe saques. Quando os usuários depositam fundos em sua conta, esses fundos serão permanentemente bloqueados, e o usuário não poderá retirá-los.

Patch de vulnerabilidade:

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 no estágio ValidateBasic também estavam presentes no Cosmos-SDK Security Advisory Elderflower e no Cosmos-SDK Security Advisory Jackfruit. O primeiro sofreu uma omissão direta da chamada ValidateBasic, enquanto o segundo envolveu problemas com a verificação da variável timestamp dentro da mensagem. Em cadeias de aplicativos, esses problemas são ainda mais comuns. Projetos como ethermint, pstake-native e quicksilver 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 manipulação do sdk.Msg, como operações envolvendo um consumo extensivo de gás, loops e manipulação de falhas não razoáveis. Como a cadeia de processamento de mensagens possui mecanismos de recuperação correspondentes, seu nível de perigo é um pouco menor do que um desligamento completo da cadeia. No entanto, ainda podem impactar a operação normal do sistema ou levar à perda de fundos na cadeia.

Tipos Comuns de Vulnerabilidade

Excluindo vulnerabilidades únicas para operações de projetos específicos, 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. Esse 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 mensagem são bastante comuns em blockchain, e muitas vulnerabilidades significativas têm origem nesses 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 a inúmeras operações de leitura e gravação na blockchain, a singularidade na nomenclatura é extremamente importante em algumas funcionalidades. Por exemplo, o segundo caso de perda de fundos mencionado anteriormente é uma questão 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 negligência poderia resultar em nomes sendo mal interpretados, levando a problemas como perda de fundos ou erros de consenso.

Problemas de Recurso de Idioma

Estes são mais amplos, mas têm características identificáveis, o que os torna mais fáceis de detectar. 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 da linguagem e prestar atenção especial a eles durante o uso ou auditoria para minimizar tais erros.

Resumo

De nossa exploração de questões de segurança subjacentes no ecossistema Cosmos, é claro que esses problemas não são exclusivos do Cosmos e podem ser aplicados a outros ecossistemas de blockchain também. Aqui estão algumas recomendações e conclusões sobre as questões 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 a segurança.

• Revisar prontamente as bibliotecas de terceiros: os desenvolvedores do Cosmos frequentemente utilizam bibliotecas de terceiros para estender as funcionalidades de suas aplicações. Essas bibliotecas podem conter vulnerabilidades potenciais, exigindo assim revisão e atualizações para mitigar riscos.

• 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, então 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.

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

• Preste atenção às ferramentas do ecossistema: O ecossistema Cosmos inclui muitas ferramentas e aplicativos, 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 aspectos 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 entre blockchains 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. IBC é um protocolo que permite que blockchains heterogêneos transfiram quaisquer dados de maneira confiável, ordenada e minimamente confiável.

Desde a chegada do Bitcoin, o campo da blockchain experimentou um crescimento explosivo. Inúmeras novas redes surgiram, cada uma com sua proposta de valor única, mecanismos de consenso, ideologias, apoiadores e razões de existência. Antes da introdução do IBC, essas blockchains operavam de forma independente, como em contêineres fechados, incapazes de se 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 criação de gado. Naturalmente, elas buscam 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 blockchain de hoje.

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

1. Trust-minimized

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 que se comunicam através do IBC possuem cada uma clientes leves do livro-razão da outra. A cadeia A, sem precisar confiar em uma terceira parte, pode chegar a um consenso sobre o estado da cadeia B verificando seus cabeçalhos de bloco. As cadeias que interagem através do IBC (especialmente módulos) não enviam mensagens diretamente uma para a outra. Em vez disso, a cadeia A sincroniza certas mensagens em um pacote de dados para seu estado. Posteriormente, os relayers detectam esses pacotes de dados e os transferem para a cadeia de destino.

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

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

• IBC APP: Define os padrões para os 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) é uma pedra angular da visão do ecossistema Cosmos de um “Internet das Blockchains”. Nesse contexto, as escolhas de design do IBC são influenciadas pelos padrões TCP/IP. Semelhante a como o TCP/IP estabelece padrões para a comunicação de computadores, o IBC especifica um conjunto de abstrações universais que permitem que as blockchains se 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, assim como protocolos de aplicação como HTTP e SMTP são construídos em cima do TCP/IP, aplicativos como transferências de ativos homogeneizados/não fungíveis ou chamadas de contratos inteligentes entre cadeias também utilizam o protocolo IBC como uma camada fundamental.

Os principais problemas atualmente observados com o protocolo IBC estão relacionados à transmissão de canal e processamento de pacotes. Há problemas significativos na verificação de prova, mas estes são relativamente menos comuns. Este artigo se concentra nos problemas 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 prova. No entanto, eles precisam implementar a interface IBCModule e os métodos de manipulação do Keeper correspondentes. 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 serve como um hub de conexão. Os tipos de vulnerabilidades associadas ao protocolo IBC são diversos e complexos devido à integração próxima 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 é o 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, ele classifica algumas das vulnerabilidades de segurança existentes. Para uma análise mais detalhada e abrangente, você está convidado a entrar em contato com nossos engenheiros de segurança da CertiK para discussão.

Classificações Comuns de Vulnerabilidades:

1. Vulnerabilidades de Nomenclatura

   ① Vulnerabilidades de Manipulação de Strings

   ② Vulnerabilidades de Manipulação de Bytecode

2. Vulnerabilidades no Processo de Transmissão

   ① Vulnerabilidades de pedidos de 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 de sua segurança, compartilha 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 alguns indivíduos e organizações, para várias organizações de blockchain, mais trabalho gira em torno da implementação e expansão da aplicação do protocolo. Portanto, este artigo se concentrará nas questões de segurança desses aspectos. Esta abordagem decorre 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 Vulnerabilidade

Formulação do Protocolo IBC

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

Antecedentes da Vulnerabilidade: Uso Incorreto 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 funcionar 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 do consState estiver entre TrustingPeriod e UnbondingPeriod, então este cabeçalho será aceito como um ponto de referência para validar um dos cabeçalhos conflitantes que constituem má conduta. Durante este período, os validadores em consState.NextValidators não são mais considerados confiáveis, e ex-validadores hostis podem desligar o cliente sem nenhum 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 questões são propensas a surgir, pois desempenha um papel de ponte crítico. Não só precisa evitar ambiguidades nas especificações do protocolo, mas 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 configuraçõ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 determinados módulos com funções de biblioteca puderem selecionar IDs de porta e canal, vulnerabilidades podem surgir.

2. Conflitos entre endereços de contas de módulos. Seqüências alfanuméricas arbitrárias são usadas na 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 apenas para 80 bits. Isso significa que aproximadamente 2^80 tentativas são necessárias para encontrar uma colisão entre dois endereços de conta custodial diferentes. Em 2018, foi conduzida uma análise detalhada de custos para atacar a 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 mapeiam para o mesmo endereço de conta. Isso poderia levar a riscos de roubo de fundos de contas custodiais. Para mais detalhes, consulte o domínio de pré-imagem ICS20 GetEscrowAddress sobrepõe-se com chaves públicasT:BUG.

3. Conflitos entre endereços de contas de módulo e não-módulo. A construção de endereços de contas públicas é a mesma que os 20 bytes SHA-256 das chaves públicas Ed25519. Embora a segurança de 160 bits seja suficiente para evitar ataques de colisão em endereços públicos específicos, a segurança contra ataques de aniversário é de apenas 80 bits. Essa situação é semelhante a um modo de ataque de semi-aniversário, onde um endereço é gerado pelo rápido SHA-256, e o outro endereço é gerado pelos cálculos de chave pública Ed25519 relativamente mais lentos. Embora essa situação seja mais segura, ainda representa potenciais ataques a 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 erro de configuração do protocolo

• Caso 1: Aviso de Segurança do IBC Dragonberry, vulnerabilidade no processo de transmissão

Antecedentes da vulnerabilidade: IBC usará 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 respectivo processo de verificação de certificação, 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 tempo limite: falha de tempo limite

Fluxograma de fluxo de transmissão de pacote 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 não existê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 que desencadeia a vulnerabilidade pode ser visto na figura abaixo.

Princípio de vulnerabilidade da 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: IBC Security Advisory Huckleberry, vulnerabilidade no processo de transmissão

Contexto 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, ao consultar o número de sequência via GetPacketReceipt, o recibo correspondente não será encontrado dentro dele.

A gravidade deste problema é menor porque o canal transmitido pelo ICS-20 FT está principalmente fora de ordem e o repetidor não depende deste ponto final gRPC para determinar quais pacotes acionam o tempo limite. 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 fazer com que o desempenho do nó de serviço degenere ou até mesmo falhe. O processo específico de desencadeamento pode ser visto na figura abaixo.

Princípio de vulnerabilidade de Huckleberry fluxograma

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 em um endereço Stride chamado senderStrideAddress, e extrai airdropIde o novo endereço de airdrop novoEndereçoStridedos metadados do pacote. Em seguida, chamaAtualizarEndereçoAirdroppara atualizar osenderStrideAddresseReivindicarRegistroCom a atualização do Reivindicação de Registro, novoEndereçoStrideserá capaz de reivindicar o airdrop. No entanto, esta função de atualização verifica apenas se o endereço do remetente da solicitação está vazio e não valida novoEndereçoStride. Como o IBC permite conexões de máquina solo para implementar cadeias habilitadas para IBC, isso apresenta um risco de segurança onde é possível atualizar qualquer outro endereço de conta como o endereço de 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 do neutron, vulnerabilidade de consumo de gás

Antecedentes de vulnerabilidade: No contexto dos contratos inteligentes, há um problema na verificação de taxas para confirmar ou expirar eventos IBC (Comunicação Inter-Blockchain). Essa falha permite que contratos inteligentes maliciosos acionem uma falha 'ErrorOutOfGas'. Essa falha ocorre durante o processamento das mensagens 'OnAcknowledgementPacket' e 'OnTimeoutPacket'. Quando esse erro ocorre, não é possível resolvê-lo através do método usual de 'recuperação de falta de gás'. Como resultado, as transações afetadas falham em ser incluídas no bloco da blockchain. Essa falha pode fazer com que os relayers IBC tentem repetidamente enviar essas mensagens. Tais envios repetidos podem levar a perdas financeiras para os relayers 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 referentes ao protocolo de Comunicação Inter-Blockchain (IBC), conforme apresentado no texto anterior, destacam a natureza ampla e variada dessas 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 aplicativos aprimoram e refinam progressivamente suas funcionalidades de módulos tradicionais, elas incorporam simultaneamente diversas implementações de código em seus módulos IBC. Isso é feito para aumentar o desempenho e atender a requisitos comerciais específicos.

Além das questões de segurança mencionadas anteriormente no componente IBC, novos desafios estão surgindo, especialmente no middleware IBC. Essas preocupações em evolução são esperadas para se tornarem cada vez mais significativas no futuro, especialmente em relação à segurança geral do ecossistema Cosmos. Essa mudança indica uma ênfase crescente em garantir medidas de segurança robustas no módulo IBC.

Conclusão

Nossa investigação sobre a segurança do ecossistema Cosmos, envolvendo auditorias detalhadas, sumarizações e categorizações, tem se concentrado em seus dois componentes mais críticos: o Cosmos SDK e o protocolo IBC. Com base em nossa ampla experiência prática, compilamos uma coleção abrangente de conhecimento geral em auditoria.

Este relatório destaca os desafios únicos apresentados por uma rede heterogênea como Cosmos, especialmente dada sua suporte para interações entre cadeias. A complexidade e a natureza dispersa de seus componentes tornam a tarefa de garantir sua segurança formidável. Isso exige não apenas a aplicação de 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 desses obstáculos, estamos otimistas. Ao documentar e analisar cenários comuns e desafios de segurança, como fizemos neste relatório, estamos abrindo caminho para melhorar progressivamente a estrutura geral de segurança dentro do ecossistema diversificado do Cosmos.

Aviso Legal:

1. Este artigo é reproduzido a partir de [CertiK]. Todos os direitos autorais pertencem ao autor original [CertiK]. Se houver objeções a esta reimpressão, entre em contato com o Gate Learnequipe e eles vão lidar com isso prontamente.
2. Responsabilidade de Isenção: As visões e 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 equipe Gate Learn. Salvo indicação em contrário, copiar, distribuir ou plagiar os artigos traduzidos é proibido.