Un comerciante pierde 26 millones de dólares en tokens ezETH: los medios culpan al usuario y un pirata informático denuncia las fallas de ERC-20

• Mi nombre es Dexaran. Soy un hacker, he diseñado y ejecutado uno de los ataques a nivel de consenso más grandes de la industria . En 2019, realicé un ataque DDOS a la red principal de EOS y la congelé durante un mes explotando una falla en su modelo de recursos de consenso. EOS estaba clasificada entre las 7 mejores en ese momento. ( Informe de EOSGO , informe de la comunidad )

  
  

• Soy fundador de uno de los equipos de desarrollo principales de Ethereum Classic . ( Artículo de Cointelegraph )

  
  

• He diseñado la Enmienda al consenso de Nakamoto , un conjunto de reglas que solucionan el 51% de los ataques que eran el azote de la industria de las cadenas de POW.

Accidente

Un usuario perdió $26,000,000 en tokens ezETH al enviarlos a un contrato inteligente. Hay varios artículos e hilos de Twitter que afirman que esto fue un error del usuario, por ejemplo, este de CoinTelegraph .

Esto es incorrecto. Un error similar de un usuario no resultaría en la pérdida de tokens Eth, NFT o ERC-223 . Las transferencias a direcciones de propiedad externa y las transferencias a contratos inteligentes funcionan de manera diferente.

Si el usuario enviara tokens a una dirección incorrecta (que no es un contrato inteligente) o a una dirección que no es propiedad de nadie, eso sería un error del usuario.

En este caso, sin embargo, el usuario depositó tokens en un contrato inteligente. Se supone que los contratos inteligentes evitan este tipo de errores, y ciertamente pueden hacerlo: por ejemplo, si un usuario depositara Ether (o cualquier otra moneda nativa), NFT (ERC-721) o tokens ERC-223 en un contrato inteligente que no fue diseñado para recibirlos, entonces los tokens no se perderían. Habría un error de transacción y la transferencia de tokens simplemente no se realizaría.

El manejo de errores es uno de los principios más básicos de la seguridad del software. Diseñar un software de tal manera que no sea posible manejar adecuadamente los errores de invocación es lo mismo que no tener el modificador onlyOwner en una función de gobernanza, lo que sería un problema de seguridad.

Este es un problema del estándar ERC-20: está diseñado de tal manera que hace imposible el manejo de errores. Y esto es un problema de seguridad. El estándar ERC-20 es inseguro . En 2023, el propio creador del estándar ERC-20 confirmó que este es un problema de seguridad del estándar .

Lo he informado en 2017 aquí y aquí . Además, he diseñado el estándar ERC-223 para resolver este problema exacto en 2017. Aquí está el hilo original de EIP-223 donde se destaca que este estándar evita la pérdida de dinero.

Es demasiado fácil para las empresas de seguridad y los desarrolladores culpar a los usuarios por cometer un error. Sin embargo, la culpa es del desarrollador, que creó sus aplicaciones utilizando un estándar inseguro que no aborda los errores de los usuarios y que resultó en un daño tan desastroso.

Historia

He destacado que esto puede causar daños financieros a los usuarios y lo he informado a la Fundación Ethereum. No han hecho nada durante 7 años.

• Se perdieron $16.000 debido a este problema en 2017.
• Se perdieron 2.000.000 de dólares en 2018
• $60.000.000 en 2023
• El 1 de noviembre de 2024 había $90,000,000 (excluyendo los 25 millones perdidos en el contrato ezETH)
• Ahora hay $115.000.000

Mi equipo desarrolló un script que calcula la cantidad de tokens perdidos:

https://dexaran.github.io/erc20-losses

• En 2017 otro usuario perdió 130K.
• En 2020 un usuario perdió los ahorros de toda su vida.
• En 2023, un usuario perdió $240 000 en una transacción.
• Luego el hacker de Poloniex perdió 2,5 millones de dólares.

Solicité dejar de promover el estándar ERC-20 debido a este problema de seguridad en 2017, no hubo respuesta https://github.com/ethereum/ethereum-org/issues/755 .

He escalado este problema a EthereumCatHerders, aquellos tipos que administran los EIP en Ethereum.

En 2023 respondieron “no tenemos nada que ver con revelaciones de seguridad, no tenemos un proceso para eso”.

Aclaración: Los EIP y los ERC son propuestas que cualquiera puede enviar a Ethereum. Pueden convertirse en estándares o modificaciones que los desarrolladores apliquen al funcionamiento de Ethereum. Son archivos de texto en su repositorio de Github.

Contexto: no tienen un proceso para abordar las divulgaciones de seguridad en los EIP 10 años después del lanzamiento del proyecto Ethereum.

Estaba proponiendo un método para modificar el funcionamiento de los EIP para permitir divulgaciones de seguridad: https://ethereum-magicians.org/t/modification-of-eip-process-to-account-for-security-treatments/16265

Propuse agregar una advertencia sobre ERC-20 y documentar el problema en los EIP. Aquí está su propuesta, donde decidieron que necesitaba crear otro EIP informativo que divulgaría una vulnerabilidad en EIP-20: https://github.com/ethcatherders/EIPIP/issues/257#issuecomment-1693372317

Lo hice. Rechazaron mi declaración de EIP después de eso.

Se me ocurrió la propuesta de revivir mi idea inicial que describí en el foro de EthereumMagicians que permitiría divulgaciones de seguridad en la sección “Consideraciones de seguridad” de los EIP en 2024 una vez más.

Aquí está mi discusión con los editores de EIP: https://www.youtube.com/watch?v=PKkJNqcozhw&t=744s

Como resultado, los editores de EIP me dijeron que votarán sobre eso: https://github.com/ethcatherders/EIPIP/issues/349

Mi propuesta fue rechazada. Todavía no existe un proceso para abordar las divulgaciones de seguridad en los EIP. El problema de ERC-20 no se ha solucionado. Ni siquiera se informa ni se documenta como un problema, por lo que los implementadores siguen reproduciéndolo una y otra vez.

Auditores injustos

Personalmente informé este problema a OpenZeppelin y solicité una solución tres veces.

• En 2018 https://github.com/OpenZeppelin/openzeppelin-contracts/issues/729

  
  

• En 2023 https://github.com/OpenZeppelin/openzeppelin-contracts/issues/4451

  
  

• Después de que rechazaron los dos anteriores, decidí informarlo de una manera que demostrara la gravedad del problema, así que lo envié a su programa de recompensas por errores porque se ajusta a los criterios de "vulnerabilidad de seguridad crítica" según sus propias reglas https://github.com/OpenZeppelin/openzeppelin-contracts/issues/4474#issuecomment-1646901022

OpenZeppelin lo rechazó con una “revelación pública de una vulnerabilidad sin parchear” (lo que confirma que al menos se trata de un problema de seguridad).

Hace unos días en Devcon7, se le hizo una pregunta a ese mismo chico de OpenZeppelin que cerró un problema en su github con respecto a ese problema: https://www.youtube.com/watch?app=desktop&v=DKJYpdXsOwQ&start=406

6 años después de que se reportó y después de que causó pérdidas de $115,000,000 a sus usuarios.

Su respuesta ni siquiera es cierta. En lugar de tener un problema abierto, cerraron 3 problemas que abrí y rechazaron todas las recomendaciones que hice.

Conclusión

1. La Fundación Ethereum censura cualquier intento de destacar el problema, que provocó que los usuarios del ecosistema perdieran 115.000.000 de dólares. El problema no se anuncia, la divulgación no se gestiona adecuadamente y los implementadores siguen reproduciéndolo en nuevos contratos.

   
   

   Creo que consideran que sería demasiado perjudicial para su reputación revelarlo.

2. Auditores como OpenZeppelin tampoco están revelando el problema, probablemente porque tienen un conflicto de intereses, ya que colocaron la etiqueta “Seguro” en cientos de contratos ERC-20 que auditaron.

   
   

3. Los desarrolladores dicen: “Simplemente estamos implementando el estándar tal como está”.

   
   

4. El estándar se rige por el proceso EIP, el proceso EIP no está diseñado para abordar divulgaciones de seguridad.

El proceso de EIP debe modificarse. El problema del ERC-20 debe divulgarse y documentarse adecuadamente. Lo ideal sería implementar un nuevo estándar. Aplicar un conjunto de “parches” al ERC-20 para mitigar el daño es mejor que no hacer nada, pero no resolvería el problema en sí.

Todos los que dicen que “el problema se puede resolver a nivel de la billetera” carecen de conocimientos de seguridad. Existe un principio de seguridad por diseño en la seguridad del software, lo que significa que no se puede crear un software inseguro, decirle a todos cómo usarlo para que no afecte a los usuarios y pretender que no causará daños. No en el sector financiero. Ese enfoque podría funcionar en el diseño web, por ejemplo, donde el costo de un error es que alguien no pueda cargar una fuente adecuada para su página web. En el sector financiero, esto da como resultado millones de dólares perdidos.

Es absolutamente imposible garantizar que todos los desarrolladores de billeteras en todo el futuro de la civilización humana siempre implementarán adecuadamente todas las correcciones necesarias.