Más allá de las claves privadas: ¿Cómo salvaguardar los límites de seguridad de Web3 desde las billeteras, L2 hasta las cadenas de suministro?

A medida que los riesgos de seguridad se expanden de un solo punto a una cadena, las defensas de los usuarios deben evolucionar de simplemente proteger las claves privadas a adoptar un conjunto integral de hábitos.

Escrito por: imToken

En junio, el mundo de las criptomonedas experimentó una serie de incidentes de seguridad que abarcaron múltiples sectores.

El último informe mensual de seguridad de PeckShield indica que hubo 40 incidentes importantes de hacking en junio, con pérdidas totales que alcanzaron hasta $75.87 millones. Lo que es aún más preocupante es que estos ataques no se concentraron en un solo vector de ataque; en cambio, cubrieron vulnerabilidades en las implementaciones de firmas de billeteras, fallos en protocolos L2 y ataques a la cadena de suministro de servicios de terceros, con múltiples defensas fallando en el mismo mes.

A medida que los riesgos de seguridad de Web3 se expanden desde un único punto de entrada a los caminos de interacción de toda la cadena, cada usuario debe reconsiderar una pregunta crucial: ¿Son mis activos criptográficos aún seguros?

1. La importancia de las implementaciones de firmas de billeteras más allá de las claves privadas

El incidente de seguridad que ocurrió en junio en la billetera del ecosistema Cardano, SecondFi, sirve como un claro ejemplo.

SecondFi era anteriormente conocida como la billetera del ecosistema Cardano, Yoroi. Del 21 al 23 de junio, los atacantes transfirieron aproximadamente 16 millones de ADA desde algunas direcciones de usuarios de SecondFi, involucrando alrededor de 374 billeteras, lo que ascendió a aproximadamente $2.4 millones según el precio en el momento del incidente. SecondFi declaró más tarde que habían implementado medidas de emergencia para proteger aproximadamente 129 millones de ADA que podrían verse afectadas.

Lo que hace que este incidente sea particularmente único es que los usuarios afectados no dieron activamente sus frases mnemotécnicas a los atacantes; el problema radicaba en la implementación de firma subyacente de la billetera. Según el análisis de la agencia de seguridad BlockSec, el nonce de firma se derivó incorrectamente de los mensajes de transacción públicos, omitiendo el prefijo de nonce secreto requerido por las implementaciones estándar.

Esto significaba que cada vez que los usuarios firmaban transacciones utilizando la versión afectada de la billetera, los datos de firma pública publicados en la cadena expondrían suficiente información para derivar la clave privada de la dirección. Por lo tanto, los atacantes no necesitaban invadir los teléfonos de los usuarios ni obtener frases mnemotécnicas; solo necesitaban analizar los datos disponibles públicamente en la cadena para potencialmente recuperar la clave privada de firma de la dirección correspondiente.

Desde la perspectiva del usuario, la billetera parecía estar funcionando normalmente, ya que las frases mnemotécnicas no se exponían a través de ventanas emergentes, las contraseñas no se rompían y las transacciones eran efectivamente iniciadas por los propios usuarios. Sin embargo, desde un punto de vista criptográfico, mientras una dirección de usuario hubiera generado algunas firmas válidas a través de la versión afectada, los datos de transacción y firma públicos podrían ayudar a los atacantes a derivar la clave privada de firma de esa dirección.

En última instancia, la seguridad de la billetera depende de si las claves privadas se generan correctamente, si las firmas se completan estrictamente de acuerdo con los estándares criptográficos y si estos códigos críticos pueden ser auditados y verificados externamente. Esto subraya la importancia de mantener los componentes centrales de la billetera como código abierto.

Por supuesto, esta es una falla de implementación específica de una versión particular de la billetera y no un problema universal para todas las billeteras de autocustodia. Por ejemplo, el TokenCore de imToken tiene su repositorio de código central públicamente alojado en GitHub, cubriendo funciones de gestión de claves, derivación de direcciones y firma de transacciones.

Si bien el código abierto no garantiza que el código esté libre de vulnerabilidades, ni significa que los usuarios puedan bajar completamente la guardia, para los componentes criptográficos y de firma más sensibles en las billeteras, el código abierto al menos proporciona una premisa esencial: los investigadores de seguridad, desarrolladores y la comunidad pueden inspeccionar el código, reproducir problemas y realizar pruebas continuas, en lugar de depender únicamente de una caja negra no verificable.

Para los usuarios comunes, estos incidentes corresponden a varios principios de seguridad más prácticos.

• Primero, las billeteras siempre deben descargarse a través de sitios web oficiales o tiendas de aplicaciones oficiales y actualizarse puntualmente a versiones seguras;
• Segundo, es aconsejable no almacenar todos los activos en la misma billetera de interacción diaria; los activos grandes a largo plazo pueden almacenarse en billeteras de hardware o billeteras frías independientes, aislándolos de las billeteras calientes que se conectan frecuentemente a DApps.
• Más importante aún, una vez que la confirmación oficial de la billetera indica una vulnerabilidad en la generación de claves o implementación de firmas, simplemente importar la frase mnemotécnica original en otra billetera generalmente no resuelve el problema;

Porque importar la misma frase mnemotécnica en otras billeteras no cambia las direcciones y claves privadas que ya han sido expuestas. Los activos afectados deben ser transferidos a una nueva dirección que nunca haya firmado a través de la versión vulnerable; para los usuarios comunes, un enfoque más prudente es típicamente seguir el proceso de emergencia oficial para crear una billetera completamente nueva y una frase mnemotécnica antes de completar la migración de activos, en lugar de importar o operar repetidamente la dirección original.

2. L2 no es solo un 'Ethereum más barato', sino una cadena de confianza compleja

Además de las billeteras, múltiples incidentes en junio también señalaron riesgos asociados con sistemas L2 cada vez más complejos.

El 14 y 18 de junio, dos implementaciones de Rollup obsoletas relacionadas con Aztec fueron atacadas, resultando en pérdidas totales de aproximadamente $4.35 millones.

Es importante señalar que los ataques se dirigieron a implementaciones heredadas como Aztec Connect, que ya no están en uso activo, y no equivalen a un ataque a la red principal actual de Aztec. Sin embargo, los problemas expuestos por estos dos incidentes son bastante alarmantes para todo el campo de ZK Rollup.

En uno de los incidentes, los atacantes explotaron inconsistencias entre el número de transacciones y los datos procesados realmente, causando que el sistema registrara un depósito internamente mientras eludía el proceso correspondiente de deducción de saldo en L1.

El otro incidente se originó de la falta de restricciones en el circuito de prueba de conocimiento cero, donde el sistema validó una prueba formalmente válida pero no garantizó que el árbol de estado privado utilizado en esa prueba fuera completamente consistente con la raíz de estado públicamente utilizada en Ethereum para liquidación. Como resultado, los atacantes pudieron generar pruebas alrededor de un árbol de estado fabricado y extraer activos del contrato L1.

Este tipo de problemas son difíciles de resumir con la pregunta tradicional de si un contrato contiene una línea de código vulnerable. Después de todo, las pruebas de conocimiento cero pueden demostrar que un proceso computacional se adhiere a reglas establecidas, pero el requisito previo es que las reglas mismas sean correctas y completas. Si los desarrolladores olvidan restringir una variable crítica, la prueba puede seguir siendo matemáticamente válida mientras demuestra un resultado que no se alinea con el estado de liquidación real.

El posterior incidente de seguridad que involucró a Taiko expuso otro tipo de riesgo en la cadena de confianza de L2.

El 22 de junio, el proceso de verificación de prueba basado en SGX de Taiko fue explotado, resultando en pérdidas de aproximadamente $1.7 millones. Según el análisis de BlockSec, los atacantes utilizaron una clave privada de firma de enclave SGX que había sido previamente enviada a un repositorio público de GitHub, mientras que también explotaron un fallo en el contrato de verificación en cadena que no rechazaba el modo DEBUG Enclave, permitiendo a los proveedores maliciosos registrarse como instancias legítimas.

Los atacantes luego falsificaron pruebas de estado L2, llevando a los contratos de Ethereum a aceptar un estado L2 inexistente, extrayendo finalmente activos de los fondos de puente. La causa raíz fue que la clave utilizada para firmar el entorno de ejecución confiable se hizo pública, y las reglas de autenticación remota no verificaron exhaustivamente los atributos del entorno operativo, causando que una prueba 'certificada' perdiera su significado de confianza originalmente previsto.

Mientras tanto, Base experimentó una interrupción en la producción de bloques de la red principal del 25 al 26 de junio. En una revisión posterior al incidente, Base indicó que las dos interrupciones se debieron a la misma falla en la lógica de construcción de bloques: una transacción fallida no eliminó correctamente los estados previamente registrados, llevando a que las transacciones subsiguientes se calcularan incorrectamente para Gas y generaran bloques que contenían transiciones de estado inválidas. Como otros nodos no pudieron aceptar estos bloques, la red finalmente dejó de progresar. Base declaró que la integridad de la cadena no se comprometió durante el incidente y que los fondos de los usuarios permanecieron seguros.

Este no fue un caso de robo de activos o un ataque externo, sino más bien un fallo técnico que afectó la disponibilidad de la red y las capacidades de recuperación. Sin embargo, desde una perspectiva de seguridad más amplia, la disponibilidad en sí misma también es parte del modelo de seguridad de L2.

Para los usuarios, si una cadena es segura depende no solo de si los hackers pueden falsificar activos, sino también de si los bloques pueden seguir produciéndose, los puentes entre cadenas pueden funcionar normalmente, los nodos pueden recuperarse rápidamente y si los usuarios aún tienen caminos de salida viables cuando el sistema encuentra fallos.

Por lo tanto, al usar L2, los usuarios no solo deben comparar tarifas de transacción y expectativas de airdrop. Para L2 de menor escala, recién lanzados o en rápida evolución, es aconsejable evitar almacenar grandes cantidades de activos que superen las necesidades de uso real durante períodos prolongados; antes de las transacciones entre cadenas, los usuarios deben confirmar que están utilizando el puente oficial y entender los tiempos de retiro, mecanismos de pausa y métodos de salida de emergencia; al encontrar interrupciones en la red, anomalías entre cadenas o alertas de seguridad oficiales, los usuarios deben abstenerse de enviar transacciones repetidamente o continuar puentando activos.

Un enfoque más prudente es gestionar activos de diferentes propósitos y niveles de riesgo por separado, en lugar de colocar toda la liquidez en el mismo L2, el mismo puente entre cadenas o depender de un único mecanismo de salida.

3. Los contratos pueden no ser vulnerados, pero los servicios de terceros también pueden traer ataques a los usuarios

Si los problemas con las billeteras y L2 aún ocurren en componentes técnicos de nivel relativamente bajo, entonces el incidente que involucró a Polymarket ilustra que incluso el front-end web más cercano a los usuarios también puede convertirse en un punto de entrada para los fondos.

El 25 de junio, Polymarket anunció que un proveedor de terceros que utilizaba había sido comprometido, permitiendo a los atacantes inyectar scripts maliciosos en el front-end de Polymarket al que accedieron algunos usuarios.

Según estadísticas de agencias de seguridad y analistas en cadena, el incidente resultó en aproximadamente $3 millones en pérdidas de activos de usuarios, involucrando alrededor de 11 billeteras. Los fondos robados fueron posteriormente puentados de Polygon a Ethereum y cambiados por aproximadamente 1,893 ETH. Sin embargo, Polymarket declaró más tarde que había eliminado las dependencias afectadas y reembolsaría completamente a los usuarios impactados.

El punto clave de este incidente es que el nombre de dominio al que accedieron los usuarios puede seguir siendo el dominio correcto de Polymarket, y las divulgaciones existentes no apuntaron a vulnerabilidades en los contratos inteligentes centrales de Polymarket; el problema radicaba principalmente en las dependencias front-end de terceros cargadas por la página web.

Esto sirve como un espejo; hoy en día, la mayoría de las aplicaciones Web3 no funcionan completamente en la cadena. Las páginas web que los usuarios ven, como las interfaces de comercio, todavía dependen en gran medida de la infraestructura de internet tradicional y paquetes de software de terceros. Cualquiera de estas dependencias siendo atacadas podría permitir que sitios web legítimos muestren información incorrecta a los usuarios, reemplacen direcciones de pago o induzcan a las billeteras a firmar transacciones maliciosas.

Por lo tanto, 'la URL es real' no significa necesariamente 'todo el código que se carga en este momento es seguro', y 'el contrato ha pasado la auditoría' no equivale a que todo el camino de interacción entre usuarios y contratos esté libre de riesgos. Ante tales ataques de front-end y de cadena de suministro, los usuarios comunes encuentran difícil verificar de manera independiente cada segmento de código cargado en la página web, pero aún pueden mitigar pérdidas potenciales reduciendo los permisos de interacciones únicas:

• Usar una billetera de interacción DApp separada: Las billeteras de ahorros a largo plazo deben evitar conectarse directamente a varios sitios de DeFi, NFT, mercados de predicción y airdrop. Las billeteras de interacción diaria solo deben contener fondos destinados a uso inmediato, por lo que incluso si surgen problemas con el front-end o la autorización, el impacto es relativamente limitado;
• Enfocarse en las operaciones reales antes de firmar, en lugar de solo mirar los botones de la página web: Solo porque una página web diga 'Iniciar sesión', 'Reclamar' o 'Confirmar pedido' no significa que la firma que aparece en la billetera sea la misma acción;
• No confiar en la inercia para continuar operando cuando la página web presenta anomalías: Si una página solicita repentinamente reimportar frases mnemotécnicas, descargar complementos adicionales o muestra contenido de transacción inconsistente con la descripción de la página web, los usuarios deben pausar las interacciones, confirmar la situación a través de múltiples canales oficiales del proyecto y verificar o revocar autorizaciones históricas que ya no están en uso;

Desde la perspectiva de los productos de billetera, esto también significa que el papel de las billeteras está cambiando.

No deben ser meras herramientas para almacenar claves privadas y mostrar ventanas de firma; también necesitan ayudar a los usuarios a comprender las intenciones de las transacciones, identificar autorizaciones anormales, mostrar cambios de activos y proporcionar advertencias suficientemente claras antes de que ocurran interacciones de alto riesgo.

Sin embargo, las billeteras no pueden eliminar todos los riesgos para los usuarios. Un modelo de seguridad más realista es que las billeteras, protocolos, L2, proveedores de servicios de terceros y usuarios reduzcan colectivamente la superficie de ataque, en lugar de trasladar toda la responsabilidad a una sola parte.

En conclusión

En el pasado, a menudo se decía que quien posee la clave privada posee los activos en la cadena.

Esta afirmación sigue siendo cierta, pero no abarca todo el proceso de los activos de los usuarios desde 'generar intenciones de transacción' hasta 'completar liquidaciones en la cadena.' La seguridad de Web3 de hoy ya no se trata solo de proteger un conjunto de frases mnemotécnicas; se trata de salvaguardar todo el camino desde la generación de claves de billetera, la visualización de transacciones, la ejecución de firmas, 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, verdaderos hábitos de seguridad efectivos significan gestionar los propósitos de los activos, niveles de riesgo y escenarios de interacción por separado: activos a largo plazo fuertemente aislados, interacciones diarias con pequeñas cantidades, baja autorización para DApps desconocidas y múltiples verificaciones para operaciones de alto riesgo.

Después de todo, a medida que los riesgos de seguridad se expanden de un solo punto a una cadena, las defensas de los usuarios deben evolucionar de simplemente proteger las claves privadas a adoptar un conjunto integral de hábitos.

Esforcémonos juntos.