Lograr interoperabilidad en el ecosistema blockchain requiere la existencia de puentes entre cadenas, que desempeñan un papel crucial. Consecuentemente, priorizar la seguridad de estos puentes se vuelve esencial. Discutamos esto en nuestro blog.
Las debilidades en la seguridad de los puentes suelen involucrar una validación on-chain y off-chain insuficiente, una gestión inadecuada de tokens nativos y malas configuraciones. Para garantizar una lógica de verificación sólida, es recomendable probar exhaustivamente el puente frente a diversos vectores de ataque.
Un puente blockchain es un protocolo que facilita la conectividad entre dos cadenas, permitiendo interacciones entre ellas. Supongamos que posees Bitcoin pero deseas participar en operaciones DeFi en la red Ethereum. En tal escenario, un puente blockchain te permite realizar estas actividades sin liquidar tus tenencias de Bitcoin.
Los puentes blockchain funcionan implementando diversos mecanismos de validación on-chain y off-chain, críticos para lograr interoperabilidad en el ámbito blockchain. Por consiguiente, presentan vulnerabilidades específicas en cuanto a seguridad.
Según estimaciones de la industria, los ataques a puentes provocaron pérdidas aproximadas de 1.300 millones de USD en 2022, constituyendo el 36% del total de pérdidas de ese año. Estos ataques se enfocan principalmente en aplicaciones cross-chain, ya que los puentes, a menudo implementados como contratos inteligentes, tienden a acumular tokens significativos al transferirlos entre cadenas. En consecuencia, los puentes se convierten en objetivos atractivos para los hackers por su alto valor.
Además, los puentes blockchain abarcan numerosos componentes, presentando una amplia superficie de ataque. Los actores maliciosos están altamente motivados a explotar vulnerabilidades dentro de estos puentes para desviar fondos considerables.
Para reforzar la seguridad de los puentes, es crucial comprender de forma integral las vulnerabilidades comunes que pueden surgir en su diseño. Antes de su lanzamiento, es aconsejable someter los puentes a pruebas exhaustivas para identificar y corregir estas fallas. Estos riesgos de seguridad pueden clasificarse en distintas áreas.
En ciertos puentes, especialmente los diseñados para aplicaciones descentralizadas (DApps) concretas, se minimiza el énfasis en la validación on-chain. Estos puentes dependen de un backend centralizado para ejecutar operaciones fundamentales como minteo, quema y transferencias de tokens, mientras que los procesos de validación se realizan off-chain.
Por el contrario, otros puentes utilizan contratos inteligentes para validar mensajes y ejecutar verificaciones on-chain. Cuando un usuario inicia un depósito de fondos en una cadena, el contrato inteligente genera un mensaje firmado e incluye la firma dentro de la transacción.
Dicha firma sirve como prueba del depósito y posteriormente se emplea para autenticar la solicitud de retiro del usuario en la cadena de destino. Este proceso robusto mitiga ataques potenciales, incluidos ataques de repetición (replay) y registros de depósito falsificados.
No obstante, si existe una vulnerabilidad en la fase de validación on-chain, un atacante puede explotarla para causar daño significativo. Por ejemplo, en el caso de un puente que emplea un árbol de Merkle para validar registros de transacciones, un atacante podría fabricar pruebas falsificadas. Esta acción maliciosa les permitiría eludir la validación de pruebas y mintear tokens nuevos ilícitamente en su cuenta, aprovechando la debilidad en el proceso de validación.
La incorporación de los llamados "wrapped tokens" es una estrategia común empleada por ciertos puentes. Por ejemplo, cuando un usuario transfiere DAI desde la blockchain de Ethereum a BNB Chain, sus DAI se retiran del contrato en Ethereum y se genera una cantidad equivalente de DAI envuelto en la BNB Chain.
Sin embargo, si la validación de esta transacción es insuficiente, se abre la puerta para que posibles atacantes exploten el sistema. Al desplegar un contrato malicioso y manipular su función, estos atacantes pueden desviar los tokens envueltos del puente hacia una dirección no prevista.
Para ejecutar con éxito tal ataque, los perpetradores dependen de que las víctimas aprueben el contrato del puente, permitiendo la transferencia de tokens vía la función "transferFrom". Esto les posibilita drenar activos del contrato del puente.
Lamentablemente, esta situación se agrava por la práctica de muchos puentes de solicitar aprobaciones de token infinitas a los usuarios de aplicaciones descentralizadas. Aunque este enfoque puede reducir las tarifas de gas, introduce riesgos adicionales al permitir que un contrato inteligente acceda a tokens ilimitados desde la cartera de un usuario. Explotando la ausencia de validación adecuada y la aprobación excesiva concedida, los atacantes pueden desviar tokens de usuarios desprevenidos hacia sí mismos.
En algunos sistemas de puentes, el servidor backend off-chain desempeña un papel crítico en la verificación de la legitimidad de los mensajes enviados desde la blockchain. En este caso, nos centramos en la verificación de las transacciones de depósito.
Un puente blockchain con validación off-chain funciona de la siguiente manera:
El servidor backend debe asegurarse de que la transacción de depósito que procesa realmente ocurrió y no fue falsificada. Este servidor determina si un usuario puede retirar tokens en la cadena de destino y es un objetivo de alto valor para los atacantes.
El servidor backend necesita validar la estructura del evento emitido por la transacción y la dirección del 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 un evento legítimo.
Si el servidor backend no verifica qué dirección emitió el evento, lo consideraría una transacción válida y firmaría el mensaje. El atacante podría entonces enviar el hash de la transacción al backend, eludiendo la verificación y permitiéndose retirar los tokens en la cadena de destino.
Los puentes emplean distintos enfoques al tratar tokens nativos y tokens de utilidad. En la red Ethereum, el token nativo es ETH, mientras que la mayoría de los tokens de utilidad se ajustan al estándar ERC-20. Los usuarios deben depositar inicialmente ETH en el contrato del puente para transferirlo a otra cadena. Esto se logra adjuntando el ETH a la transacción y recuperando la cantidad desde el campo "msg.value".
Depositar tokens ERC-20 difiere significativamente de depositar ETH. Para depósitos de tokens ERC-20, los usuarios necesitan otorgar permiso al contrato del puente para gastar sus tokens. Una vez depositados, el contrato o bien quemará los tokens del usuario usando la función "burnFrom()" o transferirá los tokens al contrato usando la función "transferFrom()".
Existen distintos enfoques para distinguir entre ambos escenarios. Un método utiliza una sentencia if-else dentro de la misma función, mientras que otro emplea funciones separadas para cada caso. Es crucial evitar intentar depositar ETH usando la función de depósito ERC-20, ya que esto puede resultar en la pérdida de fondos.
Al manejar solicitudes de depósito ERC-20, los usuarios suelen proporcionar la dirección del token como entrada a la función de depósito. Sin embargo, esto plantea un riesgo porque pueden producirse llamadas externas no confiables durante la transacción. Para mitigar este riesgo, una práctica común es implementar una lista blanca que incluya solo los tokens soportados por el puente. Permitiendo únicamente direcciones en la whitelist como argumentos, se evitan llamadas externas puesto que el equipo del proyecto ya filtró las direcciones de tokens.
No obstante, pueden surgir desafíos cuando los puentes manejan transferencias cross-chain de tokens nativos, ya que los tokens nativos no poseen direcciones. En su lugar, una dirección nula (0x000...0) representa el token nativo. Esto puede ser problemático porque pasar la dirección nula a la función puede eludir la verificación de la whitelist, incluso si está implementada incorrectamente.
En casos donde el contrato del puente llama a "transferFrom" para transferir los activos del usuario al contrato, una llamada externa a la dirección nula devolverá false, puesto que la dirección nula no tiene implementada una función "transferFrom". Sin embargo, si el contrato no maneja apropiadamente el valor de retorno, la transacción aún puede realizarse sin transferir tokens al contrato. Esto permite a los atacantes ejecutar transacciones sin transferir tokens al contrato.
La responsabilidad de incluir o excluir tokens y direcciones en listas blancas o negras, asignar o cambiar firmantes y otras configuraciones críticas en la mayoría de los puentes blockchain recae en un rol privilegiado. Una configuración precisa es esencial, ya que incluso descuidos menores pueden tener consecuencias significativas.
Un atacante explotó una mala configuración para eludir la verificación de registros de transferencia. El equipo del proyecto implementó una actualización del protocolo que implicó modificar una variable. Esta variable representaba el valor predeterminado del mensaje de confianza. Este cambio resultó en mensajes probados automáticamente, permitiendo al atacante enviar cualquier mensaje y pasar la verificación.
Abordar los desafíos de seguridad en un ecosistema blockchain interconectado requiere comprender las cuatro vulnerabilidades comunes de puentes discutidas anteriormente. Cada vulnerabilidad presenta sus consideraciones, y no existe una solución única para todos los casos.
Al establecer procesos de verificación sin errores, es difícil proporcionar pautas genéricas debido a los distintos requisitos de verificación de cada puente. La estrategia más eficaz implica pruebas exhaustivas para identificar y mitigar posibles vectores de ataque, al tiempo que se garantiza la integridad de la lógica de verificación. En conclusión, someter a pruebas rigurosas frente a ataques potenciales y adoptar un enfoque centrado en abordar las vulnerabilidades prevalentes en los puentes es vital para mantener un entorno seguro.
Los puentes cross-chain han sido durante mucho tiempo un objetivo para atacantes debido a su considerable valor. Los desarrolladores pueden reducir el peligro de los ciberataques graves que han afectado a los puentes en los últimos años realizando pruebas exhaustivas antes del despliegue y participando en auditorías de terceros. Los puentes son esenciales en un mundo con múltiples cadenas, pero al diseñar y construir una infraestructura Web3, la seguridad debe ser la prioridad.