 . 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. (   ,   ) 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 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   , un conjunto de reglas que   que eran el azote de la industria de las cadenas de POW. Enmienda al consenso de Nakamoto solucionan el 51% de los ataques  Nota del editor: Esta historia representa las opiniones del autor de la misma. El autor no está afiliado al personal de HackerNoon y escribió esta historia por su cuenta. El equipo editorial de HackerNoon solo ha verificado la historia para comprobar su precisión gramatical y no aprueba ni condena ninguna de las afirmaciones contenidas en el presente. #DYOR   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    . Las transferencias a direcciones de propiedad externa y las transferencias a contratos inteligentes funcionan de manera diferente. Esto es incorrecto. Un error similar de un usuario no resultaría en la pérdida de tokens Eth, NFT o ERC-223  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   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. ERC-223  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   en una función de gobernanza, lo que sería un problema de seguridad. onlyOwner  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.   . En 2023, el   . El estándar ERC-20 es inseguro propio creador del estándar ERC-20 confirmó que este es un problema de seguridad del estándar  Lo he informado en 2017   y   . Además, he diseñado el estándar ERC-223 para resolver este problema exacto en 2017. Aquí está el hilo   donde se destaca que este estándar evita la pérdida de dinero. aquí aquí original de EIP-223     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   “no tenemos nada que ver con revelaciones de seguridad, no tenemos un proceso para eso”. respondieron  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.   mi declaración de EIP después de eso. Rechazaron  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  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.  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.  Los desarrolladores dicen: “Simplemente estamos implementando el estándar tal como está”.  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   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. seguridad por diseño  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.

Read My Stories

Este audio es producido en el idioma original de la historia!

Demasiado Largo; Para Leer

CTA: Download the FREE AI Productivity Shift report

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

About Author

COMENTARIOS

ETIQUETAS

ESTE ARTÍCULO FUE PRESENTADO EN

Related Stories

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

Una guía del arquitecto para crear una arquitectura de referencia para un lago de datos de IA/ML

De los foros a los feeds: cómo los algoritmos de las redes sociales influyen en la interacción digital

Las capas invisibles: por qué las entrevistas con los usuarios son un activo irremplazable

La fuga rápida del sistema Claude Sonnet 3.5: un análisis forense

Una guía del arquitecto para crear una arquitectura de referencia para un lago de datos de IA/ML

De los foros a los feeds: cómo los algoritmos de las redes sociales influyen en la interacción digital

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps