Este es el tipo de error que mantiene a los equipos de protocolo despiertos por la noche.
Un exploit de 5 millones de dólares en ZKSwap, habilitado por una sola declaración dejada en el lugar equivocado.
Aquí hay un análisis profundo de cómo sucedió y cómo la monitorización en cadena podría haberlo detenido.
🧵
1/ El 9 de julio, GMX fue hackeado por 42 millones de dólares.
Pero algo más sucedió ese día y casi nadie lo notó: el puente de ZKSwap fue drenado silenciosamente por 5 millones de dólares.
¿La parte interesante? No hubo ningún exploit sofisticado involucrado. Solo una función crítica que no hizo... nada.
2/ ZKSwap es un zk-rollup construido sobre Ethereum.
Como muchos rollups, utiliza un puente para mover activos entre L1 y L2.
Como medida de seguridad, el puente incluye un "Modo Éxodo", una forma para que los usuarios recuperen fondos sin necesidad del operador.
En teoría, es una gran idea. En la práctica…
3/ El Modo Exodus permite a los usuarios demostrar manualmente que poseían tokens en el último estado L2 verificado.
Es un mecanismo de respaldo: sin confianza, autocustodia, no interactivo.
Pero la implementación de ZKSwap tenía un defecto fatal: la función responsable de verificar las pruebas no verificaba nada.
Literalmente.
4/ Aquí está el código que debería haber detenido el ataque 👇
A primera vista, parece un verdadero verificador de zk-proof.
Pero mira de cerca la primera línea: return true;
Eso es todo. No se ejecuta nada más.
5/ ¿El resultado? Cada "prueba" de retiro (sin importar cuán falsa) pasó la validación.
El contrato aceptó afirmaciones arbitrarias sobre los saldos de tokens... y los acreditó como si fueran reales.
Convirtió un mecanismo de respaldo sin confianza en un grifo desprotegido.
6/ El atacante no necesitaba exploits sofisticados: solo llamadas repetidas a exit() con datos inventados.
Eludieron las verificaciones de saldo, retiraron a través de múltiples tokens y abusaron de la lógica débil del anulador para evitar la detección.
Todo mientras el contrato decía: ✅
7/ Esto no era un caso extremo y oscuro.
Esta era la lógica central para la recuperación de activos, completamente abierta.
Y debido a que el Modo Exodus rara vez se activa, el camino roto pasó desapercibido... durante meses.
8/ Aquí está lo que debería haber activado las alarmas:
• Modo Exodus activado después de una larga inactividad
• Docenas de solicitudes de retiro ocurriendo todas a la vez
• Aumento repentino en los cambios de balancesToWithdraw
Todo esto era visible y podría haberse detenido con un monitoreo en cadena en tiempo real.
9/ ¿Entonces, cuál es la lección?
• El código de emergencia sigue siendo código de producción
• Los caminos de respaldo no ayudan si no funcionan
• La monitorización en tiempo real no es opcional, es crítica para la supervivencia
37,83 mil
422
El contenido de esta página lo proporcionan terceros. A menos que se indique lo contrario, OKX no es el autor de los artículos citados y no reclama ningún derecho de autor sobre los materiales. El contenido se proporciona únicamente con fines informativos y no representa las opiniones de OKX. No pretende ser un respaldo de ningún tipo y no debe ser considerado como un consejo de inversión o una solicitud para comprar o vender activos digitales. En la medida en que la IA generativa se utiliza para proporcionar resúmenes u otra información, dicho contenido generado por IA puede ser inexacto o incoherente. Lee el artículo vinculado para obtener más detalles e información. OKX no es responsable del contenido alojado en sitios de terceros. El holding de activos digitales, incluyendo stablecoins y NFT, implican un alto grado de riesgo y pueden fluctuar en gran medida. Debes considerar cuidadosamente si el trading o holding de activos digitales es adecuado para ti a la luz de tu situación financiera.