¿Cómo juzgar si un llamado "HACK" que le sucedió a un proyecto Crypto o Blockchain es legítimo o si es solo un mecanismo para ocultar un RUG?

Obviamente, después de lo que sucedió con MtGox o QuadrigaCX o casos similares en los que los fundadores afirmaron que perdieron las claves privadas que contenían la mayoría de los activos digitales de sus intercambios mientras desaparecían o se encontraban muertos más tarde, las personas en la criptoesfera sospechan cada vez más cuando escuchan sobre un piratear un proyecto, y el primer pensamiento que viene a la mente es que los fundadores básicamente vaciaron el fondo y se fueron con él, eso es lo que comúnmente se llama un RUG.

Este probablemente ha sido el caso en muchos proyectos, pero no necesariamente en todos, por lo que hoy estamos viendo un caso que creemos que es un verdadero truco debido a la naturaleza de la situación.

Creemos que es un caso interesante de analizar porque ayudará a comprender mejor la importancia de la seguridad y las auditorías en proyectos relacionados con contratos inteligentes o blockchain en general.

Analizaremos objetivamente el drama que sucedió con el proyecto RING Financial, un token lanzado en BSC (Binance Blockchain).

Antes de llegar al truco, primero resumiremos el proyecto y su situación antes:

RING Financial antes del hackeo

RING Financial fue un proyecto de DeFi con el objetivo de hacer que DeFi fuera más accesible para la comunidad de criptomonedas y DeFi. Un proyecto ambicioso que quería crear un protocolo de producción de nodos que sería gobernado por titulares de nodos y asignaría liquidez en más de 300 protocolos a la vez. El objetivo era obtener acceso a todos los protocolos a través de un nodo RING y a través de RING Dapp.

Estos protocolos fueron verificados por el equipo y luego la comunidad votaría sobre dónde asignarlos. El mismo concepto de votación que tendrías en un DAO que hizo que RING fuera bastante atractivo.

RING Financial también simplificó bastante el proceso de investigación y el proceso de implementación para un solo titular de nodo. Una Dapp para acceder a todas las demás Dapps, por lo que solo necesitaría una interfaz en lugar de 300 diferentes con sus propios accesos y nodos.

Finalmente, el objetivo de RING Financial era reducir las tarifas por la implementación en diferentes protocolos, con el volumen se reducen las tarifas de transacción para los titulares individuales, que era uno de los principales puntos de venta del proyecto. Un proyecto con estilo y ambición para hacer las cosas más fáciles para la comunidad y aún más convencional para aquellos que no conocen Defi.

Sin embargo, el estilo y la ambición no siempre son suficientes y se necesita experiencia y conocimiento que en mercados nuevos e inmaduros es un hallazgo raro y es por eso que RING Financial no pudo cumplir su promesa por completo.

Entonces, ¿qué sucedió realmente con RING Financial? ¿Y por qué fue hackeado? Gracias a blockchain tenemos toda la evidencia forense necesaria para profundizar en esto y ver dónde estaban las vulnerabilidades y por qué. RING Financial no fue una estafa.

El RING Financial HACK ocurrió el 5 de diciembre de 2021 entre las 2:01 p. m. y las 2:06 p. m. UTC.

¡Sí, todo sucedió literalmente en solo 5 minutos! Gracias al escáner de cadena de bloques por estos detalles, por cierto, le proporcionamos justo debajo de los enlaces de las transacciones relacionadas con el HACK, así como la dirección del contrato para aquellos que quieran buscar con más detalle.

Aquí está el resumen que explica la falla que el atacante ha explotado:

Debe comprender que el contrato inteligente de RING Financial estaba compuesto por varias partes, una para el token y todos los datos relacionados con él y otra para todo lo relacionado con la contabilidad de nodos y recompensas. La parte del token tenía una seguridad para que solo el administrador del contrato pueda modificar los datos importantes de este, para mostrarle un código, aquí hay un encabezado de una función del contrato que está protegida a través del atributo "onlyOwner". que establece que la función sólo puede ser ejecutada por el administrador:

Una función que no tiene propietario único El atributo (o atributo equivalente para proteger el acceso de la función) puede ser ejecutado literalmente por cualquier persona.

Ahora, ¿adivina qué? Las funciones en la parte de Nodos y Recompensas no tenían este atributo, como puede ver al mirar los nombres de las funciones a continuación (el propietario único falta el atributo):

Y como puede imaginar, un pirata informático explotó y estafó esta falla para obtener una cantidad exponencial de recompensas en RING, y luego las arrojó al fondo de liquidez y lo vació casi violentamente en unos minutos. Por lo tanto, perpetró sus estafas.

Ahora probablemente te estés haciendo dos preguntas:

¿Cómo podrían los desarrolladores dejar tal laguna?

Después de hablar con los desarrolladores de Solidity (lenguaje utilizado para codificar contratos inteligentes en Ethereum), este es un error relacionado con la herencia de roles entre dos contratos inteligentes, la herencia es una noción de lenguaje de programación y para no causarle un dolor de cabeza, le se quedará en palabras simples: Básicamente, es muy probable que la persona que codificó el contrato pensara que las funciones de la parte del Nodo heredaron los roles de seguridad de las funciones de la parte del Token, pero desafortunadamente este no es el caso en Solidity, y es necesario redefinir los roles de cada función de cada contrato, cualquiera que sea su vinculación. Así que nuestra conclusión sobre este punto es que el desarrollador no era un experto y que probablemente publicó el contrato SIN tomarse el tiempo de leerlo de nuevo, probablemente con prisas.

¿Cómo sabes que no es el propio desarrollador quien dejó esta falla a propósito y no fue una estafa?

Muy buena objeción y es fácil asumir una estafa cuando no estás seguro de cómo contratos inteligentes funciona, pero en realidad es muy fácil asumir la inocencia del desarrollador, porque publicó y verificó públicamente el código completo del contrato inteligente en BSCSCAN.COM (el escáner más popular de Binance Blockchain), el 19 de noviembre de 2021, que es decir, más de dos semanas antes de que ocurriera el RING Financial HACK. Y como se explicó antes, la falla estaba escrita en NEGRO SOBRE BLANCO en el contrato, y cualquier desarrollador experimentado lo habría notado y reaccionado, pero desafortunadamente, el primero en no tener piedad en absoluto. Por lo tanto, es obvio que el desarrollador no estaba al tanto de esta falla porque no se habría arriesgado a dejar que nadie matara el proyecto de RING Financial en ningún momento.

Para volver a la continuación de RING Financial HACK, el desarrollador se dio cuenta de su error y simplemente congeló el contrato para detener cualquier distribución de recompensas para que el atacante no vacíe el grupo por completo. Luego volvió a implementar un contrato de Nodo, esta vez con el atributo de seguridad "onlyOwner". Este nuevo contrato de Nodo pudo manejar correctamente la nueva distribución de recompensas, excepto que fue demasiado tarde, porque como resultado del HACK se había perdido toda la confianza en el proyecto y el equipo, y la presión de venta mató y acabó con el token y el proyecto.

Para concluir, elegimos esta historia porque muestra dos cosas importantes sobre los contratos inteligentes y los proyectos criptográficos: nunca codifique un contrato a toda prisa y siempre comuníquese con las firmas de auditoría, porque una vez que ocurre el truco, es demasiado tarde para salvar el bote, y El proyecto RING Financial es un buen ejemplo, además, según su comunicación, se han puesto en contacto con firmas de auditoría para este segundo contrato de Nodo y no lo publicaron públicamente en BSCSCAN hasta que estuvieron seguros de su seguridad. Pero como se dijo antes, era demasiado tarde para RING Financial y el daño era irreversible.

Aquí están todos los enlaces del escáner y las direcciones del contrato:

monedero ejecutando transacción para hackear exploit: 0xfe58c9e2ecb95757be6f4bca33162cfa346cc34f

 Ring smart-contract address: 0x521ef54063148e5f15f18b9631426175cee23de2

Ring reward pool address: 0xa46cc87eca075c5ae387b86867aa3ee4cb397372

 Exploit de pirateo de transacciones:

 TRX 1

    link: https://bscscan.com/tx/0x596d38494ea5ae640b2a556a7029692928f15713d22b5948477c4eb4a92cf68e

TRX 2

    link: https://bscscan.com/tx/0xfc890c855709bb6aeb5177ee31e08751561344402a88af13e7dfd02b9a2f6003

TRX 3

    link: https://bscscan.com/tx/0x35c2f1ed9c5ce13a714af6c0dcbbce8fe720f7d6212232b6dd3657d8799a10f1

• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• Platoblockchain. Inteligencia del Metaverso Web3. Conocimiento amplificado. Accede Aquí.
• Fuente: https://www.fintechnews.org/how-to-judge-if-a-so-called-hack-that-happened-to-a-crypto-or-blockchain-project-is-legit-or-if-its-just-a-mechanism-to-hide-a-rug/