¿Cuáles son las vulnerabilidades comunes de seguridad en los puentes de cadena cruzada?

Resumen

Los puentes de blockchain son la base para lograr la interoperabilidad en el ámbito de las cadenas de bloques. Por lo tanto, la seguridad de las tecnologías de puente entre cadenas es fundamental. Algunas vulnerabilidades comunes en la seguridad de los puentes de blockchain incluyen insuficiente validación en la cadena y fuera de la cadena, manejo inapropiado de tokens nativos y configuraciones incorrectas. Para garantizar que la lógica de validación sea razonable, se recomienda realizar pruebas exhaustivas en todos los posibles vectores de ataque en los puentes entre cadenas.

Introducción

Los puentes de blockchain son protocolos que conectan dos cadenas de bloques, permitiendo la interacción entre ellas. A través de estos puentes, los usuarios que deseen participar en actividades DeFi en la red de Ethereum, por ejemplo, solo necesitan poseer Bitcoin, sin necesidad de venderlo.

Los puentes de blockchain son la base para lograr la interoperabilidad en el ámbito de las cadenas de bloques. Utilizan diversas validaciones en la cadena y fuera de la cadena para funcionar, por lo que también pueden presentar diferentes vulnerabilidades de seguridad.

¿Por qué es crucial la seguridad de los puentes de blockchain?

Los puentes de blockchain suelen mantener tokens que los usuarios desean transferir de una cadena a otra. Generalmente, se despliegan en forma de contratos inteligentes y, a medida que se acumulan transferencias entre cadenas, estos puentes mantienen una gran cantidad de tokens, lo que los convierte en objetivos codiciados por hackers.

Además, debido a la participación de múltiples componentes, la superficie de ataque de los puentes de blockchain suele ser muy grande. Por ello, los actores malintencionados tienen un fuerte incentivo para convertir los puentes en objetivos, con la esperanza de obtener grandes cantidades de fondos.

Según estimaciones de CertiK, en 2022, los ataques a puentes de blockchain causaron pérdidas superiores a 1.300 millones de dólares, representando el 36% del total de pérdidas ese año.

Vulnerabilidades comunes en la seguridad de los puentes entre cadenas

Para fortalecer la seguridad de los puentes de blockchain, es importante entender las vulnerabilidades comunes en la interoperabilidad y realizar pruebas antes de su despliegue. Estas vulnerabilidades provienen principalmente de los siguientes cuatro aspectos:

Insuficiente validación en la cadena

Para puentes de cadena sencilla, especialmente diseñados para aplicaciones descentralizadas específicas (dApps), generalmente solo existe una validación mínima en la cadena. Estos puentes dependen de un backend centralizado para realizar operaciones básicas, como acuñación, quema y transferencia de tokens, con todas las validaciones realizadas fuera de la cadena.

Otros tipos de puentes utilizan contratos inteligentes para validar mensajes y realizar verificaciones en la cadena. En estos casos, cuando un usuario deposita fondos en la cadena, el contrato inteligente genera un mensaje firmado y devuelve la firma en la transacción. Esta firma sirve como prueba de recarga, utilizada para verificar la solicitud de retiro del usuario en otra cadena. Este proceso debe ser capaz de prevenir diversos ataques de seguridad, como ataques de repetición y falsificación de registros de recarga.

Sin embargo, si el proceso de validación en la cadena tiene vulnerabilidades, los ataques pueden causar daños graves. Por ejemplo, si la cadena utiliza un árbol de Merkle para verificar registros de transacciones, un atacante podría generar una prueba falsificada. Esto significa que, si hay fallos en la validación, un atacante podría eludir la verificación y acuñar nuevos tokens en su cuenta.

Algunos puentes implementan el concepto de “tokens envueltos(wrapped tokens)”. Por ejemplo, cuando un usuario transfiere DAI desde Ethereum a BNB Chain, su DAI se retira del contrato en Ethereum y se emite una cantidad equivalente de DAI envuelto en BNB Chain.

Pero si esta transacción no se valida correctamente, un atacante podría desplegar un contrato malicioso y, manipulando esa función, redirigir los tokens envueltos a una dirección incorrecta.

El atacante también necesita que la víctima apruebe previamente el contrato del puente entre cadenas para poder usar la función “TransferFrom” y transferir tokens, logrando así robar activos del contrato puente.

Lo complicado es que muchos puentes entre cadenas requieren que los usuarios de dApp aprueben ilimitadamente los tokens, una práctica común que reduce costos de gas, pero que también permite que los contratos inteligentes accedan sin límite a los fondos del usuario, lo que aumenta el riesgo. Los atacantes pueden aprovechar estas insuficiencias en la validación y en las aprobaciones excesivas para transferir tokens de otros usuarios a su propia cuenta.

Insuficiente validación fuera de la cadena

En algunos sistemas de puentes entre cadenas, el servidor backend fuera de la cadena desempeña un papel crucial en la validación de los mensajes enviados desde la cadena. En estos casos, la validación de las transacciones de recarga es especialmente importante.

El funcionamiento de un puente con validación fuera de la cadena es el siguiente:

El usuario interactúa con la dApp y deposita tokens en un contrato inteligente en la cadena fuente.

Luego, la dApp envía el hash de la transacción de recarga al servidor backend mediante una API.

El hash de la transacción debe ser validado varias veces por el servidor. Si se considera válido, el firmante firma un mensaje y devuelve la firma a la interfaz de usuario mediante la API.

Tras recibir la firma, la dApp la valida y permite al usuario retirar los tokens en la cadena destino.

El servidor backend debe asegurarse de que la transacción de recarga sea auténtica y no falsificada. Este servidor decide si el usuario puede retirar los tokens en la cadena destino, por lo que es un objetivo principal para los ataques.

El servidor debe validar la estructura del evento de inicio de la transacción y la dirección del contrato que la inició. Si se omite esta última validación, un atacante podría desplegar un contrato malicioso que falsifique eventos de recarga con la misma estructura que los legítimos.

Si el servidor no valida qué dirección inició el evento, considerará la transacción como válida y firmará el mensaje. El atacante podría enviar el hash de la transacción al servidor y, saltándose la validación, retirar los tokens en la cadena destino.

Manejo inapropiado de tokens nativos

Los puentes entre cadenas utilizan diferentes métodos para manejar tokens nativos y tokens de utilidad. Por ejemplo, en la red de Ethereum, el token nativo es ETH, y la mayoría de los tokens de utilidad cumplen con el estándar ERC-20.

Si un usuario desea transferir su ETH a otra cadena, primero debe depositarlo en el contrato del puente. Para ello, simplemente adjunta ETH a la transacción, y puede recuperar la cantidad de ETH mediante la lectura del campo “msg.value” en la transacción.

Depositar tokens ERC-20 es muy diferente a depositar ETH. Para depositar tokens ERC-20, el usuario debe primero aprobar que el contrato del puente pueda usar sus tokens. Tras aprobar y depositar los tokens en el contrato, este puede quemar los tokens del usuario usando la función “burnFrom(” o transferir los tokens a su propio contrato mediante “transferFrom)”.

Para distinguir entre estas operaciones, se puede usar una sentencia if-else en la misma función o crear funciones separadas para cada escenario. Debido a las diferencias en el manejo, si un usuario intenta usar la función de recarga de ERC-20 para depositar ETH, es posible que los fondos se pierdan.

Al procesar solicitudes de recarga de ERC-20, los usuarios suelen proporcionar la dirección del token como parámetro de entrada. Esto representa un riesgo importante, ya que durante la transacción puede ocurrir una llamada externa no confiable. La práctica común para minimizar riesgos es usar una lista blanca que incluya solo los tokens soportados por el puente. Solo las direcciones en la lista blanca se pasan como parámetros, evitando llamadas externas no confiables, ya que el equipo del proyecto filtra las direcciones de tokens permitidos.

Sin embargo, cuando el puente maneja transferencias de tokens nativos entre cadenas, también hay complicaciones, ya que los tokens nativos no tienen dirección. Se puede usar una dirección especial para representarlos, como la “dirección cero(0x000… 0)”. Pero esto presenta un problema: si la lógica de validación de la lista blanca no está correctamente implementada, pasar la dirección cero al contrato puede saltarse la validación de la lista blanca.

Cuando el contrato del puente llama a “TransferFrom” para transferir activos del usuario al contrato, la llamada externa a la dirección cero devolverá false, ya que la dirección cero no implementa “transferFrom”. Pero si el contrato no maneja correctamente el valor de retorno, la transacción aún puede continuar, creando una oportunidad para que un atacante ejecute la operación sin transferir tokens al contrato.

Errores de configuración

En la mayoría de los puentes entre cadenas, existe un rol privilegiado responsable de incluir direcciones y tokens en listas blancas o negras, asignar o cambiar firmantes y otras configuraciones clave. Garantizar que toda la configuración sea correcta es fundamental, ya que un descuido aparentemente menor puede causar pérdidas importantes.

De hecho, ha ocurrido que un atacante logró evadir la validación de registros de transferencia debido a un error de configuración. El equipo del proyecto realizó una actualización del protocolo unos días antes del ataque, modificando una variable que indica el valor predeterminado para mensajes confiables. Este cambio hizo que todos los mensajes se consideraran automáticamente validados, permitiendo a un atacante enviar cualquier mensaje y que fuera aceptado sin verificaciones adicionales.

¿Cómo mejorar la seguridad de los puentes entre cadenas?

Los cuatro vulnerabilidades comunes descritas muestran que los desafíos de seguridad en el ecosistema de cadenas conectadas no deben subestimarse. Para abordar estos problemas, es necesario adoptar un enfoque “adaptado a cada caso”, ya que no existe una solución universal que pueda cubrir todas las vulnerabilidades.

Por ejemplo, dado que cada puente entre cadenas tiene requisitos de validación únicos, ofrecer solo directrices generales para garantizar que el proceso de validación sea correcto es difícil. La forma más efectiva de prevenir eludir la validación es realizar pruebas exhaustivas en todos los posibles vectores de ataque y asegurarse de que la lógica de validación sea razonable.

En resumen, es imprescindible realizar pruebas rigurosas contra posibles ataques y prestar especial atención a las vulnerabilidades de seguridad más frecuentes en los puentes entre cadenas.

Conclusión

Debido a la gran cantidad de fondos involucrados, los puentes entre cadenas han sido objetivos de ataques durante mucho tiempo. Los desarrolladores pueden fortalecer la seguridad de estos puentes mediante pruebas exhaustivas antes del despliegue y auditorías de terceros, reduciendo así el riesgo de ataques catastróficos que han afectado a estos sistemas en los últimos años. Los puentes entre cadenas son fundamentales en un mundo multichain, pero en el diseño y construcción de infraestructuras Web3 efectivas, la seguridad debe ser la prioridad principal. ($STO