Back to Blog

#8: Incidente de SushiSwap: Un Torpe Intento de Rescate Desencadena una Serie de Ataques Imitadores

Code Auditing
February 18, 2024
6 min read

El 9 de abril de 2023, SushiSwap fue víctima de un exploit debido a un Parámetro Externo No Verificado. La pérdida total fue de aproximadamente $3.3 millones.

Como protocolo líder en Ethereum con una base de usuarios sustancial, incluso los protocolos más destacados son susceptibles de introducir nuevos problemas graves durante las actualizaciones de contratos. Es un recordatorio para la comunidad DeFi de que la seguridad siempre debe ser la prioridad principal. Además, este incidente de seguridad fue desencadenado por el intento de rescate de un investigador de seguridad whitehat, lo que generó un debate considerable dentro de la comunidad. Ofrecemos una introducción concisa a este incidente, destacándolo como uno de los diez principales incidentes de seguridad de 2023.

Contexto

SushiSwap

SushiSwap, un DEX reconocido, lanzó un ataque vampiro contra Uniswap, logrando un éxito tremendo. En su punto máximo, su TVL alcanzó los $8 mil millones, y aún mantiene alrededor de $400 millones.

Aprobación

En resumen: permiso para que un contrato acceda y transfiera un token específico desde tu billetera.

Por conveniencia, muchos contratos solicitan por defecto una aprobación ilimitada. Muchos usuarios, preocupados por los riesgos de seguridad, solo depositan pequeñas cantidades en varios protocolos. Sin embargo, estos usuarios otorgan aprobación de fondos ilimitados a los protocolos. Si un protocolo se ve comprometido, todos los tokens aprobados en la cuenta podrían perderse.

La Vulnerabilidad

Parámetro Externo No Verificado

La función processRoute() del contrato RouteProcessor2 permite a los usuarios un control total sobre el flujo de llamadas (parámetro route). Y en uniswapV3SwapCallback(), el parámetro from de safeTransferFrom() se decodifica desde el route proporcionado por el usuario. Como resultado, los usuarios que aprobaron el contrato RouteProcessor2 perdieron sus activos.

El Proceso del Ataque

Este incidente involucró múltiples transacciones de ataque, pero utilizaremos la primera transacción de ataque como ejemplo. Transacción: 0x43ff7e01423044cfb501b4fe9ef1386725c0ddc117dadd6e6620cb68bdeaf4f9

  1. El atacante llamó a la función processRoute() del contrato vulnerable RouteProcessor2 con un argumento route largo cuidadosamente construido.
  2. processRouteInternal() crea un InputStream basado en la ruta proporcionada por el usuario.
  3. La transacción siguió la route del atacante hasta llegar a swapUniV3(). Nótese que el pool se decodifica del stream, lo que significa que el atacante controló en qué pool realizar el swap(), estableciéndolo como el lastCalledPool.
  4. Esto llamó al contrato malicioso desplegado por el atacante, quien simplemente pasó calldata malicioso para volver a llamar a uniswapV3SwapCallback() de RouteProcessor2.
  5. uniswapV3SwapCallback() requiere la verificación de msg.sender, pero dado que el lastCalledPool ya había sido establecido como el contrato malicioso, el hacker eludió la verificación. Es importante destacar que el parámetro from de safeTransferFrom() fue decodificado del calldata construido por el atacante.
  6. Los activos de la víctima son transferidos al contrato malicioso desplegado por el atacante.

El Controvertido Rescate Whitehat

Vale la pena mencionar que un whitehat con el nombre de usuario @trust__90 identificó este problema e intentó rescatar los fondos, pero este intento de rescate causó un desastre.

  • Usar el mempool para transmitir transacciones en lugar de un RPC privado.
  • Intentar rescatar solo 100 Ether en lugar de todos los que estaban en riesgo.

Esto abrió la puerta para que los Bots MEV y otros atacantes ejecutaran múltiples transacciones de imitación, drenando efectivamente la mayor parte de los fondos. Después de estos eventos, @trust__90 enfrentó críticas y buscó defender sus acciones.

Rescate de BlockSec

En este ataque, también rescatamos 100 Ether y devolvimos los fondos a la víctima, 0xsifu.

Hasta la fecha, hemos bloqueado con éxito más de 20 hackeos del mundo real y rescatado activos por un valor superior a $14,000,000.

Recomendaciones de Seguridad

Las Actualizaciones Siempre Deben Ser Auditadas

Es un recordatorio para la comunidad DeFi de que la seguridad siempre debe ser la prioridad principal. Las auditorías no son una garantía de seguridad, pero la ausencia de una auditoría ciertamente no garantiza la seguridad.

Mitigaciones para el Problema de Aprobación

El año 2023 vio numerosos incidentes relacionados con ataques de aprobación, y aprovechamos esta oportunidad para recalcar la importancia de gestionar las aprobaciones. Una práctica de seguridad es aprobar solo las cantidades necesarias, o si la conveniencia es una prioridad, aprobar una cantidad ligeramente mayor a la necesaria.

MetaSuites de BlockSec ofrece una conveniente función de Diagnóstico de Aprobaciones. Además, herramientas como Revoke Cash pueden utilizarse para verificar regularmente el estado de las aprobaciones.

Adoptar Mecanismos de Monitoreo y Respuesta Automática

Ethereum es un bosque oscuro, y todos en la comunidad DeFi enfrentan diversos riesgos y desafíos, incluso los expertos en seguridad. En 2023, lanzamos Phalcon Security, el primer sistema de respuesta automatizada de la industria diseñado no solo para monitorear ataques, sino para bloquear activamente las amenazas en tiempo real. Las capacidades probadas en batalla de Phalcon han demostrado su efectividad al bloquear con éxito más de 20 hackeos del mundo real y rescatar activos por un valor superior a $14,000,000. Esta innovación garantiza que todas las partes interesadas puedan dormir más tranquilas por la noche, sabiendo que existen medidas proactivas para proteger sus inversiones.

Lee otros artículos de esta serie:

Best Security Auditor for Web3

Validate design, code, and business logic before launch. Aligned with the highest industry security standards.

BlockSec Audit