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 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 exploiter, se devolvió el 90% de los fondos robados.
El proyecto tiene la suerte de haber sobrevivido a todos esos ataques. Nuestro análisis de estos tres exploits muestra que las fallas lógicas podrían haberse evitado si se hubiera utilizado una auditoría cuidadosa o medidas de seguridad más activas.
Ataque Uno
Para comprender este incidente de seguridad, es necesario entender 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 se puede hacer staking en MasterPlatypus para recibir recompensas. El token LP se transferirá al contrato MasterPlatypus durante este proceso.
- El token LP se puede usar como garantía para pedir prestados otros activos y mejorar la eficiencia de los activos.
La siguiente figura muestra las interacciones.
Análisis de la vulnerabilidad
La vulnerabilidad existe en una función llamada emergencyWithdraw dentro del contrato MasterPlatypus. En emergencias, esta función debería usarse para retirar los tokens LP en staking en el contrato MasterPlatypus. En esta función, el contrato verifica si el usuario es Solvent para permitir el retiro. La lógica comprueba si los usuarios tienen alguna deuda incobrable (es decir, si la garantía puede usarse para pagar la deuda). Si no la tienen, los usuarios pueden retirar los tokens LP en staking.
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 Solvent después de retirar de emergencia los tokens en staking. Un atacante puede aprovechar esta falla para pedir prestados los activos y luego retirar de emergencia los tokens LP en staking también (sin pagar las deudas). Vea 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 un préstamo flash de 44 millones de USDC 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 de ataque. De hecho, el atacante puede configurar una nueva dirección de recepción para el swap y así obtener las ganancias.
El rescate de BlockSec
Descubrimos que el atacante dejó las ganancias dentro del contrato de ataque. Además, no hay lógica dentro del contrato de ataque para retirar los activos. Sin embargo, encontramos una vulnerabilidad en el contrato de ataque, que se puede aprovechar para hacer un "hack back" y retirar parte de los activos dentro del contrato.
Específicamente, existe un control de acceso en 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 de ataque mediante:
- Actualizar el contrato del pool de Platypus finance para incluir una lógica que permita retirar el USDC dentro del contrato
- Invocar el callback del contrato de ataque para aprobar el USDC al contrato del pool
- El contrato del pool puede reemplazar cualquier función (que será ejecutada por el contrato de ataque) para transferir el USDC desde el contrato de ataque (ya que el contrato de ataque aprueba el USDC al contrato del pool).
Aquí está la transacción para rescatar 2.4 millones de USDC.
Otros dos ataques
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 de 1:1, lo que se desvía de las fluctuaciones del mercado, lo que resulta en una lógica de retiro defectuosa. El enlace a una transacción de ataque. Hay varias más.
-
Ataque-III: 12-octubre-2023, debido a la manipulación de
cashyliability, lo que afectó el precio de swap. [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ó el resquicio legal y explotó el protocolo con éxito. Afortunadamente, se rescataron algunos activos, pero no podemos esperar tener siempre suerte. Se deben adoptar más medidas de seguridad, incluyendo el monitoreo de ataques y la 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 "asombrosos" de 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 extremadamente 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 ahora
- #8: Incidente de SushiSwap: Un intento de rescate torpe 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
