Recientemente, mientras trabajábamos con uno de nuestros clientes, descubrimos un error interesante que tiene el potencial de ser un vector de ataque para algunos proyectos de DeFi. Este error está especialmente relacionado con el conocido estándar de token ERC777. Además, no es solo un simple problema de reingreso común entre los piratas informáticos conocidos.
Este artículo proporciona una explicación completa de ERC777, cubriendo todos los detalles necesarios. Hay pocos recursos para profundizar en los detalles de los tokens ERC777, y este artículo es una valiosa guía detallada para cualquier persona interesada en aprender más sobre los tokens ERC777.
En la última parte del artículo, se explicarán nuestros hallazgos recientes.
Una breve descripción del vector de ataque
Esta vulnerabilidad aprovecha las características de ERC777 y puede establecer una función de recepción de Hook. Al utilizar la capacidad de realizar llamadas arbitrarias en el contrato de destino, una persona malintencionada puede llamar al contrato de registro ERC777 y asignar una dirección Hook específica al contrato de destino. Por lo tanto, siempre que el contrato objetivo reciba tokens ERC777 en el futuro, se activará el contrato Hook del atacante. Este gancho se puede explotar de varias maneras: ya sea para ataques de reingreso para robar tokens, o simplemente para revertir transacciones, evitando que el contrato de destino envíe o reciba tokens ERC777.
ERC777 y su Gancho
¿Qué es ERC777?
ERC777 es uno de los tokens estándar con gancho de transferencia. Aquí está la descripción de EIP: y aquí hay una práctica ERC777 [4] 。
La principal motivación para implementar tokens ERC777 es imitar el comportamiento de las transferencias de tokens nativos. Al activar contratos inteligentes cuando se reciben tokens, los desarrolladores pueden ejecutar una lógica específica para mejorar la funcionalidad y crear interacciones de tokens más dinámicas.
Sin embargo, estas llamadas adicionales durante el proceso de transferencia hacen que ERC777 sea diferente de los tokens ERC20. Estos ganchos introducen un nuevo vector de ataque que podría afectar los contratos inteligentes que no fueron diseñados para manejar llamadas adicionales durante las transferencias de tokens. Tal comportamiento inesperado crea riesgos de seguridad para estos contratos.
La siguiente es una lista de algunos tokens ERC777 con cierta liquidez en la red principal de Ethereum:
Cuando ocurre el Gancho
Los tokens ERC20 simplemente actualizan los saldos durante las transferencias. Pero los tokens ERC777 hacen esto:
Realice una llamada Hook a la dirección del iniciador del token
Actualizar saldo
Realice una llamada Hook a la dirección del receptor del token
Esto está bien ilustrado en el token VRA:
código fuente:
Ahora, examinemos el código de estas llamadas:
como viste:
Esta función lee un contrato llamado implementador de _ERC1820_REGISTRY
Si la función encuentra un implementador, se llama a ese implementador.
Exploremos este registro y veamos qué implementadores son.
Registro e implementadores
Todos los tokens ERC777 están relacionados con el contrato del Registro:
Los tokens ERC777 utilizan esta dirección para almacenar los destinatarios de Hook establecidos. Estos receptores Hook se denominan "implementadores de interfaz".
Esto significa que Alice puede elegir a Bob como su implementador de interfaz. Si Alice recibe o envía tokens ERC777, Bob recibirá el Hook.
Alice puede manejar diferentes tipos de Hook. Por lo tanto, cuando Alice envía tokens, puede elegir a Bob como implementador de la interfaz, y solo cuando Alice recibe tokens, elige a Tom como implementador.
También puede elegir diferentes implementadores de interfaz para diferentes tokens en la mayoría de los casos.
Estas preferencias se almacenan en este registro asignado:
_interfaceHash es el ID del implementador de interfaz elegido por Alice para un evento.
Y cualquiera puede leer el implementador de la interfaz de Alice con esta función:
Como puede ver, esta es la función que encontramos anteriormente en el código VRA.
La variable _TOKENS_SENDER_INTERFACE_HASH se usa como _interfaceHash, que puede ser cualquier byte. Pero el token VRA usa estos bytes para identificar este tipo de Hook:
Gancho de recepción
Para configurar una función de recepción de Hook, Alice solo necesita llamar a esta función en el registro e ingresar la dirección de Bob como el parámetro _implementer.
También debe especificar un _interfaceHash. Obtendrá este _TOKENS_SENDER_INTERFACE_HASH del código del token VRA.
Hay un detalle más importante.
Después de configurar el implementador para el VRA anterior, Alice también sabrá que incluso si se transfieren otros tokens ERC777, Bob recibirá la llamada. Como imBTC [5] , imBTC tiene el mismo _interfaceHash en los tokens enviados.
Esto se debe al hecho de que todos los tokens ERC777 comparten el mismo contrato de registro para almacenar las preferencias de Hook. Pero depende de los tokens ERC777 asignar nombres a sus Hooks, y aunque a veces son similares, no siempre.
Cómo encontrar tokens ERC777
Llamar al registro es una característica de todos los ERC777. Entonces podemos probar dune.com [6] para llamar a todos los contratos inteligentes que llaman al registro.
Podemos usar este script SQL. De hecho, deberíamos haber filtrado adicionalmente las direcciones de los tokens, pero al menos tuvimos un comienzo perfecto y terminamos con 78 direcciones.
Nota del traductor: tabla de huellas de dunas [7] Registrará el registro de llamadas internas de la transacción.
¿Es este registro la única posibilidad?
Teóricamente, nadie puede garantizar que algún token use este contrato 0x1820 como registro. Pero podemos usar dune.com [8] Ven a comprobarlo.
Verificamos y 0x1820 es el único registro con valiosos tokens ERC777. Los tokens de otros registros no son tan valiosos.
La situación general de los tokens Hookable
ERC777 no es solo un estándar con Hooks. También ERC223, ERC995 o ERC667. No son tan inusuales. Debe haber oído hablar del token LINK que implementa ERC667 [9] 。
Vector de ataque usando una llamada arbitraria
Este es un vector de ataque descubierto recientemente para uno de nuestros clientes.
Los investigadores generalmente asumen que los tokens ERC777 hacen llamadas a las personas que llaman y a los receptores. Pero, de hecho, el iniciador y el receptor pueden elegir cualquier "Bob" como receptor Hook.
Así que imagina lo que sucede cuando se combina con esos contratos que hacen llamadas arbitrarias a cualquier dirección con cualquier dato.
Hay funciones de llamadas arbitrarias que se pueden usar ampliamente en agregadores DEX, billeteras y contratos de llamadas múltiples.
Nota del traductor: la función de llamada arbitraria significa que hay una función como esta en el contrato:
función ute(dirección objetivo, valor uint, cadena de firma de memoria, bytes de datos de memoria, uint eta) pago público;
Puede llamar a cualquier otro método.
Método de ataque:
El atacante encuentra un contrato objetivo (Objetivo) que permite llamadas a funciones arbitrarias
Ahora, nuestro Atacante es el implementador de Target
Se llamará al atacante con el hookHash utilizado en el token ERC777.
Cada vez que el contrato objetivo (Objetivo) recibe tokens ERC777, el atacante recibirá una llamada Hook.
Los siguientes ataques varían según el código de destino:
El atacante puede volver a ingresar cuando algunos usuarios ejecutan funciones en el contrato de destino
El atacante puede retroceder directamente, de modo que la transacción del usuario se restaurará directamente
Si el agregador DEX calcula que la mejor ruta de conversión es a través de un par comercial DEX con tokens ERC777, entonces puede encontrar problemas.
Proteger
Después de horas de conversaciones con los clientes, encontramos una solución que no interrumpe las llamadas arbitrarias.
Es mejor para el lado del proyecto limitar el uso de Registry1820 como la dirección de cualquier llamada. Por lo tanto, ningún atacante puede explotar llamadas arbitrarias para configurar el implementador de la interfaz.
Hablando por experiencia
Los proyectos y los auditores deben prestar atención al comportamiento de Hook descrito en ERC777. Estos tokens realizan llamadas no solo a receptores e iniciadores, sino también a otros receptores Hook.
En este sentido, los proyectos que permitan llamadas arbitrarias deben tener especial cuidado y considerar otro vector de ataque para ERC777.
Ver originales
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
Posibles problemas de seguridad con ERC777 y contratos de llamadas arbitrarias
Recientemente, mientras trabajábamos con uno de nuestros clientes, descubrimos un error interesante que tiene el potencial de ser un vector de ataque para algunos proyectos de DeFi. Este error está especialmente relacionado con el conocido estándar de token ERC777. Además, no es solo un simple problema de reingreso común entre los piratas informáticos conocidos.
Este artículo proporciona una explicación completa de ERC777, cubriendo todos los detalles necesarios. Hay pocos recursos para profundizar en los detalles de los tokens ERC777, y este artículo es una valiosa guía detallada para cualquier persona interesada en aprender más sobre los tokens ERC777.
En la última parte del artículo, se explicarán nuestros hallazgos recientes.
Una breve descripción del vector de ataque
Esta vulnerabilidad aprovecha las características de ERC777 y puede establecer una función de recepción de Hook. Al utilizar la capacidad de realizar llamadas arbitrarias en el contrato de destino, una persona malintencionada puede llamar al contrato de registro ERC777 y asignar una dirección Hook específica al contrato de destino. Por lo tanto, siempre que el contrato objetivo reciba tokens ERC777 en el futuro, se activará el contrato Hook del atacante. Este gancho se puede explotar de varias maneras: ya sea para ataques de reingreso para robar tokens, o simplemente para revertir transacciones, evitando que el contrato de destino envíe o reciba tokens ERC777.
ERC777 y su Gancho
¿Qué es ERC777?
ERC777 es uno de los tokens estándar con gancho de transferencia. Aquí está la descripción de EIP: y aquí hay una práctica ERC777 [4] 。
La principal motivación para implementar tokens ERC777 es imitar el comportamiento de las transferencias de tokens nativos. Al activar contratos inteligentes cuando se reciben tokens, los desarrolladores pueden ejecutar una lógica específica para mejorar la funcionalidad y crear interacciones de tokens más dinámicas.
Sin embargo, estas llamadas adicionales durante el proceso de transferencia hacen que ERC777 sea diferente de los tokens ERC20. Estos ganchos introducen un nuevo vector de ataque que podría afectar los contratos inteligentes que no fueron diseñados para manejar llamadas adicionales durante las transferencias de tokens. Tal comportamiento inesperado crea riesgos de seguridad para estos contratos.
La siguiente es una lista de algunos tokens ERC777 con cierta liquidez en la red principal de Ethereum:
Cuando ocurre el Gancho
Los tokens ERC20 simplemente actualizan los saldos durante las transferencias. Pero los tokens ERC777 hacen esto:
Realice una llamada Hook a la dirección del iniciador del token
Actualizar saldo
Realice una llamada Hook a la dirección del receptor del token
Esto está bien ilustrado en el token VRA:
código fuente:
Ahora, examinemos el código de estas llamadas:
como viste:
Exploremos este registro y veamos qué implementadores son.
Registro e implementadores
Todos los tokens ERC777 están relacionados con el contrato del Registro:
Los tokens ERC777 utilizan esta dirección para almacenar los destinatarios de Hook establecidos. Estos receptores Hook se denominan "implementadores de interfaz".
Esto significa que Alice puede elegir a Bob como su implementador de interfaz. Si Alice recibe o envía tokens ERC777, Bob recibirá el Hook.
Alice puede manejar diferentes tipos de Hook. Por lo tanto, cuando Alice envía tokens, puede elegir a Bob como implementador de la interfaz, y solo cuando Alice recibe tokens, elige a Tom como implementador.
También puede elegir diferentes implementadores de interfaz para diferentes tokens en la mayoría de los casos.
Estas preferencias se almacenan en este registro asignado:
_interfaceHash es el ID del implementador de interfaz elegido por Alice para un evento.
Y cualquiera puede leer el implementador de la interfaz de Alice con esta función:
Como puede ver, esta es la función que encontramos anteriormente en el código VRA.
La variable _TOKENS_SENDER_INTERFACE_HASH se usa como _interfaceHash, que puede ser cualquier byte. Pero el token VRA usa estos bytes para identificar este tipo de Hook:
Gancho de recepción
Para configurar una función de recepción de Hook, Alice solo necesita llamar a esta función en el registro e ingresar la dirección de Bob como el parámetro _implementer.
También debe especificar un _interfaceHash. Obtendrá este _TOKENS_SENDER_INTERFACE_HASH del código del token VRA.
Hay un detalle más importante.
Después de configurar el implementador para el VRA anterior, Alice también sabrá que incluso si se transfieren otros tokens ERC777, Bob recibirá la llamada. Como imBTC [5] , imBTC tiene el mismo _interfaceHash en los tokens enviados.
Esto se debe al hecho de que todos los tokens ERC777 comparten el mismo contrato de registro para almacenar las preferencias de Hook. Pero depende de los tokens ERC777 asignar nombres a sus Hooks, y aunque a veces son similares, no siempre.
Cómo encontrar tokens ERC777
Llamar al registro es una característica de todos los ERC777. Entonces podemos probar dune.com [6] para llamar a todos los contratos inteligentes que llaman al registro.
Podemos usar este script SQL. De hecho, deberíamos haber filtrado adicionalmente las direcciones de los tokens, pero al menos tuvimos un comienzo perfecto y terminamos con 78 direcciones.
¿Es este registro la única posibilidad?
Teóricamente, nadie puede garantizar que algún token use este contrato 0x1820 como registro. Pero podemos usar dune.com [8] Ven a comprobarlo.
devuelve estas direcciones
0x1820a4b7618bde71dce8cdc73aab6c95905fad24 0xc0ce3461c92d95b4e1d3abeb5c9d378b1e418030 0x820c4597fc3e4193282576750ea4fcfe34ddf0a7
Verificamos y 0x1820 es el único registro con valiosos tokens ERC777. Los tokens de otros registros no son tan valiosos.
La situación general de los tokens Hookable
ERC777 no es solo un estándar con Hooks. También ERC223, ERC995 o ERC667. No son tan inusuales. Debe haber oído hablar del token LINK que implementa ERC667 [9] 。
Vector de ataque usando una llamada arbitraria
Este es un vector de ataque descubierto recientemente para uno de nuestros clientes.
Los investigadores generalmente asumen que los tokens ERC777 hacen llamadas a las personas que llaman y a los receptores. Pero, de hecho, el iniciador y el receptor pueden elegir cualquier "Bob" como receptor Hook.
Así que imagina lo que sucede cuando se combina con esos contratos que hacen llamadas arbitrarias a cualquier dirección con cualquier dato.
Hay funciones de llamadas arbitrarias que se pueden usar ampliamente en agregadores DEX, billeteras y contratos de llamadas múltiples.
Método de ataque:
Si el agregador DEX calcula que la mejor ruta de conversión es a través de un par comercial DEX con tokens ERC777, entonces puede encontrar problemas.
Proteger
Después de horas de conversaciones con los clientes, encontramos una solución que no interrumpe las llamadas arbitrarias.
Es mejor para el lado del proyecto limitar el uso de Registry1820 como la dirección de cualquier llamada. Por lo tanto, ningún atacante puede explotar llamadas arbitrarias para configurar el implementador de la interfaz.
Hablando por experiencia
Los proyectos y los auditores deben prestar atención al comportamiento de Hook descrito en ERC777. Estos tokens realizan llamadas no solo a receptores e iniciadores, sino también a otros receptores Hook.
En este sentido, los proyectos que permitan llamadas arbitrarias deben tener especial cuidado y considerar otro vector de ataque para ERC777.