¿Qué es un exploit de puente cross-chain y cómo surgen estos ataques?

¿Qué es un exploit de puente cross-chain?

Un exploit de cross-chain bridge es el aprovechamiento indebido de una vulnerabilidad en un bridge: una infraestructura que permite que distintas blockchains se comuniquen entre sí. A través de esa vulnerabilidad, un atacante puede, por ejemplo, liberar tokens sin un depósito válido, acuñar tokens sin suficiente colateral o retirar reservas del bridge.

Un bridge cross-chain permite mover tokens, mensajes u otros datos entre blockchains separadas. Esto es necesario porque una blockchain no puede comprobar automáticamente lo que ha ocurrido en otra blockchain.

Un exploit puede surgir en distintos puntos. Piense en un error en la verificación de mensajes, permisos de acceso demasiado amplios, una vulnerabilidad en smart contracts o claves privadas robadas de validadores o administradores. En algunos bridges, por ejemplo, los validadores confirman que un mensaje de una blockchain es auténtico y válido antes de que ocurra algo en la otra blockchain.

Es importante saber lo siguiente: un bridge añade una capa de seguridad adicional sobre las blockchains con las que se conecta. En algunos bridges, por ejemplo, usted confía en un grupo externo de validadores o en un multisig. Otros bridges utilizan light clients y pruebas criptográficas, como las pruebas de Merkle, para comprobar que una transacción o un evento realmente ha tenido lugar en la otra blockchain. Por tanto, el modelo de seguridad y, con ello, los riesgos pueden variar mucho de un bridge a otro.

Por cierto, una página de phishing durante el proceso de bridge no es automáticamente un exploit del bridge. Esa página puede llevarle a un contrato malicioso o hacer que firme una autorización no deseada, pero eso no significa necesariamente que el bridge subyacente haya sido comprometido.

Puntos clave

• Un cross-chain bridge permite la comunicación y la transferencia de valor entre blockchains separadas.
• Un bridge exploit aprovecha una vulnerabilidad técnica u operativa en ese bridge.
• Los atacantes pueden, entre otras cosas, provocar pagos no autorizados o acuñar tokens sin suficiente colateral.
• La verificación de mensajes cross-chain es un punto de seguridad clave de un bridge.
• El modelo de seguridad varía según el bridge y determina qué riesgos adicionales asumen los usuarios.

¿Cómo funciona un cross-chain bridge?

Un cross-chain bridge observa un evento en la blockchain de origen y, una vez verificado ese evento, ejecuta una acción correspondiente en la blockchain de destino.

Suponga que desea enviar un token de la blockchain A a la blockchain B. La blockchain B no puede comprobar automáticamente si usted realmente envió ese token en la blockchain A. Por eso, el bridge debe observar y verificar el evento en la blockchain A antes de que ocurra algo en la blockchain B.

Un modelo muy utilizado se llama lock-and-mint. En él, sus tokens originales se bloquean en la blockchain de origen. En la blockchain de destino se acuña entonces un wrapped token: una representación del token original. Si vuelve atrás, el wrapped token se quema y los tokens originales pueden liberarse de nuevo.

Ejemplo: Usted bloquea 1 token en la blockchain A. Tras la verificación, recibe 1 wrapped token en la blockchain B. Por tanto, su token original no viaja literalmente a la blockchain B, sino que permanece bloqueado como colateral del token que recibe allí.

Otro enfoque funciona con pools de liquidez. Después de una transacción verificada en la blockchain de origen, un pool en la blockchain de destino puede pagar una cantidad equivalente de tokens.

El paso crucial es siempre la verificación. El bridge debe, por ejemplo, comprobar si un mensaje es auténtico, si procede de la blockchain correcta, si cumple las condiciones adecuadas y si no se ha procesado antes. La forma en que esto se hace varía según el bridge.

Algunos bridges también admiten generalised message passing. En ese caso, no solo pueden mover tokens, sino también transmitir y ejecutar otros datos o instrucciones entre blockchains. Esto ofrece más posibilidades, pero también puede ampliar la superficie de ataque.

¿Qué distintos modelos de seguridad utilizan los bridges?

No todos los bridges determinan de la misma manera si un mensaje es válido. Por ello, el modelo de seguridad también puede variar mucho.

Un bridge puede, por ejemplo, confiar en:

• Validadores externos o multisigs: un grupo de partes firma los mensajes antes de que se ejecuten en otra blockchain.
• Light clients: una blockchain verifica información criptográfica sobre el estado de la otra blockchain.
• Pruebas criptográficas: un bridge utiliza, por ejemplo, pruebas de Merkle u otras construcciones criptográficas para demostrar eventos.
• Verificación optimista: los mensajes se aceptan primero, pero existe un periodo durante el cual otras partes pueden impugnar un mensaje inválido.

Estos modelos implican distintas compensaciones. Un grupo externo de validadores puede ser más sencillo, pero añade una capa adicional de confianza. Un bridge que verifica eventos criptográficamente presenta otros riesgos técnicos. Por eso, la palabra "bridge" por sí sola dice poco sobre cuán seguro es exactamente el sistema.

¿Cómo puede ser atacado un cross-chain bridge?

Un atacante suele intentar eludir la verificación del bridge o conseguir la autoridad para aprobar como válido un mensaje cross-chain inválido.

La idea detrás de esto es sencilla: si la blockchain de destino cree erróneamente que en la blockchain de origen se han depositado o bloqueado tokens, el bridge puede, por ejemplo, acuñar nuevos tokens o liberar reservas sin que exista suficiente colateral.

Esto puede ocurrir de varias maneras:

• Un error hace que un mensaje no probado o falsificado sea aceptado de todos modos.
• Un atacante obtiene suficientes claves privadas de validadores, firmantes de multisig o administradores.
• Un fallo en un smart contract omite una comprobación importante o concede demasiados permisos a una cuenta.
• La verificación de una prueba criptográfica, como una prueba de Merkle o una prueba de light client, contiene un error.
• Una configuración incorrecta o una actualización hace que mensajes inválidos se traten igualmente como válidos.

Una prueba de Merkle es una forma criptográfica compacta de demostrar que ciertos datos forman parte de un conjunto de datos mayor, por ejemplo, de los datos de un bloque. Si un bridge verifica mal esa prueba, un atacante podría hacer que se acepte un evento que nunca tuvo lugar de forma válida.

Por tanto, no todos los ataques pasan por claves robadas ni todos los bridges funcionan igual. Para comprender el riesgo, debe observar el modelo específico de verificación y seguridad del bridge.

¿Qué vulnerabilidades son frecuentes?

Muchos ataques a bridges se encuadran, en términos generales, en varias categorías: errores en los permisos de acceso, errores en la lógica, problemas de verificación de mensajes y problemas de seguridad operativa.

Los permission issues se refieren a quién puede realizar qué acciones. Tal vez una cuenta de administrador tenga demasiados permisos, las cuentas de validadores estén insuficientemente protegidas o los privilegios puedan modificarse de forma incorrecta. Especialmente en un conjunto pequeño de validadores o multisig, esto puede suponer un gran riesgo. Si suficientes firmantes colaboran o son comprometidos, pueden autorizar pagos inválidos.

Los logic issues son errores en las reglas de los smart contracts. Por ejemplo, un contrato procesa un mensaje sin comprobar todas las condiciones o la acuñación y la liberación están mal configuradas. También pueden incluirse aquí errores durante una actualización o en la inicialización de un contrato.

Los message verification issues surgen cuando un bridge no comprueba suficientemente si un mensaje cross-chain es realmente válido. Por ejemplo, un bridge puede aceptar la fuente equivocada, verificar mal una prueba criptográfica o ejecutar un mensaje que nunca se originó de forma válida en la blockchain de origen.

Los key management issues surgen cuando las claves privadas de validadores, administradores o firmantes de multisig son robadas o no están suficientemente protegidas. Los smart contracts pueden funcionar correctamente desde el punto de vista técnico, mientras que un atacante aun así puede producir firmas válidas con claves robadas.

Los replay attacks también son un riesgo conocido. En ellos, se reutiliza un mensaje que ya era válido. Por eso, un bridge debe comprobar que cada mensaje solo pueda procesarse una vez. Un ID de mensaje único, una nonce o un hash pueden ayudar en este sentido.

Una auditoría puede ayudar a encontrar vulnerabilidades, pero no garantiza que un bridge esté libre de errores. Especialmente después de actualizaciones, cambios de configuración o modificaciones en la infraestructura off-chain, pueden surgir nuevos riesgos.

¿Qué papel desempeñan las interfaces y el phishing?

No toda pérdida durante el uso de un bridge significa que el bridge en sí haya sido explotado. Los atacantes también pueden intentar engañar a los usuarios mediante un sitio web o una interfaz falsos.

Una interfaz falsa puede, por ejemplo, hacer que usted envíe una transacción a un smart contract incorrecto o que conceda permiso para usar tokens de su wallet. La infraestructura técnica del bridge puede permanecer completamente intacta.

La distinción es importante: en un bridge exploit se aprovecha un punto débil del bridge o de la infraestructura que lo rodea. En el phishing, por lo general, se engaña al usuario para que apruebe por sí mismo una acción perjudicial.

¿Cómo pueden influir las claves privadas y los smart contracts?

Las claves privadas y los smart contracts son componentes importantes de muchos bridges. Un problema en cualquiera de los dos puede tener consecuencias graves.

Una clave privada es una clave secreta con la que se pueden crear transacciones o firmas criptográficas. Si un bridge, por ejemplo, solo ejecuta un pago después de que varios validadores hayan firmado, surge un gran riesgo cuando un atacante consigue hacerse con suficientes de esas claves. Entonces, el atacante puede hacer que se aprueben instrucciones fraudulentas del bridge como si fueran legítimas.

Un multisig requiere que varias partes firmen antes de que una acción continúe. Esto puede ser más seguro que una sola cuenta de administrador, pero no es automáticamente seguro. El umbral debe elegirse correctamente, los firmantes deben ser suficientemente independientes y las claves privadas deben protegerse bien.

En el ataque al Ronin Bridge, en marzo de 2022 se comprometieron suficientes claves de validadores para aprobar retiradas no autorizadas. Finalmente, se retiraron del bridge 173.600 ETH y 25,5 millones de USDC. Después, el diseño del bridge se modificó y se añadieron medidas de seguridad adicionales.

En el incidente del Harmony Horizon Bridge, en junio de 2022 se comprometieron al menos dos de las cuatro claves privadas de los validadores del bridge. Harmony informó de que no había pruebas de que los smart contracts del bridge o el propio protocolo blockchain hubieran sido afectados. El incidente muestra que un bridge puede ser comprometido sin que necesariamente exista un fallo en el contrato on-chain.

Mientras tanto, los smart contracts constituyen las reglas on-chain de muchos bridges. Por ejemplo, verifican firmas o pruebas criptográficas y luego ejecutan acciones como acuñar, quemar, bloquear o liberar tokens. Si esas comprobaciones están mal diseñadas o implementadas, un atacante a veces puede crear tokens o retirar reservas sin una transacción subyacente válida.

Por ello, una buena protección requiere tanto smart contracts seguros como una sólida gestión de claves.

¿Cuáles son las consecuencias de un exploit de cross-chain bridge?

Un exploit de cross-chain bridge puede hacer que desaparezcan reservas, que los pools de liquidez se vacíen o que los wrapped tokens dejen de estar completamente respaldados.

Esto último puede tener consecuencias importantes. En un bridge lock-and-mint, un wrapped token normalmente debe estar respaldado por reservas en otra blockchain. Si ese colateral desaparece, la posibilidad de canjear el wrapped token por el activo original puede verse comprometida. Esto también puede afectar a protocolos en los que el token se utiliza como colateral, activo de negociación o liquidez.

Los equipos de proyecto a veces pueden pausar temporalmente un bridge para limitar daños adicionales. Tras el exploit de Nomad en agosto de 2022, por ejemplo, se detuvo el procesamiento posterior después de que un error en la inicialización permitiera tratar mensajes inválidos como válidos. En el incidente se retiraron del bridge activos por un valor aproximado de 190 millones de dólares.

En el exploit de BSC Token Hub en octubre de 2022, se utilizó una prueba criptográfica falsificada que permitió crear aproximadamente 2 millones de BNB adicionales. BNB Chain coordinó con los validadores para detener temporalmente la blockchain y limitar daños adicionales. Como resultado, gran parte de los BNB implicados permaneció bajo control.

Por lo general, las transacciones en blockchain no pueden revertirse simplemente por una parte central, como sí ocurre, por ejemplo, con una transferencia bancaria tradicional. Sin embargo, eso no significa que nunca pueda intervenirse. Según la red, los validadores, los equipos de proyecto, los emisores de tokens o la gobernanza pueden, en ocasiones, tomar medidas para detener transacciones adicionales, bloquear activos u otras acciones de recuperación.

Una pausa temporal puede limitar daños adicionales, pero también tiene inconvenientes. Es posible que los usuarios no puedan usar el bridge o recuperar sus tokens temporalmente. Además, una parada de emergencia implica que determinados administradores, validadores o guardians tienen influencia para ralentizar o detener partes del sistema.

No está garantizado que los usuarios reciban compensación después de un exploit. Esto depende, entre otras cosas, de las reservas disponibles, los seguros, las decisiones del proyecto, la gobernanza y de si los fondos robados pueden recuperarse.

Un gran exploit de bridge también puede dañar la confianza en un proyecto o en un activo bridged. Esto puede afectar a la liquidez y posiblemente también al precio de mercado, aunque el efecto varía según el incidente y las condiciones del mercado.

Además de la pérdida financiera directa, un bridge puede volverse menos útil durante mucho tiempo. La liquidez puede disminuir, los wrapped tokens pueden ser más difíciles de canjear y los usuarios pueden mostrarse más reacios a volver a utilizar el bridge.

¿Qué exploits conocidos de cross-chain bridge existen?

Ha habido varios exploits importantes de bridges. La causa técnica varió según el incidente.

• Poly Network: en agosto de 2021, se movieron más de 600 millones de dólares en cripto en Poly Network tras aprovechar la infraestructura cross-chain. Posteriormente, gran parte de los fondos fue devuelta.
• Wormhole: en febrero de 2022, se aprovechó una vulnerabilidad en Wormhole en Solana para crear wrapped ETH sin el respaldo subyacente requerido. Después, el atacante trasladó parte de los activos a Ethereum.
• Ronin Bridge: en marzo de 2022 se comprometieron claves de validadores, lo que permitió al atacante aprobar retiradas no autorizadas. En total, se retiraron del bridge 173.600 ETH y 25,5 millones de USDC.
• Harmony Horizon Bridge: en junio de 2022 se comprometieron al menos dos claves privadas de validadores del bridge. En el incidente se sustrajeron aproximadamente 100 millones de dólares en cripto.
• Nomad: en agosto de 2022, un error relacionado con la inicialización del contrato Replica hizo que mensajes no probados pudieran tratarse como válidos. Como resultado, varias direcciones pudieron copiar transacciones y retirar activos del bridge. La pérdida total fue de aproximadamente 190 millones de dólares.
• BNB Chain Token Hub: en octubre de 2022, se vio afectado el bridge nativo entre BNB Beacon Chain y BNB Smart Chain. Al falsificar una prueba de bajo nivel, se pudieron crear aproximadamente 2 millones de BNB adicionales.

Las cantidades en este tipo de incidentes deben interpretarse con contexto. Una cifra mencionada puede referirse al valor de mercado de tokens acuñados, a reservas realmente retiradas, a activos bloqueados temporalmente o a importes que posteriormente se recuperaron. Como los precios de las criptomonedas fluctúan, el valor en dólares informado también puede variar según el momento de la medición.

¿Cómo pueden prevenirse los exploits de cross-chain bridge?

Los exploits de cross-chain bridge no pueden prevenirse por completo, pero varias capas de seguridad independientes pueden reducir la probabilidad de un ataque exitoso y limitar el daño máximo.

La base es una verificación estricta. Un bridge debe comprobar, entre otras cosas, de dónde procede un mensaje, si es válido, para qué acción está destinado y si no se ha utilizado antes. Solo entonces un contrato puede, por ejemplo, acuñar tokens o liberar reservas.

El modelo de confianza también importa. Un bridge que depende de un pequeño conjunto externo de validadores o de un multisig tiene un perfil de riesgo distinto al de un bridge que verifica información cross-chain mediante, por ejemplo, light clients. Ningún diseño está completamente libre de riesgo.

Además, pueden ayudar medidas para limitar el daño máximo:

• Rate limits limitan cuánta cantidad de valor puede moverse en un periodo determinado.
• Límites de retirada establecen un máximo para los pagos.
• Circuit breakers pueden frenar o detener automáticamente una actividad anómala.
• Funciones de pausa pueden detener temporalmente determinadas actividades del bridge durante un incidente.
• Monitoring puede detectar antes mensajes de bridge inusualmente grandes o extraños.

Ese freno de emergencia no resuelve la vulnerabilidad subyacente. Pero sí puede evitar que un atacante retire todas las reservas disponibles en poco tiempo.

Las auditorías, los bug bounties, las revisiones de código y las pruebas exhaustivas también son importantes. Funcionan mejor junto con una supervisión continua, una gestión segura de claves y un plan de respuesta a incidentes preparado de antemano.

¿Qué medidas de seguridad pueden tomar los desarrolladores?

Los desarrolladores pueden reducir el riesgo configurando de forma estricta la verificación, los permisos de acceso, la gestión de claves y las medidas de emergencia desde el principio.

1. Compruebe cada mensaje por completo. Verifique, entre otras cosas, la blockchain de origen, el remitente, la nonce o ID de mensaje único, el destino y la función permitida. Así se evita que un mensaje proceda de la fuente equivocada o se reutilice para otra acción.

2. Incorpore protección contra replay. Marque un mensaje procesado como usado y no lo acepte de nuevo. Esto ayuda frente a los replay attacks, en los que la misma instrucción se ejecuta varias veces.

3. Conceda los mínimos permisos posibles. Aplique el principio de least privilege. No todas las cuentas necesitan poder actualizar contratos, modificar validadores, acuñar tokens o activar una parada de emergencia. Cuantos menos privilegios tenga una cuenta, menor será el daño potencial si se compromete.

4. Proteja las cuentas de administración con un multisig. Para acciones de administración sensibles, utilice cuando sea apropiado varios firmantes independientes en lugar de una sola externally owned account con una única clave privada. Un multisig solo es útil si los firmantes y sus claves son realmente suficientemente independientes.

5. Utilice un timelock para cambios de alto riesgo. Un timelock introduce un tiempo de espera antes de ejecutar una actualización o una decisión de gobernanza. Así, los cambios pueden revisarse con antelación y la actividad sospechosa puede detectarse antes.

6. Pruebe algo más que la ruta normal. Encargue auditorías independientes, pero pruebe también actualizaciones, inicialización, entradas erróneas, casos límite y verificación de pruebas. El exploit de Nomad muestra lo grave que puede ser un error en una actualización o en la inicialización.

7. Prepare de antemano la respuesta a incidentes. Utilice monitoring, detección de anomalías, rate limits y, cuando proceda, una parada de emergencia controlada. Defina de antemano quién puede intervenir, qué acciones son posibles y cómo se comunicará durante un incidente.

8. Gestione las claves privadas con cuidado. Mantenga separadas y bien protegidas las claves de validadores y administradores. Además, establezca procedimientos para añadir, eliminar y sustituir firmantes de forma controlada.

Una auditoría o un bug bounty no constituyen un sello de seguridad. Las nuevas actualizaciones, los relayers off-chain, los cambios de configuración y la seguridad diaria de las claves privadas siguen siendo riesgos independientes.

¿Cómo pueden limitar los usuarios los riesgos?

Como usuario, usted no puede decidir la seguridad de un bridge, pero sí puede limitar cuánto riesgo asume a través de él.

1. Observe el modelo de confianza. Compruebe qué bridge utiliza y cómo se verifican los mensajes cross-chain. Por ejemplo, vea si se utiliza un grupo externo de validadores, un multisig, un light client u otro modelo de verificación.

2. Utilice la interfaz correcta. Acceda al bridge a través de un canal de proyecto fiable y verificado. Antes de firmar una transacción, compruebe, entre otras cosas, la URL, la blockchain, la dirección de recepción y el token que envía.

3. No firme a ciegas. Compruebe qué hace una transacción o un mensaje antes de firmarlo. La firma ciega puede exponerle a phishing, a un contrato malicioso o a permisos no deseados.

4. Limite las aprobaciones de tokens. Siempre que sea posible, conceda permiso solo por el importe necesario. Una aprobación de tokens puede permanecer activa on-chain hasta que se modifique o se revoque.

5. Revise las aprobaciones que no utilice. Compruebe los límites de gasto antiguos y revóquelos si ya no los necesita. Desconectar solo su crypto wallet de una dApp no elimina las aprobaciones de tokens existentes.

6. Limite su exposición. Una pequeña transacción de prueba puede ayudar a comprobar, por ejemplo, la dirección, la interfaz y la ruta elegida. Sin embargo, esa prueba no demuestra que el bridge sea seguro.

7. Tenga en cuenta el riesgo de los tokens bridged. Después de un exploit, los wrapped tokens pueden ser temporalmente difíciles de canjear o tener menos liquidez. Cuanto más tiempo y más valor dependa de un único bridge a través de las reservas subyacentes, mayor será la exposición a ese riesgo específico del bridge.

Además, compruebe los avisos oficiales de incidentes y las advertencias de seguridad actuales antes de utilizar un bridge.

Conclusión

Un cross-chain bridge permite intercambiar tokens, mensajes y otros datos entre blockchains, pero al hacerlo también añade una capa de seguridad adicional. Las vulnerabilidades pueden surgir, entre otras cosas, en la verificación de mensajes cross-chain, los permisos de acceso, las claves privadas, la configuración y los smart contracts.

Las consecuencias pueden ser graves, porque los bridges suelen gestionar cantidades considerables de cripto o son responsables del respaldo de los wrapped tokens. Los incidentes en Poly Network, Wormhole, Ronin, Harmony, Nomad y BNB Chain, entre otros, muestran además que los exploits de bridges pueden surgir de formas muy distintas.

Para los desarrolladores, una buena seguridad consiste por tanto en varias capas independientes: verificación estricta, protección contra replay, administración limitada, gestión segura de claves, monitoring y un plan de respuesta a incidentes preparado. Para los usuarios, lo más importante es entender qué modelo de confianza utiliza un bridge, comprobar la interfaz correcta y tener en cuenta los riesgos adicionales de los activos bridged.

Los bridges desempeñan un papel importante en un ecosistema con múltiples blockchains, pero no están exentos de riesgo. Cuanto mejor entienda cómo un bridge comprueba los eventos en otra blockchain y de qué partes o sistemas depende esa verificación, mejor podrá evaluar su modelo de seguridad.