Más allá de las claves privadas: desde las billeteras, L2 hasta la cadena de suministro, ¿cómo proteger los límites de seguridad de Web3?

El pasado junio, el mundo cripto experimentó una ronda de incidentes de seguridad que abarcaron múltiples eslabones.

El informe de seguridad mensual más reciente de PeckShield muestra que en junio ocurrieron 40 ataques graves de hackers, con pérdidas totales de hasta 75,87 millones de dólares. Lo que es más preocupante es que estos ataques no se concentraron en una sola ruta de ataque, sino que cubrieron defectos en la implementación de firmas de carteras, vulnerabilidades de protocolos L2 y ataques a la cadena de suministro de servicios de terceros. Múltiples líneas de defensa cayeron sucesivamente en el mismo mes.

Cuando el riesgo de seguridad de Web3 se expande desde un único punto de entrada a toda la ruta de interacción en la cadena, cada usuario se ve obligado a replantearse una pregunta: ¿mis activos cripto siguen siendo seguros?

I. Más allá de las claves privadas: la importancia de la implementación de firmas subyacente en las carteras

El incidente de seguridad ocurrido en junio en SecondFi, una cartera del ecosistema Cardano, es el ejemplo más directo.

SecondFi es la predecesora de Yoroi, la cartera del ecosistema Cardano. Entre el 21 y el 23 de junio, el atacante transfirió aproximadamente 16 millones de ADA desde algunas direcciones de usuarios de SecondFi, afectando alrededor de 374 carteras, con un valor de aproximadamente 2,4 millones de dólares según el precio en ese momento. SecondFi indicó posteriormente que, mediante medidas de emergencia, logró proteger otros aproximadamente 129 millones de ADA que podrían haber sido afectados.

Lo más particular de este incidente es que los usuarios afectados no entregaron activamente sus frases semilla al atacante; el problema radicó en la implementación de las firmas subyacente de la cartera. Según el análisis de la firma de seguridad BlockSec, se derivó erróneamente el nonce de firma a partir de mensajes de transacciones públicas, omitiendo el prefijo secreto del nonce requerido por la implementación estándar.

Esto hizo que cada vez que un usuario usaba 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 posiblemente recuperar la clave privada de firma de la dirección correspondiente.

Desde la perspectiva del usuario, la cartera seguía funcionando con normalidad, ya que la frase semilla no se filtró mediante ventanas emergentes, la contraseña no fue descifrada y la transacción fue iniciada por el propio usuario. Sin embargo, desde el punto de vista criptográfico, si la dirección del usuario había generado algunas firmas válidas a través de la versión afectada, los datos de transacciones y firmas públicas podrían ayudar al atacante a derivar la clave privada de firma de esa dirección.

En resumen, la seguridad de una cartera también depende de si las claves privadas se generan correctamente, si las firmas se realizan estrictamente según los estándares criptográficos y si ese código clave puede ser revisado y verificado externamente. Aquí radica la importancia de mantener abierto el código de los componentes centrales de la cartera.

Por supuesto, esto es un defecto de implementación de una versión específica de una cartera específica, no un problema general de todas las carteras de autocustodia. Tomando como ejemplo TokenCore de imToken, su repositorio de código central está alojado públicamente en GitHub, cubriendo funciones subyacentes de la cartera como gestión de claves, derivación de direcciones y firma de transacciones.

Aunque el código abierto no significa que el código esté libre de vulnerabilidades, ni que los usuarios puedan bajar la guardia por completo, para los componentes criptográficos y de firma más sensibles de la cartera, el código abierto al menos proporciona una premisa importante: los investigadores de seguridad, desarrolladores y la comunidad pueden revisar 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 los usuarios comunes, este tipo de incidentes también corresponden a varios principios de seguridad más prácticos.

En primer lugar, las carteras siempre deben descargarse desde el sitio web oficial o las tiendas oficiales de aplicaciones, y actualizarse a versiones seguras a tiempo.

En segundo lugar, no es aconsejable colocar todos los activos en una sola cartera de interacción diaria. Los activos grandes a largo plazo pueden almacenarse en una cartera de hardware o en una cartera fría independiente, aislada de la cartera caliente que se conecta frecuentemente a DApps.

Más importante aún, una vez que la cartera confirma oficialmente una vulnerabilidad en la generación de claves o en la implementación de firmas, simplemente importar la misma frase semilla a otra cartera generalmente no resuelve el problema.

Esto se debe a que, al importar el mismo conjunto de frases semilla a otra cartera, las direcciones y claves privadas ya expuestas no cambian. Los activos afectados deben transferirse a una nueva dirección que nunca haya firmado a través de la versión vulnerable. Para los usuarios comunes, el enfoque más seguro suele ser seguir el proceso de emergencia oficial para crear un nuevo conjunto de cartera y frase semilla, y luego completar la migración de activos, en lugar de importar o manipular repetidamente la dirección original.

II. L2 no es solo «Ethereum más barato», sino también un complejo conjunto de cadenas de confianza

Además de las carteras, múltiples incidentes en junio apuntaron a los cada vez más complejos sistemas L2.

El 14 y 18 de junio, dos despliegues antiguos relacionados con Aztec fueron atacados sucesivamente, con pérdidas totales de aproximadamente 4,35 millones de dólares.

Es importante señalar que los atacados fueron despliegues antiguos de Aztec Connect, que ya estaban en estado heredado, y no equivale a que la red principal actual de Aztec Network haya sido atacada. Sin embargo, los problemas expuestos por ambos incidentes son una advertencia significativa para todo el campo de los ZK Rollups.

En uno de los incidentes, el atacante aprovechó la inconsistencia entre el número de transacciones y los datos realmente procesados, logrando que el sistema registrara un depósito dentro de la prueba pero evitando el proceso de deducción de saldo correspondiente en L1.

El otro incidente se originó por la falta de restricciones en el circuito de prueba de conocimiento cero. El sistema verificó una prueba formalmente válida, pero no garantizó que el árbol de estado privado utilizado por la prueba coincidiera completamente con la raíz de estado pública utilizada realmente para la liquidación en Ethereum. Por lo tanto, el atacante pudo generar una prueba en torno a un árbol de estado falso y extraer activos del contrato L1.

Este tipo de problemas es difícil de resumir con la tradicional «¿existe una línea de código vulnerable en el contrato?» Después de todo, las pruebas de conocimiento cero pueden demostrar que un proceso de cálculo sigue reglas establecidas, pero solo si las reglas en sí son correctas y completas. Si el desarrollador olvida restringir una variable clave, la prueba aún puede ser matemáticamente válida, pero demuestra un resultado que no es coherente con el estado de liquidación real.

El posterior incidente de seguridad 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 basado en SGX de Taiko fue explotado, causando pérdidas 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 enviada previamente a un repositorio público de GitHub, y aprovechó el defecto de que el contrato de verificación en cadena no rechazaba los Enclaves en modo DEBUG, registrando un probador malicioso como instancia legítima.

Posteriormente, el atacante falsificó una prueba de estado L2, haciendo que el contrato en Ethereum aceptara un estado L2 inexistente, extrayendo finalmente fondos del puente. En resumen, se debió a que la clave utilizada para firmar el entorno de ejecución confiable se hizo pública, y las reglas de atestación remota no verificaron completamente las propiedades del entorno de ejecución, lo que hizo que una prueba «certificada» perdiera su significado de confianza original.

Al mismo tiempo, Base experimentó una parada en la producción de bloques de la red principal entre el 25 y 26 de junio. En su revisión posterior, Base indicó que las dos interrupciones se debieron al mismo defecto en la lógica de construcción de bloques: una transacción fallida no limpió correctamente el estado registrado anteriormente, lo que provocó que las transacciones posteriores calcularan incorrectamente el gas y generaran un bloque que contenía una transición de estado no válida. Dado que otros nodos no pudieron aceptar ese bloque, la red finalmente dejó de avanzar. Base afirmó que la integridad de la cadena no se vio comprometida durante el incidente y que los fondos de los usuarios siempre estuvieron seguros.

Esto no fue un robo de activos ni un ataque externo, sino una falla técnica que afectó la disponibilidad y la 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 el usuario, si una cadena es segura no solo depende de si un hacker puede falsificar activos, sino también de si los bloques pueden producirse continuamente, si los puentes entre cadenas pueden funcionar correctamente, si los nodos pueden recuperarse rápidamente y, cuando ocurre una falla en el sistema, si el usuario todavía tiene una ruta de salida viable.

Por lo tanto, al usar L2, los usuarios no deben comparar solo las comisiones y las expectativas de airdrop. Para L2 de menor escala, recién lanzadas o con mecanismos de seguridad que cambian rápidamente, evite mantener grandes cantidades de activos a largo plazo más allá de las necesidades reales de uso. Antes de realizar un puente entre cadenas, confirme que utiliza el puente oficial y conozca los tiempos de retiro, los mecanismos de pausa y los métodos de salida de emergencia. Ante una parada en la producción de bloques, anomalías en puentes entre cadenas o advertencias de seguridad oficiales, no envíe transacciones repetidamente ni continúe puenteando activos.

Un enfoque más seguro es gestionar los activos de diferentes propósitos y niveles de riesgo de forma dispersa, en lugar de concentrar toda la liquidez en un mismo L2, un mismo puente entre cadenas o un mismo mecanismo de salida.

III. El contrato no fue atacado, pero los servicios de terceros pueden traer el ataque al usuario

Si los problemas de carteras y L2 aún ocurren en componentes técnicos relativamente subyacentes, el incidente de Polymarket demuestra que el frontend web, que es el más cercano al usuario, también puede convertirse en una puerta de entrada para los fondos.

El 25 de junio, Polymarket informó que uno de sus proveedores de servicios de terceros fue comprometido, y el atacante inyectó scripts maliciosos en el frontend de Polymarket al que accedían algunos usuarios.

Según estadísticas de firmas de seguridad y analistas en cadena, el incidente causó pérdidas de aproximadamente 3 millones de dólares en activos de los usuarios, afectando a alrededor de 11 carteras. Los fondos robados luego fueron puenteados desde Polygon a Ethereum y convertidos en aproximadamente 1893 ETH. Sin embargo, posteriormente Polymarket indicó que ya había eliminado la dependencia afectada y 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 no apuntan a una vulnerabilidad en los contratos inteligentes centrales de Polymarket. El problema principal radicó en las dependencias de frontend de terceros cargadas por la página web.

Esto también es un espejo: hoy en día, la mayoría de las aplicaciones Web3 no se ejecutan completamente en la cadena. Las páginas web que ven los usuarios, como las interfaces de trading, todavía dependen en gran medida de la infraestructura tradicional de Internet y de paquetes de software de terceros. Cualquiera de estas dependencias que sea atacada puede hacer que un sitio web legítimo muestre información errónea al usuario, reemplace direcciones de recepción o induzca a la cartera a firmar transacciones maliciosas.

Por lo tanto, «la URL es verdadera» no equivale necesariamente a «todo el código cargado en este momento es seguro», y «el contrato ha sido auditado» no significa que toda la ruta de interacción entre el usuario y el contrato esté libre de riesgos. Ante este tipo de ataques al frontend y a la cadena de suministro, los usuarios comunes difícilmente pueden revisar de forma independiente cada fragmento de código cargado en la página web. Sin embargo, aún pueden reducir las pérdidas potenciales disminuyendo los permisos de cada interacción:

• Use una cartera independiente para interactuar con DApps: la cartera de ahorros 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 los fondos que planea usar a corto plazo. Incluso si el frontend o las autorizaciones se ven comprometidos, el impacto será relativamente limitado.

• Antes de firmar, preste atención a la operación real en lugar de solo al botón en la página web. El sitio web puede decir «Iniciar sesión», «Reclamar» o «Confirmar pedido», pero eso no significa que la firma que aparece en la cartera sea la misma operación.

• Cuando la página web muestre anomalías, no continúe operando por inercia. Si la página solicita repentinamente reimportar la frase semilla, descargar complementos adicionales, o el contenido de la transacción mostrada no coincide con la descripción de la página, detenga la interacción, confirme la situación a través de múltiples canales oficiales del proyecto, y revise o revoque las autorizaciones históricas que ya no se usen.

• Desde la perspectiva de los productos de cartera, esto también significa que el rol de la cartera está cambiando.

Ya no debe ser solo una herramienta que almacena claves privadas y muestra ventanas de firma. También debe ayudar al usuario a comprender la intención de la transacción, identificar autorizaciones anómalas, mostrar cambios en los activos y proporcionar advertencias claras antes de que ocurra una interacción 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 el usuario reduzcan conjuntamente la superficie de ataque, en lugar de delegar toda la responsabilidad a una sola parte.

Reflexiones finales

En el pasado, se solía decir: quien tenga la clave privada, tendrá los activos en la cadena.

Esa afirmación sigue siendo válida, pero no cubre todo el proceso desde que el usuario «genera la intención de una transacción» hasta que «se completa la liquidación en cadena». La seguridad de Web3 hoy ya no se trata solo de proteger un conjunto de frases semilla, sino de proteger toda la ruta que va desde la generación de claves por parte de la cartera, la visualización de la transacción, la ejecución de la firma, hasta la verificación de la red y la liquidación final.

Por supuesto, esto no significa que los usuarios deban alejarse de todas las interacciones en la cadena. Para los usuarios, los hábitos de seguridad realmente efectivos implican gestionar por separado el propósito de los activos, el nivel de riesgo y el escenario de interacción: los activos a largo plazo deben estar altamente aislados, las interacciones diarias deben ser de bajo monto, las DApps desconocidas deben tener autorizaciones limitadas, y las operaciones de alto riesgo deben ser verificadas múltiples veces.

Después de todo, cuando el riesgo de seguridad se expande de un punto a una cadena, la defensa del usuario también debe pasar de simplemente proteger la clave privada a un conjunto completo de hábitos.

Un abrazo a todos.