El pasado mes de junio, el mundo cripto experimentó una serie de incidentes de seguridad que abarcaron múltiples eslabones.
El último informe mensual de seguridad publicado por PeckShield muestra que en junio hubo 40 incidentes importantes de ataques de hackers, con una pérdida total de 75,87 millones de dólares. Lo que es más alarmante es que estos ataques no se concentraron en una sola vía de ataque, sino que abarcaron defectos de implementación de firmas en carteras, vulnerabilidades en protocolos L2, ataques a la cadena de suministro de servicios de terceros, donde múltiples líneas de defensa colapsaron sucesivamente en un mismo mes.
Cuando el riesgo de seguridad en Web3 se extiende desde un único punto de entrada hasta toda la ruta de interacción en la cadena, cada usuario se ve obligado a replantearse una pregunta: ¿están realmente seguros mis activos cripto?
一、 Más allá de la clave privada: la importancia de la implementación de firmas en el núcleo de la cartera
El incidente de seguridad en la cartera SecondFi del ecosistema Cardano en junio es el ejemplo más claro.
SecondFi es el sucesor de la cartera Yoroi del ecosistema Cardano. Entre el 21 y el 23 de junio, los atacantes transfirieron aproximadamente 16 millones de ADA desde algunas direcciones de usuarios de SecondFi, afectando a unas 374 carteras, lo que equivale a unos 2,4 millones de dólares al precio del momento. SecondFi declaró posteriormente que, mediante medidas de emergencia, había protegido otros aproximadamente 129 millones de ADA que podrían haber estado en riesgo.
Lo más peculiar de este incidente es que los usuarios afectados no entregaron activamente sus frases semilla (seed phrase) a los atacantes, el problema radicó en la implementación de firmas en el núcleo de la cartera. Según el análisis de la agencia de seguridad BlockSec, el error consistió en derivar el nonce de la firma erróneamente a partir del mensaje de transacción público, omitiendo el prefijo de nonce secreto requerido por la implementación estándar.
Esto significaba que cada vez que un usuario utilizaba la versión afectada de la cartera para firmar una transacción, los datos de firma públicos publicados en la cadena exponían información suficiente para derivar la clave privada de la dirección. Por lo tanto, el atacante no necesitaba invadir el teléfono del usuario ni obtener la frase semilla; solo necesitaba analizar los datos públicos en la cadena para potencialmente recuperar la clave privada de firma correspondiente a esa dirección.
Desde la perspectiva del usuario, la cartera seguía funcionando con normalidad; después de todo, no había ventanas emergentes filtrando la frase semilla, la contraseña no estaba siendo descifrada, y las transacciones las iniciaba efectivamente el propio usuario. Pero desde el punto de vista criptográfico, siempre que una dirección hubiera generado algunas firmas válidas con la versión afectada, los datos públicos de transacción y firma podían ayudar al atacante a derivar la clave privada de firma de esa dirección.
En el fondo, la seguridad de una cartera también depende de si genera correctamente las claves privadas, si realiza las firmas estrictamente según los estándares criptográficos, y de si este código crítico puede ser examinado y verificado externamente. Esta es también la importancia de mantener los componentes centrales de la cartera como código abierto.
Por supuesto, este es un defecto de implementación específico de una cartera y versión concretas, no un problema general de todas las carteras auto-custodiadas. Tomemos como ejemplo TokenCore de imToken, cuyo repositorio de código central está públicamente alojado en GitHub, cubriendo funciones básicas de cartera como la gestión de claves, derivación de direcciones y firma de transacciones.
Aunque el código abierto no garantiza que el código esté libre de vulnerabilidades, ni mucho menos que los usuarios puedan abandonar por completo la vigilancia, para los componentes más sensibles de la cartera, como los de criptografía y firma, el código abierto proporciona al menos una premisa importante: investigadores de seguridad, desarrolladores y la comunidad pueden examinar el código, reproducir problemas y realizar pruebas continuas, en lugar de tener que confiar en una caja negra que no se puede verificar.
Para el usuario común, este tipo de incidente también se traduce en algunos principios de seguridad más pragmáticos.
- En primer lugar, las carteras siempre deben descargarse desde el sitio web oficial o las tiendas de aplicaciones oficiales, y actualizarse a versiones seguras de manera oportuna;
- En segundo lugar, no es recomendable mantener todos los activos en la misma cartera de uso diario. Los activos de gran valor a largo plazo pueden guardarse en carteras de hardware o carteras frías independientes, aisladas de la cartera caliente ("hot wallet") que se conecta frecuentemente a DApps.
- Lo más importante: una vez que el proveedor de la cartera confirma una vulnerabilidad a nivel de generación de claves o implementación de firmas, simplemente importar la misma frase semilla en otra cartera normalmente no soluciona el problema;
porque después de importar el mismo conjunto de frases semilla en otra cartera, las direcciones y claves privadas que ya estaban expuestas no cambian. Los activos afectados necesitan transferirse a una nueva dirección que nunca haya firmado con la versión vulnerable. Para el usuario común, el enfoque más seguro suele ser seguir el procedimiento de emergencia oficial para crear un nuevo conjunto de cartera y frase semilla desde cero, y luego migrar los activos, en lugar de importar o manipular repetidamente la dirección original por su cuenta.
二、 L2 no es solo 'Ethereum más barato', sino también una compleja cadena de confianza
Además de las carteras, varios incidentes en junio también apuntaron al riesgo en los sistemas L2, cada vez más complejos.
Los días 14 y 18 de junio, dos implementaciones antiguas de Rollup relacionadas con Aztec fueron atacadas, con pérdidas combinadas de aproximadamente 4,35 millones de dólares.
Es importante aclarar que lo que fue atacado fueron implementaciones antiguas como Aztec Connect que ya estaban en estado de "legacy", lo que no equivale a que la red principal actual de Aztec Network fuera atacada. Sin embargo, los problemas expuestos en ambos incidentes son muy instructivos para todo el campo de los ZK Rollup.
En uno de los incidentes, el atacante aprovechó la inconsistencia entre la cantidad de transacciones y los datos procesados realmente, haciendo que el sistema contabilizara un depósito en el interior de la prueba, pero evitando el proceso correspondiente de deducción del saldo en L1.
El otro incidente se originó por la falta de restricciones en el circuito de prueba de conocimiento cero (ZKP). El sistema verificó una prueba formalmente válida, pero no aseguró que el árbol de estado privado utilizado por esa prueba fuera completamente consistente con la raíz de estado pública real utilizada para la liquidación en Ethereum. El atacante pudo así generar pruebas alrededor de un árbol de estado falsificado y extraer activos del contrato en L1.
Este tipo de problemas es difícil de resumir con el enfoque tradicional de "¿hay una línea de código vulnerable en el contrato?" Después de todo, una prueba de conocimiento cero puede demostrar que un proceso de cálculo cumple con reglas establecidas, pero la premisa es que las reglas en sí mismas sean correctas y completas. Si los desarrolladores olvidan restringir una variable clave, la prueba aún puede ser matemáticamente válida, pero estará demostrando un resultado que no es consistente con el estado real de liquidación.
El incidente de seguridad posterior en Taiko expuso otro tipo de riesgo en la cadena de confianza de L2.
El 22 de junio, el proceso de verificación de pruebas de Taiko basado en SGX fue explotado, causando una pérdida de aproximadamente 1,7 millones de dólares. Según el análisis de BlockSec, el atacante utilizó una clave privada de firma de enclave SGX que había sido previamente subida a un repositorio público de GitHub, y al mismo tiempo aprovechó el defecto de que el contrato de verificación en cadena no rechazaba enclaves en modo DEBUG, registrando al atacante malicioso como una instancia legítima.
Posteriormente, el atacante falsificó pruebas de estado de L2, haciendo que el contrato en Ethereum aceptara un estado de L2 que no existía, extrayendo finalmente activos de los fondos del puente. En el fondo, la causa fue que la clave utilizada para firmar el entorno de ejecución de confianza se hizo pública, y las reglas de autenticación remota no verificaron completamente los atributos del entorno de ejecución, lo que finalmente hizo que una prueba "autenticada" perdiera su significado de confianza original.
Al mismo tiempo, Base experimentó una interrupción consecutiva en la producción de bloques en su red principal del 25 al 26 de junio. Base declaró en su análisis posterior que ambas interrupciones se debieron al mismo defecto lógico en la construcción de bloques: una transacción que falló en su ejecución no limpió correctamente el estado previamente registrado, lo que provocó que las transacciones posteriores calcularan el Gas erróneamente y generaran bloques con transiciones de estado inválidas. Como otros nodos no podían aceptar ese bloque, la red finalmente dejó de avanzar. Base indicó que la integridad de la cadena no se vio comprometida durante el incidente y los fondos de los usuarios siempre estuvieron seguros.
Este no fue un caso de robo de activos o ataque externo, sino una falla técnica que afectó a la disponibilidad y capacidad de recuperación de la red. Pero desde una perspectiva de seguridad más amplia, la disponibilidad en sí misma es parte del modelo de seguridad de L2.
Porque para los usuarios, la seguridad de una cadena no solo depende de si los hackers pueden falsificar activos, sino también de si los bloques pueden producirse continuamente, si los puentes inter-cadena funcionan correctamente, si los nodos pueden recuperarse rápidamente, y de si los usuarios tienen una ruta de salida viable cuando el sistema sufre una falla.
Por lo tanto, los usuarios al utilizar L2 tampoco deberían solo comparar comisiones y expectativas de airdrops. Para L2 de menor escala, recién lanzados o con mecanismos de seguridad aún en evolución rápida, se debe evitar almacenar a largo plazo grandes cantidades de activos que superen las necesidades de uso real. Antes de hacer cross-chain, se debe confirmar que se está utilizando el puente oficial y entender los tiempos de retiro, mecanismos de pausa y formas de salida de emergencia. Si se encuentra con una red que deja de producir bloques, anomalías en el cross-chain o advertencias de seguridad oficiales, no se deben enviar transacciones repetidamente ni continuar transfiriendo activos a través del puente.
Una práctica más segura es gestionar de forma separada activos con diferentes usos y diferentes niveles de riesgo, en lugar de concentrar toda la liquidez en una misma L2, un mismo puente cross-chain o un mismo mecanismo de salida.
三、 El contrato no fue hackeado, pero los servicios de terceros también pueden llevar el ataque a los usuarios
Si los problemas de carteras y L2 aún ocurren en componentes técnicos relativamente básicos, el incidente de Polymarket demuestra que el front-end web, lo más cercano al usuario, también puede convertirse en una puerta de entrada para los fondos.
El 25 de junio, Polymarket informó que un proveedor de servicios de terceros que utilizaban había sido comprometido, y los atacantes aprovecharon esto para inyectar un script malicioso en el front-end de Polymarket al que accedían algunos usuarios.
Según estadísticas de agencias de seguridad y analistas on-chain, el incidente causó la pérdida de aproximadamente 3 millones de dólares en activos de usuarios, afectando a unas 11 carteras. Los fondos robados fueron posteriormente transferidos desde Polygon a Ethereum mediante cross-chain y convertidos en aproximadamente 1893 ETH. Sin embargo, posteriormente Polymarket declaró que había eliminado la dependencia afectada y que reembolsaría completamente a los usuarios afectados.
La clave de este incidente es que los usuarios probablemente estaban accediendo al dominio correcto de Polymarket, y las divulgaciones actuales tampoco apuntan a una vulnerabilidad en el contrato inteligente central de Polymarket; el problema principal estuvo en la dependencia de front-end de terceros cargada por la página web.
Esto también es un espejo: hoy en día, la mayoría de las aplicaciones Web3 no funcionan completamente on-chain. Las páginas web que ven los usuarios, como las interfaces de intercambio, todavía dependen en gran medida de la infraestructura tradicional de Internet y de paquetes de software de terceros. Cualquiera de estas dependencias, si es atacada, puede hacer que un sitio web legítimo muestre información errónea a los usuarios, reemplace direcciones de recepción o induzca a la cartera a firmar transacciones maliciosas.
Por lo tanto, "la URL es real" no equivale necesariamente a "todo el código cargado en este momento es seguro", y "el contrato está auditado" tampoco significa que toda la ruta de interacción entre el usuario y el contrato esté libre de riesgos. Frente a este tipo de ataques de front-end y cadena de suministro, es difícil para el usuario común verificar de forma independiente cada fragmento de código cargado por la página web, pero aún puede limitar las pérdidas potenciales reduciendo los permisos de interacción única:
- Utilizar una cartera independiente para interactuar con DApps: La cartera de ahorro a largo plazo no debe conectarse directamente a varios sitios de DeFi, NFT, mercados de predicción o airdrops. La cartera de interacción diaria solo debe contener fondos para uso reciente, de modo que incluso si hay problemas con el front-end o las autorizaciones, el alcance del impacto sea relativamente limitado;
- Prestar atención a la operación real antes de firmar, no solo al botón de la página web: Que la página web diga "Iniciar sesión", "Reclamar" o "Confirmar pedido" no significa que la firma que aparece en la cartera sea para lo mismo;
- Si la página web muestra anomalías, no depender de la inercia para continuar operando: Si la página de repente solicita volver a importar la frase semilla, descargar un plugin adicional, o si el contenido de la transacción mostrado no coincide con la descripción de la página web, se debe pausar la interacción, confirmar la situación a través de múltiples canales oficiales del proyecto, y revisar o revocar autorizaciones históricas que ya no se utilicen;
Desde la perspectiva de los productos de cartera, esto también significa que el rol que asumen las carteras está cambiando.
No debería ser solo una herramienta para guardar claves privadas y mostrar ventanas de firma, sino que también necesita, en la medida de lo posible, ayudar a los usuarios a comprender la intención de la transacción, identificar autorizaciones anómalas, mostrar cambios en los activos y proporcionar advertencias suficientemente claras antes de que ocurran interacciones de alto riesgo.
Pero la cartera tampoco puede eliminar todos los riesgos por el usuario. Un modelo de seguridad más realista es que la cartera, el protocolo, L2, los proveedores de servicios de terceros y los usuarios trabajen juntos para reducir la superficie de ataque, en lugar de trasladar toda la responsabilidad a una sola parte.
Para terminar
En el pasado, se solía decir que quien posee la clave privada posee los activos on-chain.
Esta afirmación sigue siendo cierta, pero no cubre todo el proceso que va desde la "intención de realizar una transacción" hasta la "liquidación final on-chain" de los activos del usuario. La seguridad en Web3 hoy en día ya no es solo proteger un conjunto de palabras semilla, sino proteger toda la ruta, desde la generación de claves por la cartera, la visualización de la transacción, la ejecución de la firma, hasta la verificación por la red y la liquidación final.
Por supuesto, esto no significa que los usuarios deban alejarse de todas las interacciones on-chain. Para los usuarios, los hábitos de seguridad realmente efectivos implican separar la gestión según el uso de los activos, el nivel de riesgo y el escenario de interacción: los activos a largo plazo requieren aislamiento, las interacciones diarias con montos pequeños, DApps desconocidas con autorizaciones bajas, y operaciones de alto riesgo con múltiples verificaciones.
Después de todo, cuando el riesgo de seguridad se expande desde un punto hasta una cadena, la defensa del usuario también debe evolucionar desde proteger bien la clave privada hasta adoptar un conjunto completo de hábitos.
Un mensaje para reflexionar juntos.
