El Impacto Potencial de los Tokens ERC-777 en los Protocolos DeFi

Introducción

Los tokens son parte fundamental de la experiencia promedio diaria del usuario en la blockchain. Usualmente representan divisas que pueden enviarse entre direcciones, cumpliendo muchas funciones básicas como las del intercambio, préstamo, empréstito y transferencia de fondos.

Los tokens son distintos de las divisas nativas de la cadena como Ether en Ethereum. Son aplicaciones de nivel primitivo, usualmente toman la forma de un contrato inteligente que mantiene el rastreo de los balances e impone las reglas y la autorización.

Para poder asegurar la interoperabilidad entre los tokens y las aplicaciones, con el pasar del tiempo se han desarrollado e implementado grandes estándares por los desarrolladores. De estos, el ERC-20 es, sin lugar a dudas, el más ampliamente adoptado. Sin embargo, extensiones que son menos conocidas que buscan el avance, como el ERC-677, también están disponibles.

Un problema de seguridad central introducido con ciertos estándares es la modificación del comportamiento en métodos previamente definidos del contrato inteligente. Específicamente el ERC-777 con su añadido de transferir hooks, es probablemente uno de los más problemáticos en este sentido, y estuvo recientemente en las noticias relacionados al hackeo reciente de Curve Finance. Este es el foco principal de este artículo, el cual es para cuantificar los riesgos de los protocolos DeFi en términos de capital, si no protegen contra el ataque de reentrada del ERC-777.

Este artículo fue escrito por whitehat bobface16.

Vistazo breve de los Mayores Estándares de Token

En noviembre del 2015, aproximadamente 4 meses luego del lanzamiento de Ethereum, el estándar ERC-20 fue publicado para revisión por Fabian Vogelsteller y Vitalik Buterin. Define la funcionalidad básica del token y la interfaz en términos que, casi, cualquier desarrollador e investigador de seguridad está ya familiarizado, incluyendo métodos como transfer, transferFrom y balanceOf.

El ERC-20 se ha mantenido, desde entonces, como el tipo de token más establecido de entre todo el ecosistema, con un estimado de 450.000 tokens presentes nada más en Ethereum en febrero del 2023, así como más entre otras cadenas EVM.

Un problema que fue descubierto rápidamente, luego de la adopción del ERC-20, es que los usuarios enviaban accidentalmente sus tokens a la dirección del contrato en vez del receptor
Previsto, causando que el balance de su transferencia se bloquease permanentemente. En los peores casos, los usuarios afectados perdieron millones de dólares en activos . El ERC-223 fue subsecuentemente presentado para evitar ese tipo de pérdidas. La propuesta modifica el proceso de transferencia para que cuando el receptor es un contrato inteligente, la lógica se asegure en primer lugar que esté esperando recibir tokens, llamando a un hook en el destinatario. En el caso del ERC-223, este hook se llama tokenReceived, y si no está presente en el contrato del destinatario o si falla, la transferencia se aborta, protegiéndose contra este tipo de errores.

Otra peculiaridad del ERC-20 es que el código de un contrato inteligente, en el lado del receptor de una transferencia no se ejecuta, como sería en el caso de la transferencia de Ether nativos. Para que un contrato inteligente sea capaz de saber de dónde recibió los fondos, esto ha llevado a un UX pobre de un proceso de dos pasos que conlleva ´approve´ seguido por transferFrom. El ERC-677 apuntó a resolver este problema, añadiendo el método transferAndCall, permitiendo al remitente para que opcionalmente invoque el contrato del destinatario luego que la transferencia se complete. Un ejemplo popular que implementa este estándar es el token Chainlink (LINK).

Aparte del de arriba y del ERC-777, hay muchos más estándares de token con hooks de transferencia como el ERC-721 (NFTs). Sin embargo, estos modifican la base del interfaz, los cuales lo vuelven incompatibles con el ERC-20 y, por lo tanto, no son relevantes para este análisis.

ERC-777: Una Nueva Manera de Interactuar con el Contrato de un Token

Finalmente, esto nos trae al enfoque principal del artículo: el estándar del token ERC-777. Fue publicado en primer lugar en noviembre del 2017, con la intención de avanzar las características y funcionalidad ofrecidas en los token de los contratos existentes. Enumera siete mejoras claves, incluyendo la introducción de operadores aprobados que pueden transferir tokens a nombre de los usuarios, y el registro con el registro de ERC-1820.

Implicaciones de Seguridad

Desde la perspectiva de seguridad, los añadidos más importantes son los hooks de pre-transferencia opcionales. Se diferencias de los hooks previamente descritos, ejecutando una llamada no exclusiva (tokensToSend) al emisor de la transferencia, tomando en cuenta que el emisor se haya registrado en el registro del ERC-1820 de antemano. Este hook le da el flujo de control al remitente, el cual puede llevar a la explotación de vulnerabilidades de reentrada. Considera el siguiente contrato simplificado, que le permite a los usuarios depositar y retirar tokens:

pragma solidity ^0.8.10;














interface IERC20 {


   // ...


}






contract Vault {


   // Token => Usuario => Balance


   mapping(IERC20 => mapping(address => uint256)) public deposits;






   function deposit(IERC20 token, uint256 amount) external {


       // Transferencia en los tokens.


       // Calcula la cantidad exacta recibida para manejar la tarifa de la transferencia y tokens similares.


       uint256 balanceBefore = token.balanceOf(address(this));


       require(token.transferFrom(msg.sender, address(this), amount), "Transfer failed");


       uint256 balanceAfter = token.balanceOf(address(this));


       uint256 received = balanceAfter - balanceBefore;






       // Incrementa el depósito del usuario 


       deposits[token][msg.sender] += received;


   }






   function withdraw(IERC20 token, uint256 amount) external {


       // Reduce el depósito del usuario


       deposits[token][msg.sender] -= amount;





       // Envía los tokens


       require(token.transfer(msg.sender, amount), "Transfer failed");


   }


}

Aquí, los tokens ERC-777 depositados legítimamente pueden ser drenados desde el contrato por un atacante, reentrado la función de depósito:

1. Llama a deposit con la cantidad de 0 (o 1 wei si el token no apoya el valor de transferencia 0) a través de un ataque al contrato.
2. El vault cachea su balance y llama a transferFrom.
3. El contrato del token ERC-777 invoca el hook tokensToSend en el contrato del atacante.
4. El contrato del atacante gana el flujo de control y llama de nuevo a deposit con la cantidad de 0.
5. Repite el paso de arriba varias veces.
6. Luego de algunas repeticiones, llama a deposit con una gran cantidad, por ejemplo 100 tokens, y detén la reentrada desde aquí.
7. Las llamadas anteriores a deposit continuarán luego que transferFrom se alineen los unos con los otros, después calcularán los 100 tokens received, por lo tanto, amplificando el depósito del atacante por el número de reentradas.
8. Llama a withdraw para drenar los fondos.

El problema de arriba afecta a los protocolos que se suponen que deben trabajar con cualquier token, como un DEX o un puente token, pero no consideran las implicaciones de los tokens ERC-777 y, por lo tanto, no protegen correctamente contra la reentrada.

Incidencias de Seguridad Pasadas

El escenario simplificado presentado con el contrato Vault ha llevado a hackeos serios en el pasado. El más notorio, Uniswap V1 no protegió contra la reentrada, el cual causó una pérdida de alrededor de 300K$ para que fuesen robados desde el pool imBTC. Cream Finance también sufrió un exploit similar, llevando a la pérdida de alrededor de 18.8$ millones, así como LendfMe, el cual fue explotado por alrededor de. Mientras que otros ejemplos no son tan numerosos, el daño por cada exploit individual es sustancial, mostrando que las vulnerabilidades en el ERC-777 presentan una considerable amenaza tangible al cripto.

La Capitalización del Mercado de los Tokens ERC-777

A pesar de esto, en el pasado, los proyectos han tratado esos reportes con una falta de interés general. La percepción común entre ellos parece ser que el estándar ERC-777 es viejo y despreciado, sin una adopción real o un uso en el mercado. En otras palabras: no es un problema que vale la pena resolver. Sin embargo, la pregunta se mantiene: ¿cuánto capital está realmente adjuntado con este problema?

Por suerte, responder esto no es difícil ya que el estándar en sí mismo requiere que los tokens que lo utilizan se registren en el registro mencionado ERC-1820. El registro emite un evento por cada llamada a su método setInterfaceImplementer, de los cuales podemos extraer los tokens ERC-777, revisando el campo interfaceHash para el hash de “ERC777Token” como el estándar. Al momento de escribir esto, esto rinde una cuenta de 615 tokens.

Para calcular la capitalización bursátil total circulante de estos tokens, podemos utilizar la API CoinMarketCap para reportar el precio del token y circular la demanda. Al momento de escribir esto, la capitalización combinada del mercado es, aproximadamente de 459.605.720$. No es insignificante. Algunos de los tokens más largos incluyen:

• Lukso (LYXe): 138.998.727$ @
  0xA8b919680258d369114910511cc87595aec0be6D

• Skale (SKL): 120.559.020$ @
  0x00c83aeCC790e8a4453e5dD3B0B4b3680501a7A7

• Verasity (VRA): 44.429.110$ @
  0xF411903cbC70a74d22900a5DE66A2dda66507255

• Dawn Protocol (DAWN): 42.155.332$ @
  0x580c8520dEDA0a441522AEAe0f9F7A5f29629aFa

Adicionalmente, este número representa sólo un estimado en el extremo inferior, ya que ciertas implementaciones no se registran con el registro de ERC-1820 y, por lo tanto, no son detectados por este método. Un ejemplo de esto es el token AMP (0xfF20817765cB7f73d4bde2e66e067E58D11095C2), el cual se registra bajo una interfaceHash distinta.

Actualmente tiene una oferta circulante del mercado bursátil de 130.530.352$.

Sumario

Mientras el ERC-777 no ha encontrado una adopción cercana a los de los estándares ERC-20 o ERC-721, aún representan el equivalente de medio millardo de dólares Norteamericanos en fondos en riesgo. Cualquier proyecto que está construído en la premisa de permitir la interacción con un tipo de token ERC-20 basado, el cual incluye la mayoría de los intercambios descentralizados, puentes token, o plataformas de préstamos sin permisos, deberían estar conscientes de la seriedad de este riesgo y tomar los pasos necesarios para proteger a sus usuarios contra los problemas de reentrada que tienen los tokens que usan este estándar.

Este artículo es una traducción de Immunefi Editor, hecha por Gabriella Martínez. Puedes encontrar el artículo original aquí
Sería genial escucharte en nuestro Discord, puedes contarnos tus ideas, comentarios, sugerencias y dejarnos saber lo que necesitas.
Si prefieres puedes escribirnos a @web3dev_es en Twitter.