El 25 de enero de 2026, detectamos una serie de transacciones sospechosas
dirigidas a contratos víctima desplegados por SwapNet y Aperture Finance en Ethereum, Arbitrum, Base y BSC, con pérdidas totales que superan los 17 millones de dólares. A grandes rasgos, la causa raíz de ambos incidentes es sencilla y ya fue descrita en nuestras alertas iniciales [1, 2]:
los contratos víctima exponen una capacidad de llamada arbitraria debido a una validación de entrada insuficiente, lo que permite a los atacantes abusar de las aprobaciones de tokens existentes e invocar transferFrom para drenar activos.
Sin embargo, ambos conjuntos de contratos víctima son de código cerrado y, una vez descompilados, se expanden en miles de líneas de código con una lógica de ramificación profundamente anidada y compleja, lo que aumenta significativamente la dificultad del análisis. Además, los informes post-mortem publicados posteriormente por los proyectos afectados [3, 4] se centraron principalmente en la remediación y recuperación, con escasa discusión sobre los detalles técnicos subyacentes. Como resultado, varias preguntas importantes siguen sin respuesta, incluyendo cómo se construyeron los caminos de llamada vulnerables y por qué las comprobaciones existentes no lograron prevenir la explotación.
En este informe, proporcionamos un análisis técnico más detallado basado en bytecode descompilado y trazas de ejecución on-chain. Si bien la falta de código fuente limita la visibilidad, el análisis a nivel de bytecode es suficiente para reconstruir la lógica vulnerable y revela varias observaciones interesantes sobre el diseño del contrato que no son inmediatamente evidentes a partir de las alertas de alto nivel.
Comenzamos con un análisis profundo del incidente de SwapNet, seguido de un análisis detallado del incidente de Aperture Finance.
Incidente de SwapNet
Antecedentes
SwapNet [5] es un agregador DEX diseñado para encontrar rutas de intercambio óptimas mediante la agregación de liquidez de múltiples fuentes on-chain, incluyendo AMMs y creadores de mercado privados. El protocolo también permite a los usuarios especificar routers o pools personalizados al ejecutar intercambios, ofreciendo flexibilidad adicional.
Análisis de Causa Raíz
Este incidente surge de una validación insuficiente de las entradas proporcionadas por el usuario, lo que permite a un atacante activar llamadas transferFrom() con parámetros arbitrarios. Como resultado, los activos que habían sido previamente aprobados para los contratos víctima (por ejemplo, 0x616000e384Ef1C2B52f5f3A88D57a3B64F23757e) podrían transferirse al atacante.
Según el bytecode descompilado, la función 0x87395540() parece carecer de una validación adecuada en las entradas críticas. Al reemplazar el router o la dirección del pool esperados con una dirección de token (por ejemplo, USDC), el contrato trata incorrectamente el token como un objetivo de ejecución válido. Esto conduce a la ejecución de una llamada de bajo nivel con calldata controlado por el atacante.
En consecuencia, el contrato víctima realiza llamadas de la forma: approvedAsset.transferFrom(victim, attacker, amount), lo que permite al atacante sifunar todos los activos aprobados.
Flujo del Ataque
Se observaron múltiples ataques contra SwapNet. Aquí usamos la transacción de Base 0xc15df1d131e98d24aa0f107a67e33e66cf2ea27903338cc437a3665b6404dd57 como ejemplo.
El atacante simplemente invocó la función 0x87395540() del contrato víctima con entradas maliciosas. Esta invocación consta de dos pasos principales.
- Una variable interna clave (por ejemplo,
v51) se estableció en USDC, eludiendo la lógica de enrutamiento prevista.
- Se ejecutó una llamada de bajo nivel usando calldata controlado por el atacante, lo que resultó en la invocación de
USDC.transferFrom()y el drenaje de todos los USDC aprobados.
Resumen de Pérdidas, Transacciones y Contratos Afectados
El incidente de SwapNet causó una pérdida estimada de ~$13.41M en múltiples cadenas. Las tablas a continuación resumen las transacciones clave de explotación y las direcciones de los contratos víctima involucrados.
Incidente de Aperture Finance
Antecedentes
Aperture Finance [6] es un protocolo DeFi que gestiona posiciones de liquidez concentrada, como LPs de Uniswap V3, en nombre de los usuarios. Sus contratos de código cerrado (por ejemplo, 0xD83d960deBEC397fB149b51F8F37DD3B5CFA8913) permiten a los usuarios acuñar y gestionar posiciones de Uniswap V3 usando tokens nativos.
Flujo de Trabajo Previsto para Acuñar Posiciones en UniswapV3
Al acuñar posiciones de Uniswap V3 a través de la función 0x67b34120(), el contrato sigue un flujo de trabajo previsto de tres pasos:
-
Envolver tokens nativos
-
Intercambiar tokens nativos a través de la función interna
0x1d33() -
Acuñar posiciones de UniswapV3
El problema surge en el Paso 2: 0x1d33() realiza un intercambio personalizado a través de una llamada de bajo nivel, donde los parámetros críticos (por ejemplo, el objetivo de la llamada y el calldata) parecen estar controlados por el usuario y no estar suficientemente validados, lo que permite llamadas externas no deseadas. Se proporcionan más detalles en las siguientes secciones.
Análisis de Causa Raíz
Similar al caso de SwapNet, el incidente de Aperture Finance es causado por una validación insuficiente de entradas en llamadas de bajo nivel. Cuando se invoca 0x67b34120(), la función interna 0x1d33() ejecuta una llamada de bajo nivel usando calldata proporcionado por el usuario, sin imponer restricciones estrictas sobre el objetivo de la llamada o el selector de función.
Como se muestra en la figura a continuación, el calldata utilizado para activar la llamada de bajo nivel se basa puramente en las entradas del atacante.
Esto permite a los atacantes construir calldata malicioso que resulta en: approvedToken.transferFrom(victim, attacker, amount) ejecutado en el contexto del contrato víctima. Como resultado, no solo los tokens ERC20 sino también los NFTs de posición de Uniswap V3 aprobados pueden ser drenados.
Flujo del Ataque
Se observaron múltiples ataques contra Aperture Finance. En esta sección, usamos la transacción de Ethereum 0x8f28a7f604f1b3890c2275eec54cd7deb40935183a856074c0a06e4b5f72f25a como ejemplo representativo.
-
El atacante creó un contrato de ataque
0x5c92884dFE0795db5ee095E68414d6aaBf398130. -
El contrato de ataque invocó la función
0x67b34120()con entradas maliciosas y100wei ETHs (es decir,msg.value==100).
- a) Los ETHs nativos fueron envueltos en WETHs a través de la función
WETH.deposit().
- b) La función interna
0x1d33()fue invocada para realizar una llamada de bajo nivel. En este paso, se invoca una llamada deWBTC.transferFrom(victim, attacker, amount)en el contexto del contrato víctima, permitiendo al atacante drenar los tokens aprobados. Vale la pena señalar que se superó una verificación de saldo al final de la función0x1d33(). Específicamente, la función0x1d33()comparó los cambios de saldo con un valor de salida del intercambio (es decir,varg2.word2) especificado también por el atacante. Como resultado, se ejecutaron exitosamente sin recibir nada.
- Por último, la función
NonfungiblePositionManager.mint()fue invocada para acuñar una posición para el atacante usando100wei deWETH.
Hallazgos Interesantes
Al comparar transacciones de acuñación normales y anómalas, observamos que ambas aprobaron tokens al mismo gastador (por ejemplo, OKX DEX: TokenApprove) pero especificaron diferentes direcciones de router (es decir, DexRouter y WBTC). Esto sugiere que el contrato puede imponer validación sobre el gastador de la aprobación mientras no valida el objetivo de ejecución real, dejando una brecha crítica explotable a través de llamadas arbitrarias.
Transacción normal: https://app.blocksec.com/phalcon/explorer/tx/eth/0xc823b703c716fa9078e1d71714b734557bd540ddd1e41590dd73da7c5aba0200
Transacción anómala: https://app.blocksec.com/phalcon/explorer/tx/eth/0x8f28a7f604f1b3890c2275eec54cd7deb40935183a856074c0a06e4b5f72f25a
Resumen de Pérdidas, Transacciones y Contratos Afectados
El incidente de Aperture Finance resultó en una pérdida total estimada de ~$3.67M en múltiples cadenas. Las tablas a continuación resumen las transacciones clave de explotación y las direcciones de los contratos víctima asociados.
Conclusión
Aunque los incidentes de SwapNet y Aperture Finance afectaron a diferentes protocolos y cadenas, el problema subyacente en ambos casos no es complejo: llamadas de bajo nivel controladas por el usuario combinadas con una validación de entrada insuficiente en contratos que mantienen aprobaciones de tokens. Estos incidentes sirven como recordatorio de que la flexibilidad en el diseño de contratos debe equilibrarse cuidadosamente con restricciones estrictas en las llamadas, especialmente en sistemas de código cerrado donde la revisión externa es limitada.
Referencias
[1] https://x.com/Phalcon_xyz/status/2015614087443697738
[2] https://x.com/Phalcon_xyz/status/2015624519898234997
[3] https://meta.matcha.xyz/SwapNet-Incident-Post-Mortem
[4] https://x.com/ApertureFinance/status/2015938720453820752
[6] https://x.com/ApertureFinance
Acerca de BlockSec
BlockSec es un proveedor integral de seguridad blockchain y cumplimiento de criptomonedas. Desarrollamos productos y servicios que ayudan a los clientes a realizar auditorías de código (incluyendo contratos inteligentes, blockchain y billeteras), interceptar ataques en tiempo real, analizar incidentes, rastrear fondos ilícitos y cumplir con las obligaciones AML/CFT, a lo largo de todo el ciclo de vida de los protocolos y plataformas.
BlockSec ha publicado múltiples artículos de seguridad blockchain en conferencias de prestigio, ha reportado varios ataques de día cero en aplicaciones DeFi, ha bloqueado múltiples hackeos para rescatar más de 20 millones de dólares y ha asegurado miles de millones en criptomonedas.
-
Sitio web oficial: https://blocksec.com/
-
Cuenta oficial de Twitter: https://twitter.com/BlockSecTeam
