El ataque del préstamo flash de $ 8 millones Platypus fue posible gracias a un código que estaba en el orden incorrecto, según una autopsia realizada por el auditor Omniscia de Platypus. La empresa auditora afirma que el código problemático no existía en la versión que vieron.

Según el informe, el contrato Platypus MasterPlatypusV4 «contiene una falla fatal en su mecanismo de retiro de emergencia» que hizo que realizara «su verificación de solvencia antes de actualizar los tokens LP asociados con la posición de participación».

El informe destaca que el código de la función EmergencyWithdraw tiene todos los elementos necesarios para prevenir un ataque, pero esos elementos simplemente están escritos en el orden incorrecto, como explica Omniscia:

«El problema podría haberse evitado reordenando los operadores MasterPlatypusV4::emergencyWithdraw y realizando una verificación de solvencia después de que el monto ingresado por el usuario se estableciera en 0, lo que habría evitado que se produjera el ataque».

Omnisia admitió que auditaron una versión del contrato MasterPlatypusV4 del 21 de noviembre al 5 de diciembre de 2021. Sin embargo, esta versión «no contiene puntos de integración con un sistema externo platypusTreasure» y, por lo tanto, no contiene las líneas de código desalineadas. Desde el punto de vista de Omniscia, esto significa que los desarrolladores deben haber implementado una nueva versión del contrato en algún momento posterior a la realización de la auditoría.

LEER  El informe del BIS encuentra un progreso desigual y diferentes motivaciones en la adopción de CBDC en África

Conectado: Raydium anuncia detalles del hackeo y ofrece compensación a las víctimas

El auditor afirma que la dirección de ejecución del contrato C-Chain de Avalanche (AVAX) 0xc007f27b757a782c833c568f5851ae1dfe0e6ec7 es lo que se utilizó. Las líneas 582-584 de este contrato parecen llamar a una función llamada «isSolvent» en el contrato PlatypusTreasure, y las líneas 599-601 parecen establecer la cantidad, el factor y la recompensa del usuario en cero. Sin embargo, estas cantidades se establecen en cero después de que ya se haya llamado a la función «isSolvent».

El equipo ornitorrinco confirmado el 16 de febrero que el atacante usó una “laguna en [the] Mecanismo de Verificación de Solvencia de USP”, pero el equipo inicialmente no proporcionó más detalles. El informe de este nuevo auditor arroja más luz sobre cómo el atacante pudo haber logrado el exploit.

El equipo Platypus anunció el 16 de febrero que el ataque había sido realizado. Intentó ponerse en contacto con el hacker y recuperar los fondos a cambio de una recompensa por errores. El atacante usó préstamos rápidos para llevar a cabo el exploit, que es similar a la estrategia utilizada en el exploit Defrost Finance del 25 de diciembre.

LEER  Muchos proyectos de NFT carecen de pruebas adecuadas de contratos inteligentes, dice el fundador anónimo