El ecosistema Cosmos, reconocido a nivel mundial como una de las redes de blockchain más grandes y notables, prioriza la interoperabilidad blockchain. Este enfoque es clave para facilitar la comunicación fluida entre diversas blockchains. El ecosistema alberga varios proyectos líderes como Celestia y dYdX v4, todos desarrollados utilizando el Cosmos SDK y el protocolo IBC. La creciente preferencia de los desarrolladores por los componentes de Cosmos ha llevado a un impacto ampliado de problemas de seguridad dentro del ecosistema. Un caso destacado es la vulnerabilidad de Dragonfruit en el Cosmos SDK, que interrumpió las operaciones en numerosas blockchains públicas principales.

Dada la naturaleza descentralizada de los componentes principales de Cosmos, a menudo se requiere que los desarrolladores adapten y extiendan estos componentes en función de necesidades funcionales específicas. Esto conduce a una fragmentación de desafíos de seguridad dentro del ecosistema de Cosmos. En consecuencia, hay una necesidad apremiante de un enfoque estructurado para comprender y abordar estas preocupaciones de seguridad. Este artículo tiene como objetivo proporcionar un análisis exhaustivo del panorama de seguridad actual en el ecosistema de Cosmos y esbozar estrategias efectivas de respuesta.

El equipo de CertiK se dedica a reforzar la seguridad de la red de Cosmos y del ecosistema más amplio de Web3 a través de una investigación y desarrollo continuos. Nos entusiasma compartir nuestros hallazgos y conocimientos con usted a través de informes de seguridad regulares y actualizaciones de investigación técnica. Si tiene alguna consulta, nuestro equipo está siempre disponible para contactar.

Aquí está el texto completo de la “Guía de Seguridad del Ecosistema Cosmos” 👇.

Visión general de Cosmos

Considerado como uno de los ecosistemas de blockchain más destacados del mundo, Cosmos se destaca por sus capacidades de red de código abierto, escalables e interconectadas. Desarrollado por el equipo de CometBFT, originalmente conocido como Tendermint, Cosmos tiene como objetivo eliminar los silos de información y facilitar la interoperabilidad entre diversas blockchains. En una era en la que coexisten múltiples redes de blockchain, la necesidad de interacción entre cadenas es más apremiante que nunca.

Cosmos se distingue por ofrecer un modelo eficiente de cadena cruzada, especialmente beneficioso para cadenas públicas con enfoques verticales específicos. Su infraestructura modular de blockchain empodera a los desarrolladores de aplicaciones, brindándoles la flexibilidad para seleccionar y utilizar cadenas públicas que se alineen con sus requisitos específicos.

En el corazón del ecosistema Cosmos se encuentra el Protocolo de Comunicación Inter-Blockchain (IBC), que conecta aplicaciones y protocolos en diferentes blockchains independientes. Esto facilita no solo la transferencia sin problemas de activos y datos, sino que también se alinea con la visión de Cosmos de crear un 'internet de blockchains'. Este concepto imagina una vasta red de blockchains autónomos y fácilmente desarrollados, interconectados para su expansión e interacción.

La participación e investigación de CertiK en la seguridad de Cosmos

Durante un largo período, CertiK ha estado profundamente involucrado en la investigación del ecosistema de Cosmos. Nuestro equipo ha adquirido una experiencia sustancial en abordar los desafíos de seguridad dentro de este entorno. En este informe, compartiremos nuestras ideas y descubrimientos sobre la seguridad del ecosistema de Cosmos, centrándonos en cuatro áreas clave: seguridad de Cosmos SDK, seguridad del protocolo IBC, seguridad de CometBFT y seguridad de CosmWasm. Nuestra discusión abarcará todo, desde los componentes fundamentales del ecosistema de Cosmos hasta sus cadenas fundamentales y de aplicación. Al examinar y extrapolar problemas relacionados, nuestro objetivo es presentar un análisis integral y desde la base de los aspectos críticos de seguridad dentro del ecosistema de Cosmos.

Dada la complejidad y diversidad del ecosistema de Cosmos, se enfrenta a un amplio espectro de desafíos de seguridad. Este informe se concentra principalmente en las amenazas más características y significativas para la cadena ecológica de Cosmos. Para obtener más información o discutir otros aspectos de seguridad, le animamos a comunicarse con los ingenieros de seguridad de CertiK.

Antecedentes

CometBFT: Mejorando la escalabilidad entre cadenas en su núcleo

En el corazón de la escalabilidad de Interchain se encuentra CometBFT, un algoritmo de consenso de vanguardia fundamental para garantizar la seguridad, descentralización e integridad del ecosistema de Interchain. Este algoritmo es un compuesto de dos componentes principales: el núcleo de CometBFT, que sirve como el motor de consenso fundamental, y una interfaz universal de cadena de bloques de aplicación (ABCI). Al combinar elementos de PBFT (Tolerancia Práctica a Fallas Bizantinas) y Prueba de Participación Asegurada (PoS), CometBFT sincroniza nodos para mantener registros precisos de transacciones, desempeñando así un papel crucial en el consenso del validador dentro del entorno de Interchain.

Cosmos SDK: Acelerando el Desarrollo de Blockchain con Modularidad

El SDK de Cosmos se presenta como un conjunto de herramientas potente que simplifica y acelera el desarrollo de blockchain. Su diseño modular y características enchufables permiten a los desarrolladores construir sus propias blockchains o componentes funcionales sobre el algoritmo de consenso CometBFT. Este enfoque no solo facilita el desarrollo, sino que también acorta significativamente el ciclo de desarrollo. La eficacia del SDK se evidencia por su adopción en numerosos proyectos, incluidos Cronos, Kava y el recientemente lanzado dYdX V4. Mirando hacia el futuro, el Cosmos SDK planea mejorar su modularidad e introducir nuevas características, lo que permitirá la creación de aplicaciones más sofisticadas y modulares, fomentando así un ecosistema más amplio y robusto.

Protocolo IBC: Impulsando la interoperabilidad y la escalabilidad entre blockchains

El protocolo de Comunicación Inter-Blockchain (IBC) es fundamental para facilitar la transferencia de datos segura, descentralizada y sin permisos entre blockchains dentro de la red Cosmos. Dado que Cosmos es una red descentralizada que comprende múltiples blockchains independientes y paralelos conectados a través de tecnología de relay, el papel del protocolo IBC en mejorar la escalabilidad y la interoperabilidad es central. El enfoque actual de la Fundación Interchain se centra en mejorar estos aspectos del protocolo IBC, con el objetivo de fortalecer las interacciones sin problemas entre blockchains, aplicaciones y contratos inteligentes dentro del ecosistema Cosmos.

CosmWasm: Facilitando la implementación de aplicaciones descentralizadas

CosmWasm (Cosmos WebAssembly) es un marco de contrato inteligente diseñado para el ecosistema Cosmos. Basado en WebAssembly, permite a los desarrolladores implementar aplicaciones descentralizadas sin necesidad de permisos específicos. Este marco permite a los desarrolladores de blockchain separar el desarrollo de productos del desarrollo de blockchain, reduciendo la carga en las actualizaciones del validador. Las características de CosmWasm incluyen una arquitectura modular, integración con Cosmos SDK y capacidades de comunicación entre cadenas. Cosmos SDK y el protocolo IBC, al ser relativamente maduros, son ampliamente utilizados en el ecosistema actual de Cosmos.

Adaptación y personalización dentro del ecosistema Cosmos

Para los desarrolladores de cadenas en el ecosistema Cosmos, el Cosmos SDK satisface la mayoría de las necesidades de personalización. Durante las actividades de intercadenas, los desarrolladores de cadenas pueden adaptar sus módulos IBC para operaciones especiales u optimización de rendimiento. Si bien algunas cadenas modifican motores subyacentes como CometBFT Core, las limitaciones de espacio impiden una discusión detallada de dichas modificaciones en este informe. Por lo tanto, esta investigación se centra principalmente en los matices técnicos y consideraciones de seguridad del Cosmos SDK y el protocolo IBC.

Guía de seguridad de Cosmos SDK

La Guía de Seguridad de Cosmos SDK proporciona una visión general completa de los aspectos de seguridad de Cosmos SDK, un marco avanzado para el desarrollo de aplicaciones blockchain y protocolos descentralizados. Creado por la Fundación Interchain, este marco es fundamental para la red Cosmos, que es una red expansiva de blockchains interconectadas.

En su núcleo, el Cosmos SDK está diseñado para agilizar la creación de aplicaciones de blockchain a medida, al tiempo que facilita la interacción fluida entre diversas blockchains. Sus características destacadas incluyen una estructura modular, una amplia capacidad de personalización, integración con el núcleo CometBFT para el consenso y la implementación de interfaces IBC, todo lo cual contribuye a su atractivo para los desarrolladores. Una fortaleza clave del Cosmos SDK es su dependencia del motor de consenso CometBFT Core, que proporciona sólidas medidas de seguridad. Este motor desempeña un papel vital en la defensa de la red contra ataques maliciosos y en la protección de los activos y datos de los usuarios. La naturaleza modular del SDK permite a los usuarios crear módulos a medida con facilidad. Sin embargo, los desarrolladores deben estar atentos, ya que pueden surgir vulnerabilidades de seguridad al implementar aplicaciones utilizando el Cosmos SDK.

Desde el punto de vista de la auditoría de seguridad, es esencial evaluar a fondo las posibles amenazas de seguridad desde múltiples perspectivas. Contrariamente, en la investigación de seguridad, el énfasis se desplaza hacia la identificación de vulnerabilidades que podrían tener repercusiones significativas. Este enfoque tiene como objetivo mitigar las principales amenazas de seguridad de manera rápida, ofreciendo así una asistencia más efectiva a los servicios que integran el SDK. Es crucial identificar y examinar las vulnerabilidades que representan riesgos graves y tienen implicaciones generalizadas.

Un punto focal dentro del Cosmos SDK es la interfaz ABCI, que es integral para el ecosistema Cosmos. Esta interfaz comprende cuatro componentes clave: BeginBlock, EndBlock, CheckTx y DeliverTx. BeginBlock y EndBlock están directamente involucrados en la lógica de ejecución de bloques individuales. En contraste, CheckTx y DeliverTx se ocupan del procesamiento de sdk.Msg, la estructura de datos fundamental para la transmisión de mensajes dentro del ecosistema Cosmos.

Para comprender y abordar las vulnerabilidades de seguridad mencionadas, primero se debe entender el ciclo de vida de las transacciones en el ecosistema Cosmos. Las transacciones se originan en agentes de usuario, donde se crean, firman y luego se transmiten a los nodos de la cadena de bloques. Los nodos emplean el método CheckTx para validar detalles de la transacción como las firmas, el saldo del remitente, la secuencia de la transacción y el gas proporcionado. Las transacciones válidas se ponen en cola en el mempool, esperando ser incluidas en un bloque, mientras que las inválidas son rechazadas, con mensajes de error transmitidos a los usuarios. Durante el procesamiento del bloque, se aplica el método DeliverTx para garantizar la consistencia y la determinación transaccional.

En el SDK de Cosmos, el ciclo de vida de la transacción es un proceso de múltiples etapas, que abarca la creación, validación, inclusión en un bloque, cambios de estado y compromiso final. Este proceso se puede describir en los siguientes pasos:

1. Creación de transacción: Los usuarios generan transacciones utilizando diversas herramientas como Interfaces de Línea de Comando (CLI) o clientes de frontend.

2. Adición al Mempool: Una vez creadas, las transacciones ingresan al mempool. Aquí, los nodos envían un mensaje ABCI (Interfaz de la Cadena de Bloques de la Aplicación), conocido como CheckTx, a la capa de aplicación para verificar su validez. Las transacciones se someten a decodificación del formato de bytes al formato Tx. Cada sdk.Msg dentro de la transacción se somete a verificaciones preliminares sin estado por medio de la función ValidateBasic(). Además, si la aplicación incluye un anteHandler, su lógica se ejecuta antes de la función runTx, lo que conduce a la función RunMsgs() para procesar el contenido sdk.Msg. Un CheckTx exitoso resulta en la transacción en cola en el mempool local, listo para ser incluido en el próximo bloque, y simultáneamente se transmite a los nodos pares a través de P2P.

3. Inclusión en un Bloque Propuesto: Durante el comienzo de cada ronda, el proponente reúne un bloque que contiene transacciones recientes. Los validadores, que son responsables de mantener el consenso, aprueban este bloque o optan por un bloque vacío.

4. Cambios 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. Compromiso de bloque: Al recibir suficientes votos de validadores, un nodo compromete el nuevo bloque en la cadena de bloques. Esta acción finaliza las transiciones de estado en la capa de aplicación, marcando la finalización del proceso de transacción.

)

[Esta sección incluye un diagrama que representa el ciclo de vida de las transacciones en el ecosistema de Cosmos.]

[La siguiente sección proporciona la lógica de ejecución específica de la clave ABCI en Cosmos SDK, útil para comprender y analizar las vulnerabilidades discutidas más adelante.]

)

Categorías Comunes de Vulnerabilidades

Antes de comprender la clasificación de vulnerabilidades, necesitamos tener una división básica del nivel de peligro de las vulnerabilidades. Esto ayuda a identificar mejor las vulnerabilidades de seguridad de alto riesgo y evitar posibles riesgos de seguridad.

)

Teniendo en cuenta el nivel de peligro y el alcance del impacto, nos enfocamos principalmente en vulnerabilidades de seguridad clasificadas como Críticas y Mayores, que generalmente pueden causar los siguientes riesgos:

1. Operación de detención de cadena
2. Pérdida financiera
3. Afectando el estado del sistema o su funcionamiento normal

Las causas de estos peligros suelen ser los siguientes tipos de vulnerabilidades de seguridad:

1. Denegación de Servicio
2. Configuración de estado incorrecta
3. Falta de verificación o verificación irrazonable
4. Problemas de singularidad
5. Problemas de algoritmo de consenso
6. Flaws lógicos en la implementación
7. Problemas de funciones del lenguaje

Análisis de vulnerabilidades en el ecosistema Cosmos

El ecosistema Cosmos, conocido por su estructura modular, a menudo se encuentra con la interutilización de módulos y la interllamada dentro de sus cadenas. Esta complejidad conduce a escenarios donde la ruta de activación de vulnerabilidad y las variables de ubicación son inconsistentes. Al comprender estas vulnerabilidades, es crucial no solo considerar la ruta de activación, sino también la ruta controlable de las variables críticas de la vulnerabilidad. Este enfoque dual ayuda a definir y categorizar mejor el modelo de vulnerabilidad.

Operación de parada de cadena: causas y tipos

Las paradas de la cadena suelen deberse a problemas encontrados durante la ejecución de un solo bloque. Sin embargo, la historia de Cosmos incluye instancias en las que las vulnerabilidades de seguridad del consenso necesitaron paradas activas de la cadena para reparaciones. Estos problemas se dividen en dos categorías distintas.

El primer tipo se ve comúnmente en las Vulnerabilidades de Denegación de Servicio: A menudo son el resultado de un manejo inadecuado de fallos y operaciones de límite de bucle influenciadas por el usuario. Estas vulnerabilidades pueden llevar a que la cadena se pause o se ralentice significativamente.

Cosmos SDK y CometBFT, infraestructuras clave en el ecosistema de Cosmos, no solo son utilizados por las cadenas base en Cosmos, sino también por varias cadenas de aplicaciones basadas en su arquitectura. Todas siguen las reglas de la interfaz ABCI de CometBFT. El enfoque de su superficie de ataque también se encuentra en su interfaz ABCI, y la mayoría de las vulnerabilidades de seguridad que pueden causar la detención de la cadena son problemas que pueden afectar directamente la ejecución del código de bloque. Por lo tanto, sus caminos de ocurrencia generalmente se pueden rastrear hasta las interfaces BeginBlock y EndBlock.

El segundo tipo de situación involucra Vulnerabilidades que afectan al consenso: a menudo se relacionan con la implementación en diferentes cadenas e incluyen problemas en la validación del procesamiento lógico, la calibración del tiempo y la aleatoriedad. Estas vulnerabilidades golpean en el corazón del principio de descentralización de la cadena de bloques. Aunque al principio pueden no parecer graves, en manos de un actor malicioso representan una amenaza de seguridad sustancial.

Ejemplos del Primer Tipo

Ejemplo 1: Análisis de Vulnerabilidades del Proyecto SuperNova

Antecedentes de vulnerabilidad: En el proceso de distribución de creación de monedas dentro del Proyecto SuperNova, surge un problema crítico debido a la falta de verificación de la dirección. Esta omisión puede provocar un fallo en la operación y, consecuentemente, una pérdida financiera. Específicamente, el módulo de creación de monedas, que es fundamental para la generación de tokens, depende de la cantidad apostada. Sin embargo, este proceso es susceptible a errores. Por ejemplo, si el grupo designado no existe o si se ingresa erróneamente la dirección del contrato, puede provocar malfunciones en el módulo de creación de monedas. Tales errores tienen el potencial de detener por completo la operación de toda la cadena de bloques. Además, en el módulo de recompensas, falta la verificación de la dirección del contrato del grupo. Esta omisión significa que cualquier fallo en la operación de distribución podría causar una parada inmediata de la cadena de bloques.

Ubicación de la vulnerabilidad: Enlace de GitHub de SuperNova

Fragmento de código vulnerable:

Ruta de activación de vulnerabilidad:

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

Keeper.DistributeMintedCoin

Keeper.distributeLPIncentivePools

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

Parche de vulnerabilidad:

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

El parche se encuentra en el módulo de manejo de mensajes de Gateincentive (x/Gateauincentive/types/msgs.go), no en el módulo de creación. Se agregó la verificación de dirección al mensaje MsgCreateCandidatePool para eliminar la posibilidad de direcciones incorrectas desde la raíz.

Ejemplo 2: Proyecto de Seguridad Interchain de Cosmos

Dirección del proyecto: Enlace de GitHub de Seguridad de Interconexión de Cosmos

Antecedentes de vulnerabilidad: Los validadores pueden ralentizar la cadena del proveedor al enviar múltiples mensajes AssignConsumerKey en el mismo bloque. En el archivo x/ccv/provider/keeper/key_assignment.go, la función AssignConsumerKey permite a los validadores asignar diferentes consumerKeys a cadenas de consumidores aprobadas. La AddressList consumerAddrsToPrune aumenta en un elemento para realizar esta operación. Dado que esta AddressList se itera en EndBlocker en x/ccv/provider/keeper/relay.go, los atacantes pueden explotarla para ralentizar la cadena del proveedor. Para este ataque, el actor malintencionado puede crear transacciones con múltiples mensajes AssignConsumerKey y enviarlos a la cadena del proveedor. La cardinalidad de la AddressList consumerAddrsToPrune será la misma que la de los mensajes AssignConsumerKey enviados. Por lo tanto, la ejecución de EndBlocker tomará más tiempo y recursos de lo esperado, ralentizando o incluso deteniendo la cadena del proveedor.

Ubicación de la vulnerabilidad: Enlace de GitHub de Seguridad Interchain de Cosmos

Segmento de código de vulnerabilidad:

Ruta de activación de vulnerabilidades:

msgServer.AssignConsumerKey

Keeper.AssignConsumerKey

AppModule.EndBlock

EndBlockCIS

Manejar paquetes maduros de VSC líder

Manejar el paquete maduro de VSC

PruneKeyAssignments

Ejemplo 3: Proyecto Quicksilver - Módulo de Airdrop

Antecedentes de vulnerabilidad: BeginBlocker y EndBlocker son métodos opcionales que los desarrolladores de módulos pueden implementar en sus módulos. Se activan al comienzo y al final de cada bloque, respectivamente. Utilizar fallas para manejar errores en los métodos BeginBlock y EndBlock puede hacer que la cadena se detenga en caso de errores. El EndBlocker no consideró si el módulo tenía suficientes tokens para liquidar los airdrops pendientes, lo que podría desencadenar un fallo y detener la cadena.

Ubicación de la vulnerabilidad: Enlace de GitHub de Quicksilver

Segmento de Código de Vulnerabilidad:

Parche de vulnerabilidad: AppModule.EndBlock

Keeper.EndBlocker

Keeper.EndZoneDrop

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

El código de manejo del pánico fue eliminado y reemplazado por el registro de errores.

Ejemplo 4: Proyecto de Seguridad Interchain de Cosmos

Dirección del proyecto: Enlace de GitHub de Seguridad Interchain de Cosmos

Antecedentes de vulnerabilidad: Los atacantes pueden llevar a cabo un ataque de denegación de servicio enviando múltiples tokens a la dirección de recompensa de la cadena proveedora. En el flujo de ejecución de EndBlocker de la cadena consumidora, la función SendRewardsToProvider definida en x/ccv/consumer/keeper/distribution.go recupera el saldo de todos los tokens en tstProviderAddr y los envía a la cadena proveedora. Para lograr esto, debe iterar a través de todos los tokens encontrados en la dirección de recompensa y enviar cada uno a través de IBC a la cadena proveedora. Dado que cualquier persona puede enviar tokens a la dirección de recompensa, los atacantes pueden crear y enviar una gran cantidad de tokens de diferentes denominaciones, por ejemplo, utilizando una cadena con un módulo de fábrica de tokens, para iniciar un ataque de denegación de servicio. Por lo tanto, la ejecución de EndBlocker tomará más tiempo y recursos de lo esperado, ralentizando o incluso deteniendo la cadena consumidora.

Ubicación de la vulnerabilidad: Cosmos Interchain Security GitHub Link

Segmento de código de vulnerabilidad:

Ruta de desencadenamiento de la vulnerabilidad:

AppModule.EndBlock

EndBlock

EndBlockRD

EnviarRecompensasAlProveedor

Segundo Tipo de Situación

Este tipo de problema de consenso puede no causar daños graves inmediatos, pero al considerar los principios fundamentales y el sistema de todo el blockchain, o al analizar estas vulnerabilidades desde escenarios específicos, su impacto y daño pueden no ser menores que otras vulnerabilidades convencionales. Además, estas vulnerabilidades tienen características comunes.

Ejemplo 1

Antecedentes de vulnerabilidad: Aviso de seguridad del Cosmos SDK Jackfruit

El comportamiento no determinista en el método ValidateBasic del módulo x/authz en Cosmos SDK puede llevar fácilmente a una parada del consenso. La estructura del mensaje MsgGrant en el módulo x/authz incluye un campo de concesión que contiene el tiempo de vencimiento otorgado por la autorización definida por el usuario. En el proceso de validación de ValidateBasic() en la estructura de concesión, compara su información de tiempo con la información de tiempo local del nodo en lugar de la información de tiempo de bloque. Dado que el tiempo local es no determinista, las marcas de tiempo pueden diferir entre los nodos, lo que lleva a problemas de consenso.

Anuncio de vulnerabilidad:

• Enlace del foro de Cosmos 1

• Enlace al foro de Cosmos 2

• Enlace de aviso de seguridad de GitHub Cosmos SDK

Segmento de código de vulnerabilidad:

Parche de vulnerabilidad: Enlace de comparación de Cosmos SDK en GitHub

Problemas como marcas de tiempo no solo aparecen en componentes fundamentales como Cosmos SDK, sino que también han ocurrido en diversas cadenas de aplicaciones.

Ejemplo 2

Antecedentes de vulnerabilidad: SuperNova, proyecto nova

Dirección del proyecto: SuperNova Enlace de GitHub

Usar time.Now() devuelve la marca de tiempo del sistema operativo. El tiempo local es subjetivo y, por lo tanto, no determinista. Dado que puede haber pequeñas diferencias en las marcas de tiempo de los nodos individuales, la cadena puede no alcanzar consenso. En el módulo ICAControl, la función de envío de transacción utiliza time.Now() para obtener la marca de tiempo.

Ubicación de la vulnerabilidad: https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/icacontrol/keeper/send_msgs.go#L14

Segmento de código de vulnerabilidad:

Parche de vulnerabilidad:

Cambió de usar la marca de tiempo local a usar la hora del bloque.

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 Tres:

Antecedentes de vulnerabilidad: Módulo de Oracle en el Proyecto BandChain

URL del proyecto: Repositorio de GitHub de BandChain

Los comentarios en el repositorio de código indican que el módulo del oráculo debe ejecutarse antes del staking para implementar medidas de castigo para los infractores del protocolo del oráculo. Sin embargo, en el código, la secuencia está invertida: en la función SetOrderEndBlockers, el módulo de staking se ejecuta antes del módulo del oráculo. Si el módulo de staking se ejecuta antes del módulo del oráculo, sería imposible aplicar sanciones basadas en las verificaciones completadas en el módulo del oráculo.

Ubicación de la vulnerabilidad: Fragmento de código de GitHub de BandChain

Segmento de código de vulnerabilidad:

La vulnerabilidad radica en la implementación real y los comentarios son contradictorios, donde el módulo del oráculo debería colocarse antes del módulo de participación en la puesta en común.

Caso Cuatro:

Antecedentes de vulnerabilidad: Módulo de control de acceso en el Proyecto Sei Cosmos

URL del proyecto: Repositorio de GitHub de Sei Cosmos

En varios casos en los repositorios de código relacionados con Cosmos, existe el uso del tipo de mapa del lenguaje Go y la iteración sobre él. Debido a la naturaleza no determinista de la iteración del mapa de Go, esto podría llevar a que los nodos alcancen diferentes estados, lo que podría causar problemas de consenso y, en consecuencia, detener el funcionamiento de la cadena. Un método más apropiado sería ordenar las claves de mapa en un sector e iterar sobre las claves ordenadas. Estos problemas son comunes y se derivan de la aplicación de las características del lenguaje.

En la implementación de BuildDependencyDag en x/accesscontrol/keeper/keeper.go, hay iteración sobre nodos anteDepSet. Debido al comportamiento no determinista de la iteración de mapas en Go, ValidateAccessOp podría resultar en dos tipos diferentes de errores, lo que podría llevar a un fallo de consenso.

Ubicación de la vulnerabilidad: Sei Cosmos GitHub Code Snippet

Segmento de código de vulnerabilidad:

A partir de estos casos, es evidente que las vulnerabilidades que causan que una cadena se detenga pasivamente suelen ser las más perjudiciales. Su lógica causal se puede rastrear hasta afectar directamente el flujo de ejecución de bloques individuales en una cadena de bloques. En contraste, las vulnerabilidades de seguridad del consenso generalmente resultan en que la cadena se detenga activamente para implementar correcciones, con su lógica causal rastreada hasta afectar el flujo operativo general y el estado de la cadena de bloques. Esto difiere del enfoque de las vulnerabilidades que conducen a pérdidas financieras, donde el impacto peligroso específico no se juzga en función del camino lógico de la ocurrencia del problema, sino que se enfoca en los propietarios de los fondos, la cantidad de dinero involucrada, el alcance y los métodos que afectan a los fondos.

pérdida de fondos

Los problemas de pérdida de capital son comúnmente vistos en el manejo lógico de los mensajes sdk.Msg y mensajes IBC. Por supuesto, también existen algunas vulnerabilidades que pueden causar pérdida de capital entre las razones que pueden detener la operación de una cadena de bloques. El impacto específico depende de la vulnerabilidad particular, y aquí nos enfocamos en la primera. Además, dado que IBC es un componente muy importante del ecosistema Cosmos, inevitablemente involucra algunas vulnerabilidades en IBC. Los detalles sobre la superficie de ataque de IBC y las vulnerabilidades correspondientes se discutirán en el próximo capítulo.

Las pérdidas de capital son comúnmente encontradas en escenarios como el consumo de gas, los fondos bloqueados e incapaces de ser retirados, la pérdida de fondos durante la transferencia, errores en la lógica de computación que llevan a la pérdida de fondos, y la falla en asegurar la unicidad de los IDs de almacenamiento de fondos.

Aquí, tomamos el proyecto SuperNova como ejemplo para analizar tres vulnerabilidades relacionadas.

Antecedentes de vulnerabilidad: Proyecto SuperNova

URL del proyecto: https://github.com/Carina-labs/nova

Si los lugares decimales en una zona superan los 18, los fondos pueden quedar bloqueados. En el código de este proyecto, no hay un límite superior en los lugares decimales de una zona, que pueden superar los 18. En ClaimSnMessage, cuando los usuarios desean reclamar sus tokens compartidos, se utiliza ClaimShareToken. Sin embargo, si los lugares decimales de la zona superan los 18, la conversión fallará y será imposible extraer activos del sistema. Por lo tanto, al controlar los lugares decimales de una zona, es posible desencadenar directamente un fallo y una falla en la transacción.

Ubicación de la vulnerabilidad: https://github.com/Carina-labs/nova/blob/v0.6.3/x/gal/keeper/claim.go#L167

Fragmento de código de vulnerabilidad:

Ruta de activación de la vulnerabilidad:

msgServer.ClaimSnAsset

Keeper.ClaimShareToken

Keeper.ConvertirActivoWEnActivoSDecimal

precisionMultiplier

• Antecedentes de vulnerabilidad: proyecto SuperNova

Dirección del proyecto: https://github.com/Carina-labs/nova/

La singularidad de la zona no está verificada. En las regiones registradas, utiliza el ID de la región para comprobar la singularidad del token base (BaseDenom). El BaseDenom para cada región debe ser único. Si el valor del token base se establece incorrectamente, resultará en una pérdida de fondos. Antes de establecer el token base en el RegisterZone, el proyecto no aseguró que el BaseDenom fuera único en todas las zonas principales. De lo contrario, existiría la posibilidad de que los usuarios almacenaran fondos en otra zona maliciosa que contenga un BaseDenom con el mismo nombre, lo que resultaría en una pérdida de fondos.

Ubicación de la vulnerabilidad: https://github.com/Carina-labs/nova/blob/v0.6.3/x/icacontrol/keeper/msg_server.go#L99

Fragmento de código vulnerable:

Corrección de error: Se añadió la verificación DenomDuplicateCheck

Además, el primer caso en el primer caso donde la cadena deja de funcionar se debe a un fallo que conduce al fracaso de la acuñación, que también es una forma de pérdida de capital.

• Antecedentes de la vulnerabilidad: proyecto Supernova

Dirección del proyecto: https://github.com/Carina-labs/nova/

Actualizaciones de estado faltantes. En el método IcaWithdraw(), si la transacción falla y el estado de la versión no se modifica, el WithdrawRecord será inaccesible y los fondos correspondientes no podrán ser retirados. Una comprensión más popular es que el estado se establece antes de SendTx, y el estado no se modifica después del fallo, lo que provoca que la retirada de fondos falle y no se pueda retirar nuevamente la próxima vez.

Ubicación de la vulnerabilidad: https://github.com/Carina-labs/nova/blob/932b23ea391d4c89525c648e4103a3d6ee4531d5/x/gal/keeper/msg_server.go#L356

Código vulnerable:

Basándonos en este fragmento, podemos discernir que la lógica principal de las operaciones relacionadas con los fondos depende principalmente del manejo de varios mensajes. Por supuesto, también hay casos como el primer escenario que implica operaciones de acuñación en el proceso de ejecución de BeginBlock. Cuando estas operaciones fallan, también pueden provocar pérdidas financieras. En general, al centrar nuestra auditoría en módulos de código que involucran operaciones financieras, podemos aumentar significativamente la probabilidad de descubrir tales vulnerabilidades.

Impactando Estado del Sistema o Operación Normal

El rango de esta categoría de problemas es bastante amplio. Los dos primeros tipos de riesgos que discutimos también pueden considerarse como subconjuntos de vulnerabilidades que afectan al estado del sistema o a su funcionamiento normal. Además de estos, son más peligrosas las diversas vulnerabilidades lógicas. En gran medida, estas vulnerabilidades generan diferentes riesgos de seguridad de acuerdo con la lógica empresarial del proyecto. Sin embargo, debido a las similitudes en la construcción de los componentes de Cosmos SDK y su naturaleza modular, a menudo se producen errores similares en las implementaciones de código específicas. Aquí enumeramos algunos tipos comunes de vulnerabilidades:

- Validación de variable incompleta en el tipo sdk.Msg:

Dado que varios proyectos han implementado una variedad de tipos derivados basados en sdk.Msg, no todos los elementos de los tipos existentes se han verificado adecuadamente en Cosmos SDK. Esto ha llevado a la omisión de verificaciones críticas de variables incrustadas, lo que plantea ciertos riesgos de seguridad.

Caso práctico: Asesor de seguridad del SDK de Cosmos Barberry

Antecedentes de vulnerabilidad: MsgCreatePeriodicVestingAccount.ValidateBasic carece de mecanismos para evaluar el estado de una cuenta, como si está activa. En PeriodicVestingAccount definido en x/auth, un atacante podría inicializar la cuenta de una víctima a una cuenta de su propiedad de forma maliciosa. Esta cuenta permite depósitos pero prohíbe retiros. Cuando los usuarios depositan fondos en su cuenta, estos fondos se bloquearán permanentemente y el usuario no podrá retirarlos.

Parche de vulnerabilidad:

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

Fragmento de código vulnerable:

Además de esto, los problemas en la etapa de ValidateBasic también estaban presentes en Cosmos-SDK Security Advisory Elderflower y Cosmos-SDK Security Advisory Jackfruit. El primero sufrió una omisión directa de la llamada ValidateBasic, mientras que el segundo involucraba problemas con la verificación de la variable de marca de tiempo dentro del mensaje. En las cadenas de aplicaciones, tales problemas son aún más comunes. Proyectos como ethermint, pstake-native y quicksilver han encontrado vulnerabilidades de seguridad similares en sus medidas de verificación de procesamiento de mensajes.

Apart from verification types, there are also issues encountered in the handling logic of sdk.Msg, such as operations involving extensive gas consumption, loops, and unreasonable crash handling. Since the processing chain for messages has corresponding recovery mechanisms, their danger level is somewhat lower than a complete chain shutdown. However, they can still impact the normal operation of the system or lead to loss of funds on the chain.

Tipos comunes de vulnerabilidades

Excluyendo las vulnerabilidades únicas para operaciones de proyectos específicos, existen algunos modelos de vulnerabilidad más comunes. Por ejemplo, el tercer caso de pérdida de fondos es una operación que cambia el estado antes de enviar un mensaje. Este tipo de vulnerabilidad es similar a las que se encuentran en contratos inteligentes, donde cambiar el estado antes de transferir fondos puede llevar a problemas como reentradas o estados erróneos persistentes. Los escenarios donde el establecimiento de estado está estrechamente vinculado a la transmisión de mensajes son bastante comunes en blockchain, y muchas vulnerabilidades significativas se originan a partir de estos problemas. Además, existen vulnerabilidades de seguridad computacional como errores de división por cero, eludir el consumo de gas y el uso de versiones con vulnerabilidades conocidas, todas las cuales pueden afectar el estado del sistema o su operación normal.

Problemas de singularidad

Debido a numerosas operaciones de lectura y escritura en la cadena de bloques, la singularidad en la denominación es extremadamente importante en algunas funcionalidades. Por ejemplo, el segundo caso de pérdida de fondos mencionado anteriormente es un problema de singularidad. Además, la composición de prefijos en variables que representan claves, como cadenas o matrices de bytes, puede plantear riesgos. Un pequeño descuido podría resultar en nombres malinterpretados, lo que llevaría a problemas como pérdida de fondos o errores de consenso.

Problemas de función del idioma

Estos son más amplios pero tienen características identificables, lo que los hace más fáciles de detectar. Ejemplos incluyen problemas con la iteración de mapas en Golang o mecanismos de pánico en Rust. Es recomendable enumerar estos factores de riesgo específicos del lenguaje y prestarles especial atención durante el uso o la auditoría para minimizar tales errores.

Resumen

Desde nuestra exploración de problemas de seguridad subyacentes en el ecosistema de Cosmos, está claro que estos problemas no son exclusivos de Cosmos y también se pueden aplicar a otros ecosistemas de blockchain. Aquí hay algunas recomendaciones y conclusiones sobre los problemas de seguridad en el ecosistema de Cosmos:

• Preste atención a las vulnerabilidades de la infraestructura: componentes clave como CometBFT y Cosmos SDK también pueden tener vulnerabilidades, por lo que las actualizaciones y el mantenimiento regulares son necesarios para la seguridad.

• Revisar bibliotecas de terceros con prontitud: Los desarrolladores de Cosmos a menudo utilizan bibliotecas de terceros para ampliar las funcionalidades de sus aplicaciones. Estas bibliotecas podrían contener vulnerabilidades potenciales, por lo que es necesario revisarlas y actualizarlas para mitigar riesgos.

• Ten cuidado con los ataques maliciosos de nodos: los nodos de consenso son cruciales en el ecosistema de Cosmos. Los algoritmos de tolerancia a fallas bizantinas de estos nodos podrían ser susceptibles a ataques, por lo que garantizar la seguridad del nodo es esencial para prevenir comportamientos maliciosos.

• Considerar la seguridad física: Se requieren medidas de seguridad física para el hardware y los servidores que ejecutan nodos de Cosmos para evitar el acceso no autorizado y posibles ataques.

• Realice las revisiones de código necesarias: Dada la apertura de los ecosistemas Cosmos SDK y CometBFT, los desarrolladores y auditores deben revisar tanto el código central como el código escrito en módulos personalizados para identificar y corregir posibles problemas de seguridad.

• Preste atención a las herramientas del ecosistema: El ecosistema de Cosmos incluye muchas herramientas y aplicaciones, las cuales también deben someterse a revisiones de seguridad y actualizaciones regulares para garantizar su seguridad.

Guía de seguridad del Protocolo IBC

Este módulo se centra en los aspectos de seguridad del protocolo de Comunicación Inter-Blockchain (IBC), un componente crucial en el ecosistema de Cosmos. El protocolo IBC sirve como puente para las interacciones entre diferentes blockchains. Mientras que otros puentes entre cadenas proporcionan soluciones para problemas específicos y aislados, el protocolo IBC ofrece una solución fundamental unificada y soporte técnico subyacente para las interacciones entre cadenas. IBC es un protocolo que permite a las blockchains heterogéneas transferir cualquier dato de manera confiable, ordenada y mínimamente confiable.

Desde la llegada de Bitcoin, el campo de la cadena de bloques ha experimentado un crecimiento explosivo. Han surgido innumerables nuevas redes, cada una con su proposición de valor única, mecanismos de consenso, ideologías, seguidores y razones de existencia. Antes de la introducción del IBC, estas cadenas de bloques operaban de forma independiente, como en contenedores cerrados, incapaces de comunicarse entre sí, un modelo fundamentalmente insostenible.

Si los blockchains se ven como países con poblaciones en crecimiento y actividades comerciales bulliciosas, algunos destacan en la agricultura, otros en la cría de ganado. Naturalmente, buscan un comercio y cooperación mutuamente beneficiosos, aprovechando sus respectivas fortalezas. No es exagerado decir que el IBC ha abierto un nuevo mundo de posibilidades ilimitadas, permitiendo que diferentes blockchains interoperen, transfieran valor, intercambien activos y servicios, y establezcan conexiones, sin verse obstaculizados por los problemas inherentes de escalabilidad de las grandes redes blockchain de hoy en día.

Entonces, ¿cómo satisface IBC estas necesidades y juega un papel tan crucial? Las razones fundamentales son que IBC es:

1. Minimizado de confianza

2. Capaz de soportar blockchains heterogéneos

3. Personalizable en la capa de la aplicación

4. Una tecnología madura y probada

La base del protocolo IBC radica en clientes ligeros y relayers. Las cadenas A y B que se comunican a través de IBC poseen cada una clientes ligeros del libro mayor de la otra. La cadena A, sin necesidad de confiar en un tercero, puede llegar a un consenso sobre el estado de la cadena B verificando sus encabezados de bloque. Las cadenas que interactúan a través de IBC (especialmente módulos) no envían mensajes directamente entre sí. En cambio, la cadena A sincroniza ciertos mensajes en un paquete de datos a su estado. Posteriormente, los relayers detectan estos paquetes de datos y los transfieren a la cadena objetivo.

En general, el protocolo IBC se puede dividir en dos capas: IBC TAO e IBC APP.

• IBC TAO: Define los estándares para la transmisión de paquetes de datos, autenticación y ordenación, esencialmente la capa de infraestructura. En ICS (Estándares Interchain), esto consta de categorías de núcleo, cliente y relé.

• IBC APP: Define los estándares para los controladores de aplicación de paquetes de datos transmitidos a través de la capa de transporte. Estos incluyen, entre otros, transferencias de tokens fungibles (ICS-20), transferencias de tokens no fungibles (ICS-721) y cuentas intercadenas (ICS-27), y se pueden encontrar en la categoría de aplicación de ICS.

Protocolo IBC (Desde el Portal de Desarrolladores de Cosmos)

El protocolo IBC (Inter-Blockchain Communication) es una piedra angular de la visión del ecosistema Cosmos de un “Internet de Blockchains”. En este contexto, las elecciones de diseño del IBC están influenciadas por los estándares TCP/IP. Al igual que TCP/IP establece estándares para la comunicación entre computadoras, IBC especifica un conjunto de abstracciones universales que permiten a las blockchains comunicarse entre sí. Así como TCP/IP no restringe el contenido de los paquetes de datos transmitidos a través de la red, IBC opera de la misma manera. Además, al igual que los protocolos de aplicación como HTTP y SMTP se basan en TCP/IP, las aplicaciones como transferencias de activos homogeneizados/no fungibles o llamadas de contratos inteligentes entre cadenas también utilizan el protocolo IBC como capa fundamental.

Los principales problemas actualmente observados con el protocolo IBC están relacionados con la transmisión de canales y el procesamiento de paquetes. Ha habido problemas significativos en la verificación de la prueba, pero estos son relativamente menos comunes. Este artículo se centra en los problemas comunes del protocolo IBC. Gracias al diseño modular del protocolo IBC, los desarrolladores de aplicaciones IBC no necesitan preocuparse por detalles subyacentes como clientes, conexiones y verificación de pruebas. Sin embargo, necesitan implementar la interfaz IBCModule y los métodos de manejo de Keeper correspondientes. Por lo tanto, muchos problemas relacionados con el protocolo IBC surgen en los caminos de código de las interfaces IBCModule para recibir y procesar paquetes (onRecvPacket, OnAcknowledgementPacket, OnTimeoutPacket, etc.).

Clasificaciones Comunes de Vulnerabilidades

En el ecosistema Cosmos, el protocolo IBC sirve como un hub de conexión. Los tipos de vulnerabilidades asociadas con el protocolo IBC son diversos y complejos debido a la estrecha integración de sus implementaciones con módulos como Cosmos-SDK y CometBFT. Además, dado que IBC se utiliza principalmente en el ecosistema Cosmos, su lenguaje de programación principal es Golang, como se detalla en la documentación de ibc-go.

Debido a limitaciones de espacio, este artículo no profundiza en el análisis detallado de cada aspecto y componente del protocolo IBC. En su lugar, clasifica algunas de las vulnerabilidades de seguridad existentes. Para un análisis más detallado y completo, puede contactar a nuestros ingenieros de seguridad de CertiK para discutirlo.

Clasificaciones Comunes de Vulnerabilidades:

1. Vulnerabilidades de Nomenclatura

   ① Vulnerabilidades de manipulación de cadenas

   ② Vulnerabilidades en el manejo del bytecode

2. Vulnerabilidades en el proceso de transmisión

   ① Vulnerabilidades de Orden de Paquetes

   ② Vulnerabilidades de tiempo de espera del paquete

   ③ Vulnerabilidades de Autenticación de Paquetes

   ④ Otras Vulnerabilidades de Paquetes

3. Vulnerabilidades Lógicas

   ① Actualizar vulnerabilidades del estado

   ② Vulnerabilidades de votación y consenso

   ③ Otras Vulnerabilidades Lógicas

4. Vulnerabilidades de Consumo de Gas

El protocolo IBC existente, en términos de auditoría y análisis de su seguridad, comparte muchas similitudes con los procesos de auditoría de los protocolos Web2. Este análisis disecará algunos de los problemas de seguridad y riesgos potenciales del protocolo IBC desde la perspectiva del establecimiento del protocolo, su implementación y la expansión de su aplicación. Dado que la formulación del protocolo suele ser completada por unas pocas personas y organizaciones, para varias organizaciones blockchain, más trabajo gira en torno a la implementación y expansión de la aplicación del protocolo. Por lo tanto, este artículo se centrará en los problemas de seguridad de estos aspectos. Este enfoque se deriva de la consideración de la amplia gama de riesgos de seguridad cubiertos por el protocolo IBC, lo que permite una mejor categorización de diferentes tipos de problemas de seguridad en etapas y módulos correspondientes.

Análisis de vulnerabilidad

Formulación del Protocolo IBC

Estudio de caso 1: Protocolo ICS-07, Vulnerabilidad lógica

Antecedentes de vulnerabilidad: Uso incorrecto del período de desvinculación

En el código, existe la siguiente validación:

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

Según el modelo de seguridad de Tendermint, para un bloque (encabezado) en el tiempo t, los validadores en NextValidators deben operar correctamente antes de t+TrustingPeriod. Después de eso, pueden exhibir otros comportamientos. Sin embargo, la verificación aquí es para UnbondingPeriod, no TrustingPeriod, donde UnbondingPeriod > TrustingPeriod. Si la fecha límite de consState está entre TrustingPeriod y UnbondingPeriod, entonces este encabezado será aceptado como referencia para validar uno de los encabezados conflictivos que constituyen una mala conducta. Durante este período, los validadores en consState.NextValidators ya no se consideran confiables, y los antiguos validadores hostiles pueden cerrar el cliente sin ningún riesgo.

Dirección del Proyecto: https://github.com/cosmos/ibc/tree/e01da1d1346e578297148c9833ee4412e1b2f254/spec/ics-007-tendermint-client

Ubicación de la vulnerabilidad:

• 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

Vulnerable Code Snippet:

función de definición de protocolo

Código

Implementación del Protocolo IBC

La etapa de implementación del protocolo IBC es una fase en la que es propenso que surjan problemas, ya que desempeña un papel crítico de puente. No solo necesita evitar ambigüedades en las especificaciones del protocolo, sino que también necesita proporcionar interfaces básicas y convenientes para la aplicación y expansión posteriores del protocolo. Por lo tanto, los principales problemas en la etapa de implementación del protocolo IBC pueden clasificarse aún más en:

1. Ambigüedades y problemas no estándar en la implementación del protocolo.

2. Errores en la configuración del protocolo.

Ambigüedades y Problemas no Estándar en la Implementación del Protocolo

Estudio de caso 1: Protocolo ICS-20, Vulnerabilidad de denominación

Antecedentes de vulnerabilidad: Conflicto de dirección custodia. The GetEscrowAddress()la función genera un SHA256 truncado de 20 bytes (ID de puerto + ID de canal). Este método tiene tres problemas:

1. Falta de separación de dominio entre puertos y canales. El método de concatenación de cadenas no separa los dominios del puerto y el canal. Por ejemplo, las combinaciones de puertos/canales ('transfer', 'channel') y ('trans', 'ferchannel') darán como resultado la misma dirección custodial, es decir, el SHA256 truncado ('transferchannel'). Si se permite que ciertos módulos con funciones de biblioteca seleccionen identificadores de puerto y canal, pueden surgir vulnerabilidades.

2. Conflicts between direcciones de cuenta de módulo. Se utilizan cadenas alfanuméricas arbitrarias en la preimagen de SHA-256, con un tamaño de posimagen de 160 bits. Esta pequeña posimagen combinada con una función hash rápida hace factible un ataque de cumpleaños, ya que su seguridad se reduce solo a 80 bits. Significa que aproximadamente se necesitan 2^80 suposiciones para encontrar una colisión entre dos direcciones de cuenta custodiales diferentes. En 2018, se realizó un análisis detallado de costos de atacar la truncación de SHA256 en el contexto de Tendermint, demostrando que dicho ataque es factible desde una perspectiva de costos. Encontrar una colisión significa que dos cuentas custodiales diferentes se asignan a la misma dirección de cuenta. Esto podría llevar a riesgos de que se roben fondos de cuentas custodiales. Para obtener más detalles, consulte el solapamiento de dominios de preimagen de ICS20 GetEscrowAddress con claves públicasT:BUG.

3. Conflictos entre direcciones de cuenta de módulo y de cuenta no módulo. La construcción de direcciones de cuenta pública es la misma que la de los 20 bytes SHA-256 de las claves públicas Ed25519. Aunque la seguridad de 160 bits es suficiente para prevenir ataques de colisión en direcciones públicas específicas, la seguridad contra ataques de cumpleaños es solo de 80 bits. Esta situación es similar a un modo de ataque de cumpleaños parcial, donde una dirección se genera mediante el rápido SHA-256, y la otra dirección se genera mediante los cálculos de clave pública Ed25519 relativamente más lentos. Aunque esta situación es más segura, aún plantea posibles ataques a cuentas de custodia y cuentas públicas.

Dirección del proyecto: https://github.com/cosmos/ibc/tree/e01da1d1346e578297148c9833ee4412e1b2f254/spec/ics-020-fungible-token-transfer

Ubicación de vulnerabilidad: 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

Fragmento de código vulnerable:

Problema de configuración de protocolo

• Caso 1: IBC Security Advisory Dragonberry, vulnerabilidad en el proceso de transmisión

Antecedentes de vulnerabilidad: IBC utilizará una estructura de paquete al procesar paquetes de datos de la aplicación. Según el mecanismo de tiempo de espera, los mecanismos de confirmación síncrona y asíncrona y el proceso de verificación de certificación correspondiente, el paquete de datos se dividirá en dos procesos de ejecución:

1. Normal situation: Éxito dentro del tiempo de espera

2. Timeout situation: timeout failure

Flujo de transmisión de paquetes de aplicación IBC

Cuando se agota el tiempo de espera, significa que la transmisión falló y el protocolo IBC iniciará un proceso de reembolso. Cabe señalar que IBC tiene un mecanismo de tiempo de espera configurable por el usuario. La vulnerabilidad de Dragonberry se origina en ICS-23 (IBC). La causa principal de esta vulnerabilidad es que los usuarios pueden falsificar pruebas de inexistencia en el proceso de verificación (es decir, pruebas falsas de que no se han recibido paquetes de datos), eludiendo así las comprobaciones de seguridad y falsificando Una situación de tiempo de espera IBC "razonable" se utiliza para engañar al protocolo IBC, lo que hace que el repetidor envíe paquetes de tiempo de espera con certificados falsos, y puede convertirse en un problema de doble gasto de la CIE-20. El proceso de activación específico de la vulnerabilidad se puede ver en la siguiente figura.

Diagrama de flujo del principio de vulnerabilidad de Dragonberry

Dirección del proyecto: https://github.com/cosmos/ibc-go/tree/00a680cda52690a4ba835bf37f53acc41c01bc7a/modules/core/04-channel

Ubicación de la vulnerabilidad: https://github.com/cosmos/ibc-go/blob/00a680cda52690a4ba835bf37f53acc41c01bc7a/modules/core/04-channel/keeper/timeout.go#L117C28-L117C54

Fragmento de código vulnerable:

• Caso 2: Aviso de seguridad de IBC Huckleberry, vulnerabilidad del proceso de transmisión

Antecedentes de vulnerabilidad: UnreceivedPackets solo construye una respuesta encontrando el recibo del paquete correspondiente para cada número de secuencia incluido en la consulta. Esto solo funciona para canales desordenados, ya que los canales ordenados utilizan nextSequenceRecv en lugar de los recibos de paquetes. Por lo tanto, en un canal ordenado, consultar el número de secuencia a través de GetPacketReceipt no encontrará el recibo dentro de él.

La gravedad de este problema es menor porque el canal transmitido por el ICS-20 FT está en su mayoría desordenado y el repetidor no depende de este punto final grpc para determinar qué paquetes activan el tiempo de espera. Sin embargo, si hay un gran número de paquetes en la cadena de destino, y el canal ordenado está configurado para la transmisión IBC, y la respuesta grpc no está paginada, esto creará un riesgo de degradación del rendimiento del nodo de servicio o incluso de un bloqueo. El proceso específico de activación se puede ver en la figura a continuación.

Principio de vulnerabilidad de Huckleberry diagrama de flujo

Dirección del proyecto: https://github.com/cosmos/ibc-go/blob/11297aaa61e651c16e6d4147a15be24ce55ba7cc/modules/core/04-channel/

Ubicación de vulnerabilidad: https://github.com/cosmos/ibc-go/blob/11297aaa61e651c16e6d4147a15be24ce55ba7cc/modules/core/04-channel/keeper/grpc_query.go#L408

Fragmento de código vulnerable:

Aplicación y extensión del protocolo IBC

• Caso 1: vulnerabilidad de entrega aérea de zancada, vulnerabilidad lógica

Antecedentes de vulnerabilidad: La función IntentarActualizarReclamoDeAirdropconvierte la dirección del remitente de un paquete IBC en una dirección Stride llamadadireccióndeStride del remitente, y extrae airdropId y la nueva dirección de lanzamiento aéreo nuevaDirecciónStridedesde los metadatos del paquete. Luego llama ActualizarDirecciónAirdrop Para actualizar el archivo senderStrideAddress y ReclamarRegistro. Con la actualización de la Registro de reclamación, nuevaDireccionStridepodrá reclamar el airdrop. Sin embargo, esta función de actualización solo verifica si la dirección del remitente de la solicitud está vacía y no validanewStrideAddress. Dado que IBC permite conexiones de máquinas individuales para implementar cadenas habilitadas para IBC, esto presenta un riesgo de seguridad donde es posible actualizar la dirección de cualquier otra cuenta como la dirección de la entrega aérea.

Dirección del proyecto: https://github.com/Stride-Labs/stride/tree/3a5c7bfcc3b8c5e7dd870f01bebeb9d949492203/x/autopilot

Ubicación de la vulnerabilidad: 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

Fragmento de código vulnerable:

• Caso 2: vulnerabilidad del módulo IBC de neutron, vulnerabilidad de consumo de gas

Antecedentes de vulnerabilidad: En el contexto de contratos inteligentes, hay un problema con la forma en que se verifican las tarifas para confirmar o agotar los eventos de IBC (Comunicación Inter-Blockchain). Esta falla permite que los contratos inteligentes maliciosos desencadenen un 'ErrorOutOfGas'. Esta falla ocurre durante el procesamiento de los mensajes 'OnAcknowledgementPacket' y 'OnTimeoutPacket'. Cuando ocurre este error, no es posible resolverlo a través del método 'outOfGasRecovery' habitual. Como resultado, las transacciones afectadas no se incluyen en el bloque de la cadena de bloques. Esta falla puede hacer que los relayers de IBC intenten repetidamente enviar estos mensajes. Tales envíos repetidos podrían provocar pérdidas financieras para los relayers y sobrecargar la red con un número excesivo de paquetes no procesados ('abandonados'), lo que representa un riesgo para la estabilidad de la red.

Dirección del proyecto: https://github.com/neutron-org/neutron/blob/64868908b21f648ad5e8a9b48179134619544e2a/

Ubicación de la vulnerabilidad:

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

Fragmento de código vulnerable:

Resumen

El análisis y la discusión de los problemas de seguridad relacionados con el protocolo de Comunicación Inter-Blockchain (IBC), tal como se presenta en el texto anterior, resaltan la naturaleza generalizada y variada de estas preocupaciones. Los desafíos principales parecen originarse predominantemente en la fase de implementación y en la expansión de aplicaciones que utilizan el protocolo IBC. A medida que diversas cadenas de aplicaciones mejoran y perfeccionan progresivamente sus funcionalidades de módulos tradicionales, incorporan simultáneamente diversas implementaciones de código en sus módulos IBC. Esto se hace para mejorar el rendimiento y satisfacer requisitos comerciales específicos.

Además de los problemas de seguridad mencionados anteriormente en el componente IBC, están surgiendo nuevos desafíos, especialmente en el middleware de IBC. Se espera que estas preocupaciones en evolución se vuelvan cada vez más significativas en el futuro, especialmente en lo que respecta a la seguridad general del ecosistema de Cosmos. Esta transición indica un creciente énfasis en garantizar medidas de seguridad sólidas en el módulo IBC.

Conclusión

Nuestra investigación sobre la seguridad del ecosistema de Cosmos, que incluye auditorías detalladas, resúmenes y categorizaciones, se ha centrado en sus dos componentes más críticos: el Cosmos SDK y el protocolo IBC. Basándonos en nuestra amplia experiencia práctica, hemos compilado una colección completa de conocimientos generales de auditoría.

Este informe subraya los desafíos únicos planteados por una red heterogénea como Cosmos, especialmente dada su compatibilidad con interacciones entre cadenas. La complejidad y la naturaleza dispersa de sus componentes hacen que la tarea de garantizar su seguridad sea formidable. No solo implica aplicar nuestro conocimiento existente sobre riesgos de seguridad, sino también adaptarse a nuevos escenarios de seguridad para abordar problemas emergentes.

A pesar de estos obstáculos, somos optimistas. Al documentar y analizar escenarios comunes y desafíos de seguridad, como hemos hecho en este informe, estamos allanando el camino para mejorar progresivamente el marco de seguridad general dentro del diverso ecosistema de Cosmos.

Descargo de responsabilidad：

1. Este artículo es reimpreso de [CertiK]. Todos los derechos de autor pertenecen al autor original [CertiK]. Si hay objeciones a esta reimpresión, por favor contacta al Gate Learnequipo, y lo resolverán rápidamente.
2. Responsabilidad de responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.