¿Cuáles son las vulnerabilidades más comunes de la seguridad de los puentes?
Inicio
Artículos
¿Cuáles son las vulnerabilidades más comunes de la seguridad de los puentes?

¿Cuáles son las vulnerabilidades más comunes de la seguridad de los puentes?

Avanzado
Publicación: Mar 22, 2023Actualización: Jun 15, 2023
9m

Este artículo es una contribución de la comunidad. El autor es Minzhi He, auditor de CertiK.

Las opiniones en este artículo pertenecen al colaborador/autor y no reflejan necesariamente las perspectivas de Binance Academy.

Resumen

Los puentes de blockchain son fundamentales para lograr la interoperabilidad dentro del espacio blockchain. Por lo tanto, su seguridad es de suma importancia. Algunas de las vulnerabilidades más comunes de la seguridad de los puentes incluyen una validación débil en la cadena y fuera de la cadena, el manejo inadecuado de los tokens nativos y las configuraciones erróneas. Se recomienda poner a prueba el puente frente a todos los vectores de ataque posibles para garantizar una lógica de verificación sólida.

Introducción

Un puente de blockchain es un protocolo que conecta dos blockchains para permitir las interacciones entre ellas. Si tienes Bitcoin, pero quieres participar en una actividad DeFi en la red Ethereum, un puente de blockchain te permite hacerlo sin tener que vender tu Bitcoin. 

Los puentes de blockchain son fundamentales para lograr la interoperabilidad dentro del espacio blockchain. Funcionan mediante variadas validaciones en la cadena y fuera de la cadena, por lo que presentan diferentes vulnerabilidades de seguridad.

¿Por qué es fundamental la seguridad de los puentes? 

Por lo general, un puente mantendrá el token que un usuario quiere transferir de una cadena a otra. Los puentes, que a menudo se implementan como contratos inteligentes, mantienen una cantidad significativa de tokens a medida que las transferencias cross-chain se acumulan, lo que los convierte en objetivos lucrativos para los hackers. 

Además, los puentes de blockchain tiene una gran superficie de ataque porque incluyen varios componentes. Con eso en mente, los actores malintencionados consideran las aplicaciones cross-chain como objetivos muy buenos para robar grandes cantidades de fondos. 

En 2022, los ataques a puentes generaron pérdidas por más de 1.3 mil millones USD, lo que representa el 36% de las pérdidas totales del año, según estimaciones realizadas por CertiK. 

Vulnerabilidades comunes de la seguridad de los puentes

Para mejorar la seguridad de los puentes, es valioso comprender sus vulnerabilidades más comunes y ponerlos a prueba antes de su lanzamiento. Estas vulnerabilidades se pueden clasificar en las siguientes cuatro áreas. 

Validación débil en la cadena

En el caso de puentes simples, especialmente los que se diseñaron para DApps específicas, la validación en la cadena se mantiene al mínimo. Estos puentes dependen de un backend centralizado para ejecutar operaciones básicas como la acuñación, la quema y la transferencia de tokens, mientras que todas las verificaciones se realizan fuera de la cadena.

Por el contrario, otros tipos de puentes utilizan contratos inteligentes para validar mensajes y realizar verificaciones en la cadena. En estos casos, cuando un usuario deposita en la cadena, el contrato inteligente genera un mensaje firmado y devuelve la firma en la transacción. La firma sirve como prueba del depósito y se usa para verificar la solicitud de retiro del usuario en la otra cadena. Este proceso debe poder prevenir varios tipos de ataques a la seguridad, incluidos los ataques de repetición y la falsificación de registros de depósito. 

Sin embargo, si existe una vulnerabilidad en el proceso de validación en la cadena, el atacante puede causar un gran daño. Por ejemplo, si un puente usa el árbol de Merkle para validar el registro de transacciones, un atacante puede generar comprobantes falsificados. Esto significa que, si el proceso de validación es vulnerable, el atacante puede eludir la validación de comprobantes y acuñar nuevos tokens para su cuenta.

Algunos puentes implementan el concepto de "wrapped tokens". Por ejemplo, cuando un usuario transfiere DAI de Ethereum a BNB Chain, se toma el DAI del contrato de Ethereum y una cantidad equivalente de wrapped DAI se emite en BNB Chain. 

Sin embargo, si la transacción no se valida correctamente, un atacante puede implementar un contrato malicioso para dirigir los wrapped tokens desde el puente hasta una dirección incorrecta. 

Los atacantes también necesitan víctimas que aprueben el contrato del puente para poder transferir tokens mediante la función "transferFrom" y así drenar activos del contrato del puente. 

Lamentablemente, esto empeora porque muchos puentes solicitan la aprobación infinita de tokens a los usuarios de DApps. Esta es una práctica común que baja las comisiones de gas, pero crea riesgos adicionales al permitir que un contrato inteligente acceda a una cantidad ilimitada de tokens de la billetera del usuario. Los atacantes pueden explotar la falta de validación y la aprobación excesiva para transferir tokens de otros usuarios a ellos mismos.

Validación débil fuera de la cadena

En algunos sistemas de puentes, el servidor backend fuera de la cadena juega un papel fundamental en la verificación de la legitimidad de los mensajes enviados desde la blockchain. Esta vez nos enfocaremos en la verificación de transacciones de depósito. 

Un puente de blockchain con validación fuera de la cadena funciona de la siguiente manera: 

  1. Los usuarios interactúan con la DApp para depositar tokens en el contrato inteligente de la cadena fuente.

  2. La DApp luego envía el hash de la transacción de depósito al servidor backend a través de una API.

  3. El hash de la transacción pasa por varias validaciones por parte del servidor. Si se lo considera legítimo, un firmante firma el mensaje y envía la firma de regreso a la interfaz de usuario a través de la API.

  4. Al recibir la firma, la DApp la verifica y autoriza al usuario a retirar los tokens de la cadena objetivo.

El servidor backend debe asegurarse de que la transacción de depósito que procesa haya ocurrido realmente y no sea una falsificación. Este servidor backend determina si el usuario puede retirar los tokens en la cadena objetivo y, por lo tanto, es un objetivo de ataque muy buscado por los ciberdelincuentes.

El servidor backend debe validar la estructura del evento emitido de la transacción, así como la dirección de contrato que emitió el evento. Si se descuida lo último, un atacante podría desplegar un contrato malicioso para falsificar un evento de depósito con la misma estructura que el evento de depósito legítimo. 

Si el servidor backend no verifica qué dirección emitió el evento, podría considerarlo una transacción válida y firmar el mensaje. El atacante podría entonces enviar el hash de transacción al backend, eludiendo la verificación y logrando retirar los tokens de la cadena objetivo.

Manejo inadecuado de los tokens nativos

Los puentes asumen diferentes enfoques para el manejo de los tokens nativos y los tokens de utilidad. Por ejemplo, en la red Ethereum, el token nativo es ETH y la mayoría de los tokens de utilidad se adhieren al estándar ERC-20. 

Si un usuario intenta transferir su ETH a otra cadena, primero debe depositarlo en el contrato del puente. Para lograrlo, el usuario simplemente adjunta el ETH a la transacción, y la cantidad de ETH se puede recuperar leyendo el campo "msg.value" de la transacción.

El depósito de tokens ERC-20 es muy diferente del depósito de ETH. Para depositar un token ERC-20, el usuario primero debe permitir que el contrato del puente gaste sus tokens. Después de la aprobación y de que se hayan depositado los tokens en el contrato del puente, el contrato quemará los tokens del usuario mediante la función "burnFrom()" o transferirá el token del usuario al contrato con la función "transferFrom()". 

Una manera de diferenciar esto es usar un enunciado condicional dentro de la misma función. Otra manera es crear dos funciones separadas para manejar cada escenario. Intentar el depósito de ETH usando la función de depósito para ERC-20 puede resultar en la pérdida de los fondos.

Al manejar solicitudes de depósito de ERC-20, los usuarios normalmente proporcionan la dirección del token como entrada en la función de depósito. Esto implica un riesgo significativo, ya que pueden darse llamadas externas no confiables durante la transacción. Implementar una lista blanca que solo incluya los tokens admitidos por el puente es una práctica común para minimizar este riesgo. Solo las direcciones incluidas en la lista blanca pueden pasar como argumento. Esto evita las llamadas externas, ya que el equipo del proyecto ya filtró la dirección de token.

Sin embargo, pueden surgir problemas cuando los puentes manejan la transferencia de tokens nativos cross-chain, ya que el token nativo no tiene una dirección. Una dirección cero (0x000...0) representa al token nativo. Esto puede ser problemático, ya que el pasaje de la dirección cero a la función puede eludir la verificación de la lista blanca, incluso si se implementó correctamente. 

Cuando el contrato del puente llama "transferFrom" para transferir los activos del usuario al contrato, la llamada externa a la dirección cero devuelve un falso porque en la dirección cero no hay una función "transferFrom" implementada. Sin embargo, la transacción igual puede ocurrir si el contrato no maneja adecuadamente el valor devuelto. Esto crea una oportunidad para que los atacantes ejecuten la transacción sin transferir ningún token al contrato.

Configuración errónea

En la mayoría de los puentes de blockchain, el responsable de asignar los tokens y direcciones a la lista blanca o negra, asignar o cambiar firmantes y otras configuraciones críticas es un rol privilegiado. Garantizar que todas las configuraciones sean precisas es fundamental, ya que incluso los descuidos aparentemente más triviales pueden provocar pérdidas significativas.

De hecho, hubo un incidente en el que el atacante eludió con éxito la verificación del registro de transferencia debido a una mala configuración. El equipo del proyecto implementó una actualización de protocolo unos días antes del hackeo, y esta actualización implicó cambiar una variable. La variable se usaba para representar el valor predeterminado del mensaje confiable. Este cambio hizo que todos los mensajes se clasificaran automáticamente como probados, lo que permitió que el atacante enviara un mensaje arbitrario y pasara el proceso de verificación.

Cómo mejorar la seguridad de los puentes

Las cuatro vulnerabilidades más comunes de los puentes explicadas hasta aquí demuestran los desafíos existentes para garantizar la seguridad en un ecosistema blockchain interconectado. Existen consideraciones significativas para manejar cada una de estas vulnerabilidades y no hay una solución fácil que funcione para todas. 

Por ejemplo, proporcionar pautas generales para garantizar un proceso de verificación libre de errores es difícil porque cada puente tiene requisitos de verificación únicos. El enfoque más efectivo para evitar que se eluda la verificación es probar exhaustivamente el puente frente a los posibles vectores de ataque y asegurarse de que la lógica de verificación sea sólida. 

En resumen, es esencial realizar pruebas rigurosas contra posibles ataques y prestar especial atención a las vulnerabilidades más comunes de la seguridad de los puentes.  

Conclusiones 

Debido a su alto valor, los puentes cross-chain han sido un blanco de ataque por mucho tiempo. Los desarrolladores pueden fortalecer la seguridad de sus puentes si llevan a cabo pruebas exhaustivas previo a la implementación y participar en auditorías de terceros, lo que reduce el riesgo de que se vuelvan a producir los hackeos devastadores que han asolado a los puentes en los últimos años. Los puentes son fundamentales para el mundo multicadena, pero la seguridad debe ser una prioridad en el diseño y construcción de una infraestructura Web3 efectiva.

Lecturas adicionales

¿Qué es un puente de blockchain?

¿Qué es la interoperabilidad cross-chain?

Tres criptopuentes populares y cómo funcionan

¿Qué son los Wrapped Tokens?

Aviso legal y Advertencia de riesgo: Este contenido se presenta "tal cual" únicamente para fines de información general y educativos, sin declaración ni garantía de ningún tipo. No debe interpretarse como un asesoramiento financiero, legal o de otra índole profesional ni pretende recomendar la compra de ningún producto o servicio específicos. Debes buscar consejo particular de asesores profesionales idóneos. Como este artículo es producto de la contribución de un tercero, ten en cuenta que las opiniones expresadas pertenecen al tercero colaborador y no reflejan necesariamente las de Binance Academy. Para obtener más información, lee nuestro aviso legal completo aquí. Los precios de los activos digitales pueden ser volátiles. El valor de una inversión puede bajar o subir, y podría darse el caso de que no recuperes el monto invertido. Solo tú eres responsable de tus decisiones de inversión. Binance Academy no se responsabiliza de ninguna pérdida en la que puedas incurrir. Este material no se debe interpretar como una asesoría financiera, legal o de otra índole profesional. Si deseas obtener más información, consulta nuestros Términos de uso y la Advertencia de riesgo.