Resumen
Platypus Finance es un protocolo AMM en la blockchain de Avalanche. Ha sido atacado tres veces, de la siguiente manera:
- El 17 de febrero de 2023, sufrió un hackeo debido a una verificación de solvencia incorrecta, lo que resultó en una pérdida total de aproximadamente $9.05M. De esto, $2.4M fueron rescatados con la ayuda de BlockSec. Aproximadamente 380K tokens quedaron atrapados en el contrato de Aave y luego fueron devueltos.
- El 12 de julio de 2023, fue hackeado, con alrededor de $50K perdidos debido a ignorar la diferencia de precio entre las stablecoins.
- El 12 de octubre de 2023, sufrió ataques de manipulación de precios, con alrededor de $2.2M perdidos. Después de negociar con el atacante, el 90% de los fondos robados fueron devueltos.
El proyecto tuvo la suerte de haber sobrevivido todos esos ataques. Nuestro análisis de estos tres exploits muestra que los fallos lógicos podrían haberse evitado si se hubiera utilizado una auditoría cuidadosa o medidas de seguridad más activas.
Ataque Uno
Para entender este incidente de seguridad, es necesario comprender el flujo de trabajo de varios contratos inteligentes. El proceso general es el siguiente:
- Un usuario puede depositar un token en un pool para convertirse en LP y recibir un token LP.
- El token LP puede ser apostado en MasterPlatypus para recibir recompensas. El token LP será transferido al contrato MasterPlatypus durante este proceso.
- El token LP puede usarse como garantía para pedir prestado otros activos y mejorar la eficiencia de los activos.
La siguiente figura muestra las interacciones.
Análisis de Vulnerabilidad
La vulnerabilidad existe en una función llamada emergencyWithdraw dentro del contrato MasterPlatypus. En emergencias, esta función debe usarse para retirar los tokens LP apostados en el contrato MasterPlatypus. En esta función, el contrato verifica si el usuario es Solvent para permitir el retiro. La lógica verifica si los usuarios tienen alguna deuda incobrable (es decir, si la garantía puede usarse para pagar la deuda). Si no, los usuarios pueden retirar los tokens LP apostados.
Sin embargo, esta lógica es defectuosa. Que el usuario sea Solvent solo significa que la garantía del usuario puede pagar su deuda. Sin embargo, NO verifica si el usuario sigue siendo Solvente después de retirar de emergencia los tokens apostados. Un atacante puede aprovechar este fallo para pedir prestados los activos y luego retirar de emergencia los tokens LP apostados también (sin pagar las deudas). Consulte el análisis detallado en el Blog de Immunefi.
Análisis del Ataque
Usamos una transacción de ataque como ejemplo para mostrar todo el proceso del ataque.
Paso 1: Pedir prestado 44 millones de USDC en Flashloan de AAVE
Paso 2: Depositar 44 millones de USDC en el pool para obtener LP-USDC
Paso 3: Depositar LP-USDC en MasterPlatypus
Paso 4: Usar LP-USDC como garantía para pedir prestado USP
Paso 5: Ejecutar la función emergencyWithdraw para lanzar el ataque
El atacante obtiene el LP-USDC sin pagar la deuda de USP.
Paso 6: Retirar LP-USDC del pool para obtener USDC
Paso 7: Vender USP para obtener ganancias
Sin embargo, las ganancias quedan dentro del contrato del atacante. De hecho, el atacante podría haber configurado una nueva dirección de recepción para el intercambio y obtener las ganancias.
El Rescate de BlockSec
Descubrimos que el atacante dejó las ganancias dentro del contrato del atacante. Además, no hay lógica dentro del contrato del atacante para retirar los activos. Sin embargo, encontramos una vulnerabilidad en el contrato del atacante, que puede aprovecharse para hackear de vuelta y retirar parte de los activos dentro del contrato.
Específicamente, existe un control de acceso de la función de callback del flashloan, lo que significa que cualquiera puede invocar esta función de callback. Esta es también la causa raíz de que muchos bots MEV sean atacados.
Además, dentro de la función de callback, el contrato del atacante aprueba el token USDC al contrato del pool de Platypus Finance. ¡Y este contrato de pool es actualizable!
Combinando los dos puntos anteriores, podemos rescatar el USDC dentro del contrato del atacante:
- Actualizar el contrato del pool de Platypus Finance para incluir una lógica que retire el USDC dentro del contrato
- Invocar el callback del contrato del atacante para aprobar el USDC al contrato del pool
- El contrato del pool puede reemplazar cualquier función (que será ejecutada por el contrato del atacante) para transferir el USDC desde el contrato del atacante (ya que el contrato del atacante aprueba el USDC al contrato del pool).
Aquí está la transacción para rescatar 2.4 millones de USDC.
Los Otros Dos Ataques
Por favor, consulte los siguientes enlaces para obtener más detalles sobre los otros dos ataques.
-
Ataque-II: 11-julio-2023, El protocolo asume que la proporción entre USDC y USDT es 1:1, lo que se desvía de las fluctuaciones del mercado, resultando en una lógica de retiro defectuosa. El enlace a una transacción de ataque. Hay un par de ellas.
-
Ataque-III: 12-octubre-2023, debido a la manipulación de
cashyliabilityque afectó el precio de intercambio. [La primera transacción de ataque | La segunda transacción de ataque]
Resumen
Los tres ataques explotaron diferentes vulnerabilidades en el protocolo. Aunque otros proveedores han auditado el protocolo, el atacante aún encontró la brecha y explotó exitosamente el protocolo. Afortunadamente, algunos activos fueron rescatados, pero no podemos esperar tener siempre suerte. Se deben adoptar más medidas de seguridad incluyendo monitoreo de ataques y respuesta automática para proteger el protocolo y los activos de los usuarios.
Lea otros artículos de esta serie:
- Introducción: Los Diez Principales Incidentes de Seguridad "Increíbles" en 2023
- #1: Cosechando Bots MEV Explotando Vulnerabilidades en Flashbots Relay
- #2: Incidente de Euler Finance: El Mayor Hackeo de 2023
- #3: Incidente de KyberSwap: Explotación Magistral de Errores de Redondeo con Cálculos Extraordinariamente Sutiles
- #4: Incidente de Curve: Un Error del Compilador Produce Bytecode Defectuoso a partir de Código Fuente Inocente
- #6: Incidente de Hundred Finance: Catalizando la Ola de Exploits Relacionados con la Precisión en Protocolos Bifurcados Vulnerables
- #7: Incidente de ParaSpace: Una Carrera Contra el Tiempo para Frustrar el Ataque Más Crítico de la Industria hasta la Fecha
- #8: Incidente de SushiSwap: Un Torpe Intento de Rescate Conduce a una Serie de Ataques Imitadores
- #9: Bot MEV 0xd61492: De Depredador a Presa en un Exploit Ingenioso
- #10: Incidente de ThirdWeb: La Incompatibilidad Entre Módulos de Confianza Expone una Vulnerabilidad
