Guia de Segurança do Ecossistema Cosmos: Desconstruindo os cenários de segurança de diferentes componentes do Ecossistema Cosmos

Este artigo não inclui apenas a análise das principais vulnerabilidades de segurança anteriores no ecossistema Cosmos, mas também classifica algumas vulnerabilidades de segurança comuns de acordo com suas causas, efeitos, localizações de código, etc., para fornecer orientação de segurança para os desenvolvedores do ecossistema Cosmos ao máximo. , e para fornecer aprendizado e orientação para auditores de segurança.Auditar dados de índice para questões de segurança do Cosmos.

**Título original: “Exclusivo CertiK: Desconstruindo a Segurança Ecológica do Cosmos e Facilitando a Jornada Interestelar Web3” **

Escrito por: CertiK

*Como um dos maiores e mais conhecidos ecossistemas de blockchain do mundo, Cosmos se concentra em melhorar a interoperabilidade de blockchain e alcançar interoperabilidade eficiente entre diferentes blockchains. Uma série de projetos líderes, incluindo Celestia e dYdX v4, são construídos com base no Cosmos SDK e no protocolo IBC. *

*Como os componentes de desenvolvimento do Cosmos são preferidos por mais desenvolvedores, as questões de segurança no ecossistema do Cosmos certamente terão um impacto mais amplo. Por exemplo, a vulnerabilidade Dragonfruit no Cosmos SDK afetou anteriormente a operação normal de várias cadeias públicas convencionais. Devido à natureza descentralizada dos componentes básicos do ecossistema Cosmos, os desenvolvedores precisam usar ou estender diferentes componentes de acordo com diferentes requisitos funcionais.Como resultado, os problemas de segurança no ecossistema Cosmos também são dispersos e diversos. Um estudo que ajude os desenvolvedores a compreender estruturalmente o status atual e as contramedidas da segurança ecológica do Cosmos é muito necessário. *

O “Guia de Segurança do Ecossistema Cosmos” lançado exclusivamente pela equipe CertiK detalha os cenários de segurança de diferentes componentes do ecossistema Cosmos por meio de classificações de fácil leitura*. Este relatório não inclui apenas a análise das principais vulnerabilidades de segurança anteriores no ecossistema Cosmos, mas também classifica algumas vulnerabilidades de segurança comuns de acordo com suas causas, efeitos, localizações de código, etc., para fornecer orientação de segurança aos desenvolvedores do ecossistema Cosmos na maior medida possível, e fornecer aprendizado e orientação para auditores de segurança.Auditar dados de índice para questões de segurança do Cosmos. *

*A equipe CertiK tem ajudado a melhorar a segurança ecológica do Cosmos e de toda a Web3 por meio de pesquisa e mineração contínuas. Traremos regularmente vários relatórios de segurança de projetos e pesquisas técnicas. Continue prestando atenção! Se você tiver alguma dúvida, pode entrar em contato conosco a qualquer momento. *

*A seguir está o texto completo do "Guia de Segurança Ecológica do Cosmos"👇. *

Visão geral

Cosmos é uma rede cross-chain de blockchain de código aberto, aberta e altamente escalável** e um dos ecossistemas de blockchain mais conhecidos do mundo. Cosmos é uma rede heterogênea lançada pela CometBFT (antiga equipe Tendermint) que suporta interação entre cadeias. Consiste em vários blockchains independentes e paralelos para formar uma rede descentralizada. Sua visão é quebrar o efeito ilha da informação e realizar diferentes blocos Interoperabilidade entre cadeias. Na atual era de múltiplas cadeias, a realização da interação entre cadeias tornou-se uma necessidade urgente na indústria de blockchain.

O Cosmos fornece um modelo eficiente de cadeia cruzada, especialmente adequado para cadeias públicas com foco em campos verticais específicos. Ao fornecer uma infraestrutura modular de blockchain, o Cosmos oferece conveniência para os desenvolvedores de aplicativos escolherem e usarem a cadeia pública que atenda às suas necessidades.

Os aplicativos e protocolos no ecossistema Cosmos são conectados usando o IBC (Protocolo de Comunicação Inter-Blockchain), que permite a interação entre blockchains independentes, permitindo que ativos e dados fluam livremente. A visão do Cosmos é construir uma internet de blockchains que forneça a possibilidade de escalar e interagir um grande número de blockchains autônomos e fáceis de desenvolver.

Durante muito tempo, a CertiK manteve toda a atenção e investigação sobre o ambiente ecológico do Cosmos. Acumulamos experiência suficiente em questões de segurança ecológica do Cosmos. Neste relatório de pesquisa, apresentaremos nossos resultados de exploração e pesquisa sobre a segurança do ecossistema Cosmos, focando principalmente na segurança do Cosmos SDK, na segurança do protocolo IBC e na segurança do CometBFT. E nas quatro direções. da segurança do CosmWasm, o objeto de discussão se estenderá dos componentes básicos do Cosmos até a cadeia básica ou cadeia de aplicativos do Cosmos. Através da análise e expansão de questões semelhantes, mostraremos aos leitores sobre o ecossistema do Cosmos de baixo para cima. Os pontos de segurança envolvidos na própria cadeia.

Devido à complexidade e diversidade do ecossistema Cosmos, as questões de segurança existentes também apresentam características diversas. Portanto, este relatório de pesquisa não cobre todos os tipos de vulnerabilidades de segurança. ** Ele apenas discute as características mais típicas e a existência do Cosmos ecológico cadeia. Vulnerabilidades mais prejudiciais**. Se você quiser saber mais detalhes sobre outros problemas de segurança, entre em contato com os engenheiros de segurança da CertiK para discussão.

fundo

• CometBFT: a base da escalabilidade entre cadeias

CometBFT é um algoritmo de consenso inovador, incluindo dois componentes principais: o mecanismo de consenso subjacente (CometBFT Core) e a interface de blockchain de aplicação universal (ABCI). Seu algoritmo de consenso adota consenso híbrido PBFT + Bonded PoS para garantir que os nós registrem transações de forma síncrona. Como componente central da escalabilidade do Interchain, o CometBFT mantém a segurança, a descentralização e a integridade do ecossistema Interchain por meio do consenso do validador.

• Cosmos SDK: Modularidade e novos recursos

O Cosmos SDK é um kit de ferramentas que ajuda os desenvolvedores a acelerar o processo de desenvolvimento e fornece recursos modulares e conectáveis. Usando o Cosmos SDK, os desenvolvedores podem criar seu próprio blockchain ou componentes funcionais com base no algoritmo de consenso CometBFT. Obtenha um desenvolvimento conveniente e reduza o tempo de desenvolvimento. ciclo. Atualmente é adotado em muitos projetos de blockchain, como Cronos, Kava e o recentemente lançado dYdX V4. Os planos de desenvolvimento futuro centrar-se-ão na modularização e na introdução de novas funcionalidades, permitindo aos programadores criar aplicações modulares mais complexas e promovendo um ecossistema mais amplo e mais forte.

• Protocolo IBC: Interoperabilidade e escalabilidade aprimoradas

O protocolo IBC (Inter-Blockchain Communication Protocol) permite transferência de dados segura, descentralizada e sem permissão entre blockchains. Como o Cosmos é uma rede descentralizada composta por vários blockchains independentes e paralelos e usa tecnologia de retransmissão para realizar cadeias cruzadas entre diferentes blockchains, pode-se dizer que o IBC é a parte central de todo o projeto. A Fundação Interchain está atualmente focada em dois tópicos: escalabilidade e usabilidade. Ao melhorar a escalabilidade e a interoperabilidade do IBC, a Cosmos aumentará ainda mais a capacidade do seu ecossistema, permitindo interações perfeitas entre blockchains, aplicações e contratos inteligentes.

• CosmWasm: Desbloqueando implantação descentralizada e sem permissão

CosmWasm (Cosmos WebAssembly) é uma estrutura de contrato inteligente baseada em WebAssembly projetada especificamente para o ecossistema Cosmos. Ele permite que os desenvolvedores implantem aplicativos descentralizados sem requisitos de permissão, ao mesmo tempo que permite que os desenvolvedores de blockchain separem seus ciclos de desenvolvimento de produtos do desenvolvimento de blockchain, reduzindo assim o custo de atualizações de validadores. Além disso, também possui arquitetura modular, integração Cosmos SDK, comunicação cross-chain e outros recursos.

Até agora, os protocolos Cosmos SDK e IBC são relativamente maduros e são os mais amplamente usados no atual ecossistema Cosmos.

Do ponto de vista dos desenvolvedores da cadeia, a maioria das funções personalizadas exigidas pela cadeia ecológica atual no Cosmos podem ser concluídas com base no Cosmos SDK.A fim de realizar algumas operações especiais no processo de operação entre cadeias ou para fins de otimização desempenho, etc., os desenvolvedores de cadeias personalizarão seus próprios módulos IBC. Além disso, um pequeno número de cadeias modificará e personalizará mecanismos subjacentes, como o CometBFT Core. Devido a limitações de espaço, este relatório de pesquisa não será realizado por enquanto Este relatório de pesquisa se concentrará na análise dos pontos técnicos e questões de segurança do Cosmos SDK e do protocolo IBC.

Guia de segurança do Cosmos SDK

O Cosmos SDK é uma estrutura poderosa e flexível para a construção de aplicações blockchain e protocolos descentralizados. Desenvolvido pela Interchain Foundation, é um componente central da Cosmos Network, uma rede descentralizada de blockchains interconectados.

O Cosmos SDK foi projetado para simplificar o desenvolvimento de aplicativos blockchain personalizados e permitir interoperabilidade perfeita entre diferentes blockchains. O Cosmos SDK possui principalmente os seguintes recursos: Arquitetura modular, capacidade de personalização, baseada em CometBFT, implementação de interfaces correspondentes IBC e amigável ao desenvolvedor. O Cosmos SDK garante forte segurança aproveitando o mecanismo de consenso subjacente do CometBFT Core para proteger a rede contra ataques maliciosos e fornecer proteção aos ativos e dados dos usuários. Além disso, sua modularidade permite que os usuários projetem facilmente módulos personalizados. Apesar dessas vantagens, ainda podem existir vulnerabilidades de segurança quando os desenvolvedores usam o Cosmos SDK para implementar seus próprios aplicativos.

Do ponto de vista da auditoria de segurança, precisamos ser abrangentes em nossos objetivos de auditoria e considerar plenamente os riscos de segurança de todos os ângulos. No entanto, do ponto de vista da pesquisa de segurança, precisamos prestar mais atenção às vulnerabilidades de segurança que podem causar impacto significativo. tempo Evite os maiores riscos de segurança tanto quanto possível dentro de um determinado período de tempo e forneça ajuda mais eficaz ao provedor de serviços de integração. Nesta perspectiva, é muito necessário e valioso classificar algumas vulnerabilidades com alto grau de perigo e grande impacto e analisar os seus modelos de vulnerabilidade**.

Entre as interfaces ABCI em todo o ecossistema Cosmos, nos concentramos nas quatro interfaces BeginBlock, EndBlock, CheckTx e DeliverTx. As duas primeiras envolvem diretamente a lógica de execução de um único bloco, enquanto as duas últimas envolvem a execução de sdk.Msg ( Ecossistema Cosmos O processamento específico da estrutura básica de dados para transmissão de mensagens).

Como a lógica de implementação de várias cadeias de aplicativos no ecossistema Cosmos pode ser baseada em módulos e amostras semelhantes aos do Cosmos SDK, ao analisar e compreender as vulnerabilidades de segurança abaixo, você precisa ter um conceito básico do processo de execução do módulo do Cosmos SDK.

No ecossistema Cosmos, as transações são inicialmente criadas no agente do usuário, depois assinadas e transmitidas para nós dentro do blockchain. Os nós utilizam o método CheckTx para verificar vários detalhes da transação, como assinaturas, saldo do remetente, sequência da transação e gás fornecido. Se a transação passar na verificação, ela será adicionada ao mempool, aguardando para ser incluída em um bloco. Além disso, se a transação falhar na verificação, uma mensagem de erro será enviada ao usuário, fazendo com que a transação seja rejeitada. Durante a execução do bloco, as transações são verificadas posteriormente, o que é feito através do método DeliverTx, para garantir consistência e finalidade.

No Cosmos SDK, o ciclo de vida de uma transação pode ser brevemente descrito como o seguinte processo:

**1. Criação de transações: **As transações são criadas no lado do cliente usando várias ferramentas, CLI ou no front-end.

2. Adicionar ao pool de memória: A transação é adicionada ao pool de memória onde o nó envia uma mensagem ABCI -CheckTx para a camada de aplicação para verificar a validade e receber o resultado abci.ResponseCheckTx. No CheckTx, a transação é decodificada do formato de byte para o formato Tx e, em seguida, ValidateBasic() é chamado em cada sdk.Msg de Tx para fazer uma verificação preliminar de validade sem estado. Se o aplicativo tiver um anteHandler correspondente, ele primeiro executará sua lógica interna, depois chamará a função runTx e, finalmente, chamará a função RunMsgs() para processar o conteúdo específico de sdk.Msg. Se CheckTx for bem-sucedido, a mensagem será adicionada ao pool de memória local como candidata para o próximo bloco e será transmitida para nós pares via P2P.

**3 Incluído em um bloco de proposta: **No início de cada rodada, o proponente cria um bloco contendo a última transação e, finalmente, o nó completo é responsável pelo validador de consenso, concordando em aceitar o bloco ou votar em um bloco vazio peça de zona.

**4. Mudança de estado: **DeliverTx é chamado para iterar as transações no bloco, semelhante a CheckTx, mas chama runTx no modo Deliver e realiza mudanças de estado. MsgServiceRouter é chamado para rotear diferentes mensagens na transação para diferentes módulos e, em seguida, executa cada mensagem correspondente no Msg Server. Posteriormente, uma verificação é executada após a execução da mensagem e, se alguma falhar, o estado é restaurado. Durante a execução, use o medidor de gás para monitorar quanto combustível (gás) é usado. Se ocorrer algum erro de combustível (por exemplo, pouco combustível), as alterações de estado serão revertidas com as mesmas consequências de uma falha de execução.

5 Bloco de envio: Quando um nó recebe votos validadores suficientes, ele envia um novo bloco para ser adicionado ao blockchain e finaliza a transição de estado na camada de aplicação.

Diagrama do ciclo de vida da transação no ecossistema Cosmos

A seguir está a lógica de execução específica do Cosmos SDK, que pode ser facilmente lida e compreendida ao analisar o caminho de acionamento da vulnerabilidade abaixo:

Cosmos SDK concentra-se na lógica de execução específica do ABCI

Classificação de vulnerabilidade comum

Antes de compreender a classificação das vulnerabilidades, precisamos de ter uma classificação básica dos níveis de vulnerabilidade, o que ajudará a identificar melhor as vulnerabilidades de segurança perigosas e a evitar, tanto quanto possível, potenciais riscos de segurança.

Considerando o grau de perigo e o escopo do impacto, nos concentramos principalmente em vulnerabilidades de segurança críticas e importantes, que geralmente podem causar os seguintes riscos:

1. A corrente para de funcionar

2. Perda de fundos

3. Afeta o status do sistema ou 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. Configurações de status erradas

3. A verificação está faltando ou não é razoável

4. Problema de exclusividade

5. Problemas de algoritmo de consenso

6. Lacunas lógicas na implementação

7. Questões de características linguísticas

Análise de vulnerabilidade

Devido à particularidade da modularidade ecológica do Cosmos, há um grande número de casos em que os módulos se utilizam e chamam uns aos outros dentro dos módulos em várias implementações de cadeia.Portanto, há casos em que o caminho do gatilho da vulnerabilidade é inconsistente com o caminho controlável da variável de posição do gatilho de vulnerabilidade. Estamos analisando a vulnerabilidade Ao olhar para os motivos específicos do gatilho, não devemos nos concentrar apenas no caminho do gatilho, mas também no caminho controlável das principais variáveis da vulnerabilidade. Isso pode nos ajudar a definir melhor o modelo de vulnerabilidade.

A corrente parou de funcionar

Na maioria dos casos, o culpado pela interrupção da cadeia é um problema durante a execução de um único bloco.No entanto, no desenvolvimento histórico do Cosmos, também houve vulnerabilidades de segurança consensuais que fizeram com que a cadeia tivesse que parar ativamente para reparar. , então o impacto está aqui As vulnerabilidades de segurança do tipo consenso também são discutidas em termos dos efeitos de fazer com que a cadeia pare de funcionar. Discutiremos esses dois tipos de problemas separadamente.

O primeiro tipo de situação são vulnerabilidades comuns do tipo negação de serviço.As razões específicas são principalmente o tratamento inadequado de falhas e operações de passagem onde os limites do loop podem ser afetados pelos usuários. Essas vulnerabilidades geralmente fazem com que a cadeia pause ou desacelere sua operação.

Como mencionado no artigo anterior, Cosmos SDK e CometBFT são infraestruturas-chave no ecossistema Cosmos. Eles não são usados apenas pela cadeia básica do Cosmos, mas também por várias cadeias de aplicativos que implementam sua própria lógica com base em sua arquitetura, para que todas cumpram com a interface ABCI do CometBFT. Regras, 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 Chain Halt são problemas que podem afetar diretamente a execução do código de bloco, então o o caminho de sua ocorrência pode basicamente ser rastreado até as interfaces BeginBlock. e EndBlock.

O segundo tipo de situações são vulnerabilidades que afetam o consenso e geralmente estão relacionadas à implementação de diversas cadeias.Atualmente, são conhecidas por serem comuns em alguns problemas de verificação de processamento lógico, calibração de tempo e aleatoriedade. Tais vulnerabilidades afetarão essencialmente o princípio de descentralização do blockchain. Intuitivamente, podem não ter muito impacto, mas se forem projetadas de forma maliciosa, ainda causarão maiores riscos de segurança.

Categoria 1

• Caso 1: Projeto SuperNova

Histórico de vulnerabilidade: Falta de verificação de endereço na operação de distribuição de moedas, resultando em falha na operação e perda de fundos. No módulo de cunhagem, cada cunhagem de token depende do valor da aposta. No entanto, se o pool não existir ou o endereço do contrato for inserido incorretamente, poderá ocorrer um comportamento inesperado no módulo de cunhagem, fazendo com que o blockchain pare de funcionar. No módulo do pool de recompensas, o endereço do contrato do pool não é verificado. Se a operação de distribuição falhar, a cadeia simplesmente irá parar de funcionar.

Localização da vulnerabilidade:

Trecho de código vulnerável:

Caminho do gatilho de vulnerabilidade:

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

Keeper.DistributeMintedCoin

Keeper.distributeLPIncentivePools

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

Patch de vulnerabilidade:

O patch está localizado no módulo de processamento de mensagens do poolincentive (x/poolincentive/types/msgs.go), não no módulo mint.

A verificação do endereço é realizada na mensagem durante o processamento de MsgCreateCandidatePool (ou seja, na criação do pool), para eliminar a possibilidade de endereços incorretos da causa raiz.

• Caso 2: Projeto de Segurança Interchain Cosmos

endereço do projeto:

Histórico de vulnerabilidade: os validadores podem desacelerar a cadeia de fornecimento enviando várias mensagens AssignConsumerKey no mesmo bloco. A função AssignConsumerKey definida em x/ccv/provider/keeper/key_assignment.go permite que os validadores atribuam diferentes consumerKeys a cadeias de consumidores aprovadas. Para fazer isso, consumerAddrsToPrune AddressList adiciona um elemento. Como esse AddressList é atravessado no EndBlocker em x/ccv/provider/keeper/relay.go, um invasor pode usá-lo para desacelerar a cadeia de provedores. Para realizar esse ataque, um ator mal-intencionado pode criar transações com múltiplas mensagens AssignConsumerKey e enviar essas transações para a cadeia de provedores. A base de consumerAddrsToPrune AddressList será a mesma da mensagem AssignConsumerKey enviada. Como resultado, a execução do EndBlocker consumirá mais tempo e recursos do que o esperado, fazendo com que a cadeia de provisionamento fique lenta ou até pare.

Localização da vulnerabilidade:/blob/6a856d183cd6fc6f24e856e0080989ab53752102/x/ccv/provider/keeper/key_assignment.go#L378

Trecho de código vulnerável:

Caminho do gatilho de vulnerabilidade:

msgServer.AssignConsumerKey

Keeper.AssignConsumerKey

AppModule.EndBlock

EndBlockCIS

Lidar comLeadingVSCMaturedPackets

HandleVSCMaturedPacket

PruneKeyAssignments

• Caso 3: Módulo Quicksilver Project-Airdrop

Histórico 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 travamentos para lidar com erros nos métodos BeginBlock e EndBlock pode fazer com que a cadeia pare quando ocorrer um erro. O EndBlocker liquidou airdrops inacabados sem considerar se o módulo tinha tokens suficientes para desencadear uma falha, fazendo com que a cadeia parasse de funcionar.

Localização da vulnerabilidade: ‍60f4047e2f2f403d67701b030e/x/airdrop/keeper/abci.go#L15

Trecho de código vulnerável:

Caminho do gatilho de vulnerabilidade:

AppModule.EndBlock

Keeper.EndBlocker

Keeper.EndZoneDrop

Patch de vulnerabilidade:

O código de processamento de pânico foi removido diretamente e substituído pela gravação do log de erros.

• Caso 4: Projeto de Segurança Interchain Cosmos

endereço do projeto:

Histórico de vulnerabilidade: um invasor pode realizar um ataque de negação de serviço enviando vários tokens para o endereço de recompensa da cadeia fornecedora.

No processo de execução EndBlocker da cadeia de consumidores, a função SendRewardsToProvider definida em x/ccv/consumer/keeper/distribution.go obtém o saldo de todos os tokens em tstProviderAddr e os envia para a cadeia de provedores. Para conseguir isso, ele deve percorrer todos os tokens encontrados no endereço de recompensa e enviá-los para a cadeia fornecedora, um por um, via IBC. Como qualquer pessoa pode enviar tokens para o endereço de recompensa, um invasor pode criar e enviar um grande número de tokens com denominações diferentes, por exemplo, usando uma cadeia com um módulo de fábrica de tokens, para lançar um ataque de negação de serviço. Portanto, a execução do EndBlocker consumirá mais tempo e recursos do que o esperado, fazendo com que a cadeia de consumo fique mais lenta ou até mesmo pare.

Localização da vulnerabilidade:/blob/6a856d183cd6fc6f24e856e0080989ab53752102/x/ccv/consumer/keeper/distribution.go#L103

Trecho de código vulnerável:

Caminho do gatilho de vulnerabilidade:

AppModule.EndBlock

EndBlock

EndBlockRD

EnviarRecompensasParaProvedor

Segundo tipo de situação

Este tipo de problema de consenso pode não trazer sérios danos intuitivos, mas se considerarmos os princípios e sistemas essenciais de todo o blockchain, ou olharmos para essas vulnerabilidades a partir de cenários específicos, o impacto e os danos que elas trazem não são necessariamente óbvios. É menos prejudicial. do que outras vulnerabilidades convencionais. Além disso, esse tipo de vulnerabilidade também tem algo em comum.

• Caso número um

Histórico de vulnerabilidade: Cosmos SDK Security Advisory Jackfruit

O comportamento não determinístico do método ValidateBasic no módulo x/authz do Cosmos SDK pode facilmente interromper o consenso. A estrutura da mensagem MsgGrant do módulo x/authz contém um campo Grant que inclui o tempo de expiração da autorização concedida definida pelo usuário. No processo de verificação ValidateBasic() da estrutura Grant, compare suas informações de hora com as informações de hora local do nó em vez das informações de hora do bloco. Como a hora local não é determinística, os carimbos de data e hora de cada nó podem ser diferentes, o que levará a questões de consenso.

Aviso de vulnerabilidade:

Trecho de código vulnerável:

Patch de vulnerabilidade:

Problemas como carimbos de data/hora não aparecem apenas em componentes básicos, como o Cosmos SDK, mas vulnerabilidades semelhantes também apareceram em várias cadeias de aplicativos.

• Caso 2

Histórico de vulnerabilidade: SuperNova, projeto nova

endereço do projeto:

Use time.Now() para retornar o carimbo de data/hora do sistema operacional. A hora local é subjetiva e, portanto, não determinística. Como pode haver pequenas diferenças nos carimbos de data/hora de nós individuais, a cadeia pode não chegar a um consenso. No módulo ICAControl, a função de envio de transações utiliza time.Now() para obter o timestamp.

Localização da vulnerabilidade: _msgs.go#L14

Trecho de código vulnerável:

Patch de vulnerabilidade:

Alterado de carimbo de data/hora local para horário 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 3

Histórico de vulnerabilidade: módulo Oracle do projeto BandChain

endereço do projeto:

Os comentários na base de código indicam que o módulo oracle deve ser executado antes do piqueteamento para implementar penalidades aos violadores do protocolo oracle. A ordem de aparecimento no código é: na função SetOrderEndBlockers, o módulo de promessa é executado antes do módulo oracle. Se o módulo de piquetagem fosse executado antes do módulo oracle, então seria impossível penalizar os validadores por piquetagem, etc. com base na verificação feita no módulo oracle.

Localização da vulnerabilidade:

Trecho de código vulnerável:

Pode-se observar que a implementação específica da vulnerabilidade e a anotação da vulnerabilidade são completamente invertidas, e o módulo oracle deve ser classificado antes do módulo de penhor.

• Caso 4

Histórico de vulnerabilidade: módulo de controle de acesso do projeto Sei Cosmos

endereço do projeto:

Em várias instâncias de várias bases de código do Cosmos, a iteração do mapa go usa o tipo de mapa da linguagem go e itera sobre ele. Como a iteração do mapa da linguagem Go não é determinística, isso fará com que os nós alcancem estados diferentes, o que pode causar problemas de consenso e fazer com que a cadeia pare de funcionar. Uma abordagem mais apropriada é classificar as chaves do mapa em uma fatia e iterar sobre as chaves classificadas. Esse tipo de problema é relativamente comum e é causado pela aplicação de recursos da linguagem.

Na implementação de BuildDependencyDag em x/accesscontrol/keeper/keeper.go, o nó itera sobre o anteDepSet. Devido ao comportamento não determinístico da iteração do mapa em Go, ValidateAccessOp pode ter dois tipos diferentes de erros, o que pode causar falha no consenso.

Localização da vulnerabilidade:/blob/afe957cab74dd05c213d082d50cae02dd4cb6b73/x/accesscontrol/keeper/keeper.go#L314C9-L314C9

Trecho de código vulnerável:

De acordo com esses casos, pode-se descobrir que as vulnerabilidades que fazem com que a cadeia pare de funcionar passivamente são muitas vezes as mais prejudiciais, e a relação lógica entre as causas das vulnerabilidades pode ser rastreada até o processo de execução que afeta diretamente a operação de um bloco único no blockchain. Para algumas vulnerabilidades de segurança de consenso, a cadeia muitas vezes para de funcionar para repará-las.A relação lógica entre as causas das vulnerabilidades pode ser rastreada até o processo operacional geral e o status do blockchain. Diferente do foco da vulnerabilidade que causa perda de capital que discutiremos a seguir, a vulnerabilidade que causa perda de capital geralmente não julga seu impacto perigoso específico com base no caminho lógico do problema, mas presta mais atenção ao proprietário dos fundos , A quantidade de fundos, o escopo de afetar os fundos e a forma de afetar os fundos, etc.

Perda de fundos

Problemas de perda de fundos são comuns no processamento lógico de mensagens sdk.Msg e IBC. É claro que também existem algumas lacunas que podem fazer com que a cadeia pare de funcionar. O impacto específico depende do efeito. Em relação a lacunas específicas, nos concentramos no antigo aqui. Além disso, como o IBC é uma parte muito importante do ecossistema Cosmos, inevitavelmente envolverá algumas vulnerabilidades do IBC. Discutiremos a superfície de ataque específica e as vulnerabilidades correspondentes do IBC no próximo capítulo.

As perdas de fundos são comuns em situações lógicas, como consumo de gás, fundos bloqueados e impossibilitados de serem retirados, fundos perdidos durante a transmissão, erros de lógica de cálculo que causam perdas de fundos e IDs de armazenamento de fundos que não garantem a exclusividade.

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

• Antecedentes da vulnerabilidade: projeto SuperNova

endereço do projeto:

Se os dígitos decimais da zona forem superiores a 18, os fundos poderão ser bloqueados. Neste código de projeto, não há limite superior para o número de casas decimais para uma região e pode exceder 18 dígitos. No ClaimSnMesssage, ClaimShareToken é usado quando os usuários desejam reivindicar seus tokens de compartilhamento. No entanto, se as casas decimais da região forem superiores a 18, a conversão falhará e os ativos não poderão ser extraídos do sistema. Portanto, ao controlar o número de casas decimais na área, a falha na transação pode ser acionada diretamente.

Localização da vulnerabilidade:/blob/v0.6.3/x/gal/keeper/claim.go#L167

Trecho de código vulnerável:

Caminho do gatilho de vulnerabilidade:

msgServer.ClaimSnAsset

Keeper.ClaimShareToken

Keeper.ConvertWAssetToSnAssetDecimal

precisãoMultiplicador

• Antecedentes da vulnerabilidade: projeto SuperNova

endereço do projeto:/

A exclusividade da zona não é verificada. Nas áreas cadastradas, utilize o ID da área para verificar a exclusividade do token base (BaseDenom). O BaseDenom de cada área deve ser único. Se o valor do token base for definido incorretamente, resultará em perda de fundos. Antes de definir o token base na 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 o mesmo BaseDenom, resultando em perda de fundos.

Localização da vulnerabilidade:/blob/v0.6.3/x/icacontrol/keeper/msg_server.go#L99

Trecho de código vulnerável:

Patch de vulnerabilidade: verificação DenomDuplicateCheck adicionada

Além disso, o primeiro caso no primeiro caso em que a corrente deixa de funcionar é devido a uma quebra que leva ao fracasso da cunhagem, o que também é uma forma de perda de capital.

• Antecedentes da vulnerabilidade: projeto Supernova

endereço do projeto:/

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 ficará inacessível e os fundos correspondentes não poderão ser sacados. Um entendimento mais popular é que o estado é definido antes do SendTx e o estado não é modificado após a falha, resultando na falha da retirada dos fundos e na impossibilidade de sacar novamente na próxima vez.

Localização da vulnerabilidade:/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/gal/keeper/msg_server.go#L356

Trecho de código vulnerável:

De acordo com esta parte dos casos, verifica-se que a lógica de implementação das operações relacionadas com fundos depende principalmente do processamento de diversas mensagens.Claro, também existem casos como o primeiro tipo de caso - a operação de cunhagem envolvida em o processo de execução do BeginBlock. A falha nessas operações também pode resultar em perda de fundos. No geral, ao concentrar a nossa auditoria nos módulos de código envolvidos nas operações dos fundos, podemos aumentar significativamente a probabilidade de descobrir tais vulnerabilidades.

Afeta o status do sistema ou a operação normal

O âmbito deste tipo de problema é relativamente amplo.Os dois primeiros perigos que acabamos de discutir podem, na verdade, ser considerados um subconjunto de tipos de vulnerabilidade que afectam o estado ou o funcionamento normal do sistema. Além disso, as mais perigosas são alguns tipos lógicos de vulnerabilidades. Em grande medida, tais vulnerabilidades gerarão diferentes riscos de segurança de acordo com a lógica de negócios do projeto, mas devido à estrutura de componentes do Cosmos SDK Devido à sua semelhança e modularidade, erros semelhantes são frequentemente cometidos ao implementar códigos específicos. Aqui estão os tipos comuns de vulnerabilidades:

Verificação de variável incompleta no tipo sdk.Msg

Como vários projetos implementaram vários tipos derivados baseados em sdk.Msg, o Cosmos SDK não detecta realmente os elementos de todos os tipos existentes de acordo, resultando na omissão de alguma detecção de variável incorporada chave, portanto, existem certos riscos de segurança.

• Caso 1: Aviso de segurança do Cosmos SDK Barberry

Histórico da vulnerabilidade: MsgCreatePeriodicVestingAccount.ValidateBasic O mecanismo de verificação não possui julgamento sobre o status da conta, como sobrevivência. Com PeriodicVestingAccount definido em x/auth, um invasor pode inicializar a conta da vítima como uma conta atribuída maliciosamente que permite depósitos, mas não retiradas. Quando os usuários depositam fundos em suas contas, esses fundos ficam permanentemente bloqueados e não podem ser sacados pelo usuário.

Patch de vulnerabilidade:

Trecho de código vulnerável:

Além disso, o Cosmos-SDK Security Advisory Elderflower e o Cosmos-SDK Security Advisory Jackfruit são, na verdade, problemas que ocorrem no link ValidateBasic. O primeiro está faltando diretamente a chamada para ValidateBasic, e o último é sobre a variável timestamp dentro da mensagem. Problemas de verificação . Nas cadeias de aplicativos, esses problemas são ainda mais comuns. Projetos como ethermint, pstake-native e quicksilver experimentaram vulnerabilidades de segurança semelhantes nas medidas de verificação usadas para processar mensagens.

Além do tipo de verificação, na lógica de processamento do sdk.Msg, você também encontrará operações de loop envolvendo uma grande quantidade de consumo de gás, processamento de falhas irracionais, etc. O risco será menor do que se a cadeia parar de funcionar, mas ainda pode afetar o funcionamento normal do sistema ou causar a perda de fundos na cadeia.

Tipos comuns de vulnerabilidades

Além das vulnerabilidades de segurança exclusivas do negócio do projeto, existem também alguns modelos de vulnerabilidade mais comuns. Por exemplo, o terceiro caso de perda de fundos é uma operação que muda o estado antes de enviar uma mensagem. Este tipo de vulnerabilidade é muito semelhante a as vulnerabilidades em contratos inteligentes. Ao transmitir fundos, mudar o próprio estado antes muitas vezes leva a problemas como reentrada ou estados de erro legados. Cenários em que a configuração do estado e a transmissão de mensagens são intimamente combinadas são, na verdade, muito comuns no blockchain, e muitas vulnerabilidades causam grandes perigos, todos decorrentes desses problemas. Além disso, existem também algumas vulnerabilidades de segurança computacional, como vulnerabilidades de divisão por zero, desvios de consumo de gás, uso de versões vulneráveis, etc. Essas vulnerabilidades afetarão o status do sistema ou a operação normal do sistema.

Problema de exclusividade

Como o blockchain envolve um grande número de operações de pesquisa e armazenamento de leitura, a singularidade da nomenclatura é muito importante na implementação de certas funções. Por exemplo, o caso de perda de capital 2 mencionado acima é um problema de exclusividade.Além disso, algumas variáveis do tipo string ou matriz de bytes que representam fatores-chave e outros fatores importantes às vezes apresentam certos riscos em sua composição de prefixo, como se há “/” Ao final de cada nomenclatura, etc., um pouco de descuido pode fazer com que o nome seja forjado em uma string com outro significado, levando a uma série de problemas como perda de fundos, erros de consenso, etc.

Problemas de recursos de idioma

Este tipo de problema é mais geral, mas tem mais características a seguir, por isso é mais fácil de encontrar, como o problema de iteração do mapa de golang, alguns problemas de mecanismo de pânico na ferrugem, etc. usando a linguagem correspondente. Liste os pontos que levam aos riscos correspondentes e preste atenção individual durante o uso ou auditoria para evitar ao máximo tais erros.

Resumo

Com base em nossa exploração das questões de segurança subjacentes do ecossistema Cosmos, não é difícil descobrir que tais questões não são aplicáveis apenas ao ecossistema Cosmos. Existem muitos modelos de vulnerabilidade que também podem ser usados em outras cadeias ecológicas. A seguir estão algumas pesquisas relevantes sobre as questões de segurança do ecossistema Cosmos. Sugestões e Resumo:

• **Foco nas vulnerabilidades da infraestrutura: **Os componentes principais do CometBFT e do Cosmos SDK também podem ter vulnerabilidades, portanto, esses componentes precisam ser atualizados e mantidos regularmente para garantir a segurança.
• Revisão imediata de bibliotecas de terceiros: Os desenvolvedores do Cosmos costumam usar bibliotecas de terceiros para estender a funcionalidade de seus aplicativos. No entanto, estas bibliotecas podem conter vulnerabilidades potenciais, pelo que estas bibliotecas precisam de ser revistas e atualizadas para reduzir o risco.
• Cuidado com ataques maliciosos a nós: No ecossistema Cosmos, os nós de consenso são um componente-chave da rede. O algoritmo de tolerância a falhas bizantinas de um nó pode ser vulnerável a ataques, portanto, os nós precisam ser protegidos para evitar mau comportamento.
• Preste atenção à segurança física: Para o hardware e servidores que executam nós do Cosmos, são necessárias medidas de segurança física para evitar acesso não autorizado e possíveis ataques.
• Revisão de código necessária: Devido à natureza aberta do Cosmos SDK e do ecossistema CometBFT, os desenvolvedores e revisores devem revisar o código principal, bem como o código escrito em módulos personalizados, para identificar e corrigir possíveis problemas de segurança.
• Cuidado com as ferramentas do ecossistema: O ecossistema Cosmos inclui muitas ferramentas e aplicativos que também exigem análises de segurança e atualizações regulares para garantir sua segurança.

Guia de segurança do protocolo IBC

Este módulo se concentrará nas questões de segurança relacionadas ao protocolo IBC (Protocolo de Comunicação Inter-Blockchain). O protocolo IBC é uma parte extremamente importante do Cosmos. Seu papel é construir uma ponte interativa entre várias cadeias. Se outros tipos de pontes entre cadeias fornecem soluções para alguns problemas relativamente independentes, então pode-se dizer que o protocolo IBC fornece um protocolo unificado solução básica e suporte técnico subjacente para problemas de interação entre cadeias. IBC é um protocolo que permite que blockchains heterogêneos entreguem quaisquer dados de maneira confiável, ordenada e com confiança minimizada.

Desde o advento do Bitcoin, o espaço blockchain experimentou um crescimento explosivo. Estão a surgir inúmeras novas redes, cada uma com propostas de valor, mecanismos de consenso, ideologias, círculos eleitorais e razão de ser únicos. Antes da introdução do IBC, a maioria destas cadeias de bloqueio operavam de forma independente, como se existissem em contentores fechados e não pudessem comunicar entre si. No entanto, este modelo fechado é fundamentalmente insustentável.

Se pensarmos em blockchains como países com uma população crescente e cheios de atividades comerciais, alguns blockchains são bons na agricultura e alguns são excelentes na pecuária. Eles naturalmente desejam realizar comércio e cooperação mutuamente benéficos, e cada um exerce seu próprio poder … Vantagem. Não é exagero dizer que o IBC abre um novo mundo de infinitas possibilidades, permitindo que diferentes blockchains ** interoperem, entreguem valor, troquem ativos e serviços ** e estabeleçam conexões sem as restrições das zonas de grande escala atuais. são limitados por problemas inerentes de escalabilidade.

Então, como o IBC atende a essas necessidades e desempenha um papel vital? A razão fundamental é que o IBC é:

1. Sem confiança

2 Pode suportar blockchains heterogêneos

3. Pode ser personalizado na camada de aplicação

4 Tecnologia comprovada e comprovada

A base do protocolo IBC são clientes leves e retransmissores. A cadeia A e a cadeia B, que se comunicam por meio do IBC, têm clientes leves dos livros contábeis uma da outra. A cadeia A não precisa confiar em terceiros e pode chegar a um consenso sobre o status da cadeia B simplesmente verificando o cabeçalho do bloco. Cadeias que interagem via IBC (especialmente módulos) não enviam mensagens diretamente entre si. Em vez disso, a cadeia A sincroniza algumas mensagens do pacote com seu estado. O relé então inspeciona esses pacotes e os entrega à cadeia de destino.

Em geral, o protocolo IBC pode ser dividido em duas camadas, nomeadamente IBC TAO e IBC APP.

IBC TAO: Padrões que definem a transmissão, autenticação e ordenação de pacotes de dados, a camada de infraestrutura. No ICS, isso consiste nas categorias núcleo, cliente e retransmissão.

APP IBC:Um padrão que define manipuladores de aplicativos para pacotes passados pela camada de transporte.Isso inclui, mas não está limitado a, Transferências de Token Fungíveis (ICS-20), Transferências de Tokens Não Fungíveis (ICS-721) e Interconta em Cadeia (ICS-27). ) e pode ser encontrado no ICS na categoria Aplicativos.

Gráfico IBC (do Portal do Desenvolvedor Cosmos)

O protocolo IBC é a espinha dorsal da visão da Cosmos sobre a Internet das Blockchains. Nesse sentido, as escolhas de projeto do IBC foram influenciadas pela especificação TCP/IP. Semelhante à forma como o TCP/IP define padrões para comunicação de computadores, o IBC especifica um conjunto de abstrações comuns que podem ser implementadas para permitir a comunicação de blockchains. O TCP/IP não impõe restrições ao conteúdo dos pacotes retransmitidos pela rede, nem o IBC. Além disso, semelhante à forma como protocolos de aplicativos como HTTP e SMTP são construídos em TCP/IP, instâncias de aplicativos como transmissão de ativos homogêneos/ativos não homogêneos ou chamadas de contratos inteligentes entre cadeias também usam o protocolo IBC como camada base.

Atualmente, os principais problemas que surgem no protocolo IBC são todos sobre transmissão de canais e processamento de pacotes de dados. É claro que também existem grandes problemas na verificação de provas e outros aspectos, mas esses problemas são relativamente poucos. Este artigo se concentra no Acordo IBC PERGUNTAS FREQUENTES. Devido ao design modular do protocolo IBC, os desenvolvedores de aplicativos IBC não precisam se preocupar com detalhes de baixo nível, como cliente, conexão e verificação de provas. No entanto, eles precisam implementar a interface IBCModule e os métodos de processamento correspondentes do Keeper, portanto, muitos problemas relacionados ao protocolo IBC aparecem no caminho do código da interface do IBCModule para receber e processar pacotes de dados (onRecvPacket, OnAcknowledgementPacket, OnTimeoutPacket, etc.).

Classificação de vulnerabilidade comum

No ecossistema Cosmos, o protocolo IBC serve como um hub de conexão. Em termos de tipos de vulnerabilidade, as vulnerabilidades relacionadas ao protocolo IBC são mais abundantes e os locais das vulnerabilidades são mais complexos. Devido à implementação relacionada do protocolo e módulos IBC como Cosmos-SDK e CometBFT. Devido à estreita integração, a implementação de alguns outros módulos do ecossistema Cosmos será inevitavelmente mencionada abaixo. Além disso, o IBC é atualmente usado principalmente no ecossistema Cosmos, portanto seu idioma principal ainda é o Golang. Para obter detalhes, consulte os documentos relacionados ao ibc-go.

Devido a limitações de espaço, não realizaremos aqui uma análise detalhada de cada link e componente do protocolo IBC. Apenas classificaremos e discutiremos algumas vulnerabilidades de segurança existentes. Se você quiser saber uma análise mais detalhada e abrangente, entre em contato com nosso CertiK engenheiros de segurança. Troca e discussão.

Categorias de vulnerabilidade comuns:

1. Nomeando vulnerabilidade

① Vulnerabilidade no processamento de strings

② Vulnerabilidade de processamento de bytecode

2. Vulnerabilidades no processo de transmissão

① Vulnerabilidade de sequência de pacotes

② Vulnerabilidade de tempo limite de pacote

③ Vulnerabilidade de autenticação de pacotes

④ Outras vulnerabilidades de pacotes

3 lacunas lógicas

① Vulnerabilidade de atualização de status

② Consenso de votação e outras lacunas

③ Outras lacunas lógicas

4. Vulnerabilidade no consumo de gás

O protocolo IBC existente tem muitas semelhanças com o processo de auditoria do protocolo Web2 no processo de auditoria e análise de sua segurança. Desta vez iremos analisá-lo na perspectiva de um processo completo de formulação de protocolo, implementação e expansão de aplicação. Algumas questões de segurança e riscos potenciais no protocolo IBC. Como a formulação de protocolos é muitas vezes concluída por um pequeno número de pessoas e organizações, para várias organizações de blockchain, mais trabalho está centrado na implementação e expansão da aplicação dos protocolos, portanto, este artigo também se concentrará na discussão das duas questões de segurança. Isto se deve à ampla cobertura dos riscos de segurança do protocolo IBC, que pode dividir melhor os diferentes tipos de questões de segurança no protocolo em links e módulos correspondentes.

Análise de vulnerabilidade

Desenvolvimento do Acordo IBC

• Caso 1: Protocolo ICS-07, vulnerabilidade lógica

Antecedentes da vulnerabilidade: utilização incorreta do período de desvinculação

As seguintes verificações existem no código:

if currentTimestamp.Sub(consState.Timestamp) >= clientState.UnbondingPeriod {

De acordo com o modelo de segurança Tendermint, os validadores nos NextValidators do bloco (cabeçalho) no momento t precisam ser executados corretamente antes de t+TrustingPeriod, após o qual podem ter outros comportamentos. No entanto, o que é verificado aqui é UnbondingPeriod, não TrustingPeriod, onde UnbondingPeriod>TrustingPeriod. Se o período de consState estiver entre TrustingPeriod e UnbondingPeriod, esse cabeçalho será aceito como base para validação de um dos cabeçalhos conflitantes que constitui má conduta. Durante esse período, os validadores em consState.NextValidators não são mais considerados confiáveis e ex-validadores hostis podem desligar o cliente sem correr nenhum risco.

endereço do projeto:

Localização da vulnerabilidade: #misbehaviour-predicate

_handle.go#L96

Trecho de código vulnerável:

Função de definição de protocolo

Código

Implementação do protocolo IBC

O elo de implementação do protocolo IBC é um local onde é mais provável que ocorram problemas, pois esse elo serve como um elo entre o passado e o próximo.É necessário evitar ao máximo ambiguidades nas especificações do protocolo, e também precisa fornecer uma base mais básica e conveniente para a aplicação e expansão subsequente do protocolo. Portanto, faremos aqui uma pequena classificação das principais questões na implementação do protocolo IBC, a saber:

1. Ambiguidades e irregularidades na implementação do protocolo

2. Problema de erro de configuração de protocolo

Ambiguidades e irregularidades na implementação do protocolo

• Caso 1: Protocolo ICS-20, vulnerabilidade de nomenclatura

Histórico de vulnerabilidade: conflito de endereço de hospedagem. GetEscrowAddress() é SHA256 (ID da porta + ID do canal) truncado para 20 bytes. Existem três problemas com esta abordagem:

1. Não há separação de domínio entre portas e canais, o uso da concatenação de strings não separará os domínios de portas e canais. Por exemplo, as combinações de porta/canal (“transfer”, “channel”) e (“trans”, “ferchannel”) fornecerão o mesmo endereço gerenciado, que é um SHA256 truncado (“transferchannel”). Uma vulnerabilidade pode surgir se determinados módulos com funcionalidade de biblioteca forem capazes de selecionar IDs de portas e canais.

2. Conflito entre endereços de conta de módulo. Usando uma sequência alfanumérica arbitrária na pré-imagem SHA-256, o tamanho da pós-imagem é de 160 bits. Essa combinação de imagem traseira pequena e função hash rápida torna possível o ataque de aniversário porque sua segurança é reduzida apenas para 80 bits. Isso significa que são necessárias aproximadamente 2 ^ 80 tentativas para encontrar uma colisão entre dois endereços de contas de garantia diferentes. Em 2018, uma análise detalhada dos custos do ataque ao truncamento SHA256 foi realizada no contexto do Tendermint, provando que este ataque é viável do ponto de vista dos custos, descobrindo que colisões significam que duas contas de hospedagem diferentes são mapeadas para o mesmo endereço de conta. Isso pode levar ao risco de roubo de fundos da conta de garantia. Para obter detalhes, consulte ICS20 GetEscrowAddress sobreposições de domínio de pré-imagem com chaves públicasT:BUG.

3 Conflito entre endereços de conta de módulo e não módulo. O endereço da conta pública é construído de forma idêntica ao SHA-256 de 20 bytes da chave pública Ed25519. Embora 160 bits de segurança sejam suficientes para evitar ataques de colisão contra endereços públicos específicos, apenas 80 bits de segurança estão disponíveis contra ataques de aniversário. Esta situação se assemelha a um padrão de ataque de meio aniversário, onde um endereço é gerado pelo rápido SHA-256 e o outro endereço é gerado pelo cálculo relativamente lento da chave pública Ed25519. Embora este cenário fosse mais seguro, ainda abre potenciais ataques a depósitos e contas públicas.

endereço do projeto:

Localização da vulnerabilidade:

Trecho de código vulnerável:

Problema de erro de configuração de protocolo

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

Antecedentes da vulnerabilidade: IBC usará uma estrutura de pacotes ao processar pacotes de dados de aplicativos.De acordo com o mecanismo de tempo limite, mecanismos de confirmação síncronos e assíncronos 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 tempo limite: falha de tempo limite

Fluxograma de transmissão de pacotes do aplicativo IBC

Quando ocorre um tempo limite, 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 tempo limite configurável pelo usuário. A vulnerabilidade Dragonberry origina-se do ICS-23 (IBC).A causa raiz desta vulnerabilidade é que os usuários podem forjar provas de inexistência no processo de verificação (ou seja, provas falsas de que nenhum pacote de dados foi recebido), ignorando assim as verificações de segurança. e falsificação Uma situação de tempo limite IBC “razoável” é usada para enganar o protocolo IBC, fazendo com que o repetidor envie pacotes de tempo limite com certificados falsos e pode evoluir para um problema de gasto duplo ICS-20. O processo de acionamento específico da vulnerabilidade pode ser visto na figura abaixo.

Fluxograma do princípio de vulnerabilidade do Dragonberry

endereço do projeto:

Localização da vulnerabilidade:

Trecho de código vulnerável:

• Caso 2: IBC Security Advisory Huckleberry, vulnerabilidade do processo de transmissão

Histórico da vulnerabilidade: UnreceivedPackets apenas constrói uma resposta encontrando o recebimento de pacote correspondente para cada número de sequência incluído na consulta. Isso se aplica apenas a canais fora de ordem, pois os canais ordenados usam nextSequenceRecv em vez de recebimentos de pacotes. Portanto, em um canal ordenado, a consulta do número de série via GetPacketReceipt não encontrará o recibo.

A gravidade deste problema é menor porque o canal transmitido pelo ICS-20 FT está praticamente fora de serviço e o repetidor não depende deste ponto final grpc para determinar o pacote de tempo limite de disparo. 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á o risco de causar degradação do desempenho ou até mesmo travamento do nó de serviço. O processo de acionamento específico pode ser visto na figura abaixo.

Fluxograma do princípio da vulnerabilidade do Huckleberry

endereço do projeto:

Localização da vulnerabilidade:keeper/grpc_query.go#L408

Trecho de código vulnerável:

Aplicação e extensão do protocolo IBC

• Caso 1: vulnerabilidade de lançamento aéreo, vulnerabilidade lógica

Histórico da vulnerabilidade: TryUpdateAirdropClaim Esta função converte o endereço do remetente do pacote IBC em um endereço Stride chamado senderStrideAddress e extrai o airdropId e o novo endereço de airdrop newStrideAddress dos metadados do pacote. Em seguida, chame UpdateAirdropAddress para atualizar senderStrideAddress e ClaimRecord. Com a atualização do ClaimRecord, newStrideAddress poderá receber airdrops. No entanto,a função de atualização aqui apenas verifica se o endereço solicitado pelo remetente está vazio e não verifica o newStrideAddress.Uma vez que o ibc permite que máquinas individuais se conectem à cadeia que implementa o IBC habilitado, existe a possibilidade de atualizar qualquer outra conta endereço como o endereço de lançamento aéreo. Risco de segurança.

endereço do projeto:

Localização da vulnerabilidade: _ibc.go#L119

Trecho de código vulnerável:

• Caso 2: vulnerabilidade do módulo ibc de nêutrons, vulnerabilidade no consumo de gás

Histórico de vulnerabilidade: A taxa paga pelo contrato inteligente para a confirmação/tempo limite do evento IBC não é suficientemente verificada, e um contrato inteligente malicioso pode explorar isso para causar uma falha de ErrorOutOfGas durante o processamento de mensagens OnAcknowledgementPacket e OnTimeoutPacket. Essas falhas não serão recuperadas pela execução outOfGasRecovery, o que significa que as transações não serão incluídas no bloco e farão com que o relé IBC envie mensagens repetidamente, o que pode eventualmente fazer com que o relé perca fundos e a rede descarte muitos pacotes. ferir.

endereço do projeto:

Localização da vulnerabilidade:

x/interchaintxs/keeper/ibc_handlers.go#L62

Trecho de código vulnerável:

Resumo

De acordo com a pesquisa e análise acima sobre as questões de segurança do protocolo IBC, não é difícil descobrir que as questões de segurança do protocolo IBC são amplamente distribuídas e diversas, mas os principais problemas ainda ocorrem na implementação e expansão da aplicação do Protocolo IBC**. Embora as principais cadeias de aplicativos enriqueçam e melhorem gradualmente a funcionalidade de seus módulos tradicionais, a fim de atender às suas próprias necessidades de negócios e otimizar os efeitos operacionais, elas também adicionaram diferentes implementações de código aos módulos IBC correspondentes.

Além das questões de segurança no link IBC mencionadas acima, outras questões de segurança, como o middleware IBC, também estão surgindo. Acredito que, no futuro, as questões de segurança no módulo IBC se tornarão uma parte importante da segurança ecológica do Cosmos.

Resumir

No processo de exploração e pesquisa da segurança do ecossistema Cosmos, passamos por trabalhos complexos de auditoria, resumo e classificação, discutimos as questões de segurança dos protocolos Cosmos SDK e IBC, os mais críticos no ecossistema Cosmos, e através de ricos experiência prática, resumiu um grande número de experiências comuns de auditoria.

Este relatório destaca os desafios enfrentados ao enfrentar redes heterogêneas que suportam interações entre cadeias. Devido à complexidade e à dispersão de seus elementos constituintes, é igualmente desafiador realizar auditorias de segurança nesses componentes. Não precisamos apenas usar os existentes experiência em segurança para solucionar alguns riscos de segurança inerentes, você também precisa enfrentar constantemente novos cenários de segurança e analisar novos problemas de segurança.

Apesar disso, ainda acreditamos que através de alguns cenários comuns e questões de segurança resumidas neste relatório, a segurança geral do ecossistema da rede heterogênea Cosmos pode ser gradualmente melhorada.