¬Ņ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.