Equipo de seguridad de CoinEx: los riesgos de seguridad de THORChain (RUNE)

Según el informe de tesorería de THORChain para el primer trimestre de 2022 publicado el 1 de abril, la cadena registró un crecimiento en los ingresos a pesar del doble impacto de la persistente lentitud del mercado y los factores geopolíticos altamente inestables. Los datos públicos muestran que THORChain registró $ 2170 millones en ingresos en el primer trimestre de 2022. THORChain, aclamada como la “versión de cadena cruzada de UniSwap”, se afianzó en el mercado comercial de cadena cruzada gracias a sus ventajas únicas y obtuvo un amplio reconocimiento entre los inversores.

Detrás de todos estos glamour, THORChain también está profundamente preocupado por la piratería. La cadena sufrió frecuentes brechas de seguridad desde su lanzamiento en Ethereum, hecho que pone en duda su seguridad. El 11 de abril, THORChain tuiteó sobre ataques de phishing, advirtiendo a los usuarios que no interactúen con [DeTHOR] u otros tokens desconocidos dentro de sus billeteras, lo que una vez más generó preocupaciones sobre sus problemas de seguridad.

Mientras construye un sistema de seguridad sólido para los productos CoinEx, el equipo de seguridad de CoinEx también realiza un seguimiento de los incidentes de seguridad en el espacio de la cadena de bloques para ayudar a los usuarios a comprender mejor la seguridad de los diferentes proyectos desde la perspectiva de la seguridad técnica y mitigar el riesgo de inversión. Con el objetivo de mejorar los criterios de seguridad para el sector blockchain, el equipo de seguridad de CoinEx ha analizado los riesgos de seguridad de THORChain (RUNE). El equipo espera que THORChain pueda notar y mitigar los siguientes riesgos al optimizar los códigos de contrato inteligente relevantes. Además, este artículo también es una advertencia para los usuarios, recordándoles que sean más conscientes de la seguridad de los activos y eviten pérdidas de activos.

¿Qué tan seguro es THORChain (RUNE)?

A través del análisis del código de contrato y la lógica de THORChain (RUNE), el equipo de seguridad de CoinEx ha encontrado los siguientes riesgos:

Para empezar, veamos el código de contrato de THORChain (RUNE):

https://etherscan.io/address/0x3155ba85d5f96b2d030a4966af206230e46849cb#código

Podemos decir que RUNE es un token ERC-20 bastante estándar. Cabe señalar que además de la interfaz ERC-20, THORChain (RUNE) ofrece una interfaz adicional:

Según transferTo (como se muestra en la imagen de arriba), THORChain (RUNE) usa tx.origin, que es una de las causas detrás de sus riesgos de seguridad. Aquí, debemos explicar la diferencia entre tx.origin y msg.sender:

La siguiente imagen describe lo que sucede cuando una dirección normal llama al contrato inteligente:

En tales casos, msg.sender = account.address y tx.origin = account.address, lo que significa que msg.sender es lo mismo que tx.origin.

Lo siguiente es lo que sucede cuando una cuenta llama al contrato A y el contrato A llama al contrato B:

Cuando el contrato A llama al contrato B (como se muestra arriba), podemos decir que msg.sender es igual a tx.origin en el contrato A.

Sin embargo, en el contrato B, msg.sender = contractA.address, mientras que tx.origin = account.address. Por lo tanto, tx.origin es como una variable global que atraviesa toda la pila de llamadas y devuelve la dirección de la cuenta que envió originalmente la transacción. Este es el tema clave: hasta la fecha, casi todos los ataques conocidos contra THORChain (RUNE) se relacionan con tx.origin.

Veamos ahora cómo los atacantes roban los tokens RUNE de los usuarios a través de tx.origin:

Ataque n.º 1: Robar una cabra de un rebaño

Las direcciones en Ethereum se dividen en direcciones externas y direcciones de contrato. Transferir ETH a estos dos tipos de direcciones a través de direcciones externas es fundamentalmente diferente. La Documentación Oficial de solidez establece que una dirección de contrato debe implementar una función de recepción de Ether antes de realizar transferencias.

A la luz de las características de tx.origin, los piratas informáticos pueden crear un contrato de ataque:

Cuando el contrato Attack recibe una transferencia ETH de un usuario, “robará una cabra de un rebaño”: el contrato robará los tokens RUNE del usuario en el proceso.

Ataque No.2: Ataque Interno

Un ataque interno es un tipo especial de ataque. Al intentar robar la RUNE de un usuario a través de un ataque interno, el hacker necesita tener un token mediano. Además, el token también debe llamar a contratos de terceros. Según los registros de transferencia de RUNE en Ethereum, algunos atacantes piratearon RUNE a través de transferencias de tokens AMP.

AMP Token utiliza el estándar ERC-1820 para administrar el registro de Hook y examinar si Hook está registrado en cada transferencia. Si se ha registrado Hook, se llamará al Hook.

El código de contrato de AMP Token muestra que la implementación final de la transferencia es: _transferByPartition. Mientras tanto, hay dos llamadas relacionadas con transferHook: _callPreTransferHooks (antes de la transferencia) y _callPostTransferHooks (después de la transferencia). En particular, _callPreTransferHooks es para la dirección de origen, mientras que _callPostTransferHooks es para la dirección de destino (es decir, la dirección de recepción).

Para los usuarios habituales, robar tokens de sí mismos no tiene sentido. Por lo tanto, los atacantes pueden explotar _callPostTransferHooks. Veamos ahora los códigos de _callPostTransferHooks.

IAmpTokensRecipient(Implementación del destinatario).tokensReceived()

Podemos decir que la única devolución de llamada que los atacantes podrían explotar es IAmpTokensRecipient(recipientImplementation).tokensReceived()

A continuación, ilustraremos cómo se puede usar esta llamada para transferir el RUNE de un usuario mientras se realiza una transferencia de token AMP.

Paso 1: Se necesita un contrato de llamada (como se muestra a continuación):

Paso 2: Implemente el contrato para obtener la dirección de ataque.

Paso 3: Llame a la interfaz de contrato ERC-1820 (setInterfaceImplementer) para registrar la interfaz.

ERC-1820 Dirección: 0x1820a4B7618BdE71Dce8cdc73aAB6C95905faD24

Interfaz de contrato: setInterfaceImplementer(dirección aAddr, bytes32 interfaceHash, implementador de direcciones)

En particular, toAddr es la dirección de recepción de la transferencia AMP,

interfaceHash es el hash de AmpTokensRecipient:

0xfa352d6368bbc643bcf9d528ffaba5dd3e826137bc42f935045c6c227bd4c72a

interfaceHash es el hash de AmpTokensRecipient:

0xfa352d6368bbc643bcf9d528ffaba5dd3e826137bc42f935045c6c227bd4c72a

Implementador es la dirección de ataque obtenida en el paso 2.

Paso 4: Atrae a un usuario para que transfiera AMP a toAddr para activar una devolución de llamada y robar su RUNE al mismo tiempo.

Ataque n.º 3: Ataque de phishing

Como su nombre indica, en un ataque de phishing, el atacante promete regalar beneficios increíbles para atraer a los usuarios a realizar ciertas operaciones de contrato. Aquí, presentaremos un ataque de phishing común.

Paso 1: El atacante emite un token ERC-20 y puede escribirlo en cualquier interfaz de contrato que involucre firmas.

Paso 2: Cree un par comercial en Uniswap o cualquier otro intercambio;

Paso 3: Ofrezca airdrops a todos los usuarios/direcciones que tengan tokens RUNE;

El trabajo inicial del ataque de phishing se completa básicamente a través de los pasos anteriores. Luego, el atacante solo tiene que esperar a que los usuarios intercambien en un intercambio, y los usuarios corren el riesgo de perder su RUNE una vez que realizan operaciones como aprobación, transferencia, etc.

Además, para verificar aún más el riesgo de seguridad del código de contrato de THORChain, CoinEx ha discutido con el equipo de seguridad de SlowMist y PeckShield, dos agencias de seguridad reconocidas en la industria. Confirmado por SlowMist y PeckShield, el riesgo de seguridad mencionado anteriormente existe.

Hasta ahora, hemos cubierto varios tipos de ataques, así como los riesgos de seguridad a los que están expuestos los usuarios.

¿Cómo debería optimizar el equipo del proyecto el código del contrato para hacerse más seguro y proteger los activos de los usuarios?

La única respuesta es tener cuidado al usar tx.origin.

¿Cómo pueden los usuarios habituales mitigar los riesgos y proteger sus activos frente a ataques que parecen inevitables? El equipo de seguridad de CoinEx ofrece las siguientes sugerencias:

  1. Para el Ataque No.1: Al realizar una transferencia, lleve un registro del consumo de Gas estimado. Para una transferencia regular de ETH, una tarifa de gas de 21 000 es más que suficiente. Ojo si el consumo de Gas supera con creces esa cifra.
  2. Para el Ataque No.2: Aísle sus tokens adoptando diferentes billeteras. Puede almacenar diferentes tokens en diferentes direcciones. Se necesita precaución adicional cuando se trata de la dirección de la billetera caliente que ofrecen los intercambios.
  3. Para el Ataque No.3: La codicia es la fuente de todo mal. No participes ciegamente en ningún evento de airdrop.

La seguridad siempre ha sido una de las principales preocupaciones en el sector de las cadenas de bloques. Todos los jugadores, incluidos los equipos de proyectos y los intercambios, deben priorizar la seguridad durante la operación del proyecto, mantener los activos de los usuarios seguros y protegidos y promover conjuntamente el crecimiento sólido de la industria de la cadena de bloques.