Este es el tipo de error que mantiene despiertos a los equipos de protocolo 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 una inmersión profunda en cómo sucedió y cómo el monitoreo en cadena podría haberlo detenido.
🧵
1/ El 9 de julio, GMX fue hackeada por 42 millones de dólares.
Pero algo más sucedió ese día y casi nadie se dio cuenta: el puente de ZKSwap se drenó silenciosamente por $ 5 millones.
¿La parte interesante? No hubo ninguna hazaña sofisticada involucrada. Solo una función crítica que lo hizo... nada.
2/ ZKSwap es un zk-rollup construido sobre Ethereum.
Al igual que muchos rollups, utiliza un puente para mover activos entre L1 y L2.
Como salvaguarda, el puente incluye un "Modo Éxodo", una forma para que los usuarios reclamen fondos sin necesidad del operador.
En teoría, esa 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 alternativo: sin confianza, autocustodiado, 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 a prueba de zk.
Pero mire de cerca la primera línea: return true;
Eso es todo. Nada más corre.
5/ ¿El resultado? Cada "prueba" de retiro (sin importar cuán falsa sea) pasó la validación.
El contrato aceptaba reclamos arbitrarios sobre saldos de tokens... y los acreditaron como si fueran reales.
Convirtió un mecanismo de respaldo sin confianza en un grifo sin protección.
6/ El atacante no necesitaba exploits sofisticados, solo llamadas repetidas a exit() con datos inventados.
Pasaron por alto las comprobaciones de saldo, se retiraron a través de múltiples tokens y abusaron de la lógica del anulador débil para evitar la detección.
Todo mientras el contrato decía: ✅
7/ Este no fue un caso extremo oscuro.
Esta fue la lógica central para la recuperación de activos, que se dejó completamente abierta.
Y debido a que el modo Éxodo rara vez se activa, el camino roto pasó desapercibido ... durante meses.
8/ Esto es lo que debería haber activado las alarmas:
• El modo Éxodo se activa después de una larga inactividad
• Docenas de llamadas de retiro que ocurren a la vez
• Aumento repentino en los saldos Cambios de ToWithdraw
Todo era visible y podría haberse detenido con el monitoreo en cadena en tiempo real.
9/ Entonces, ¿cuál es la lección?
• El código de emergencia sigue siendo el código de producción
• Las rutas de reserva no ayudan si no funcionan
• El monitoreo en tiempo real no es opcional, es crítico para la supervivencia
37.33 k
420
El contenido al que estás accediendo se ofrece por terceros. A menos que se indique lo contrario, OKX no es autor de la información y no reclama ningún derecho de autor sobre los materiales. El contenido solo se proporciona 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 enlazado para más detalles e información. OKX no es responsable del contenido alojado en sitios de terceros. Los holdings de activos digitales, incluidos stablecoins y NFT, suponen un alto nivel de riesgo y pueden fluctuar mucho. Debes considerar cuidadosamente si el trading o holding de activos digitales es adecuado para ti según tu situación financiera.