Escrito por: imToken
Una cartera de hardware con chips originales intactos, firmware genuino e incluso la capacidad de pasar con éxito la verificación oficial Genuine Check, ¿podrían los activos en su interior ser robados por hackers?
El reciente incidente de seguridad de Ledger expuso precisamente este riesgo aparentemente imposible.
Según los resultados de la investigación posteriormente divulgados por el equipo de seguridad de Ledger, el atacante implantó un circuito malicioso adicional dentro del dispositivo afectado, que era capaz de interceptar la frase mnemónica mostrada en la pantalla y enviarla al atacante a través de redes de comunicación móvil.
En otras palabras, el chip de seguridad original no fue comprometido, pero la frase mnemónica puede haber caído ya en manos del hacker la primera vez que se mostró en la pantalla.
Además, este no es el único incidente de seguridad que merece atención recientemente.
Desde septiembre, desde Bitget encontrándose con la explotación de una vulnerabilidad en un producto de seguridad de terceros, hasta el proveedor de servicios de correo electrónico de Trezor, Brevo, siendo vulnerado, hasta problemas de seguridad apareciendo en parte de la infraestructura de MetaMask, una serie de incidentes nos recuerdan que a medida que los productos Crypto se vuelven cada vez más complejos, la seguridad ya no se trata solo de proteger las claves privadas y evitar vulnerabilidades en los contratos inteligentes.
Los riesgos ocultos en la circulación de dispositivos, los servicios de terceros, los permisos internos y las comunicaciones con los usuarios pueden igualmente convertirse en puntos de entrada que los atacantes buscan.
I. La nueva alarma de "seguridad de la cadena de suministro" que hizo sonar Ledger
Primero desglosemos qué le sucedió a Ledger esta vez.
Al comprar una cartera de hardware, las personas suelen estar en guardia contra dos cosas: comprar una falsificación o recibir un dispositivo que ha sido preinicializado por otra persona.
El truco más común en los primeros años era que los intermediarios maliciosos generaran primero una frase mnemónica, la imprimieran en una tarjeta rascable y la volvieran a meter en el embalaje, apostando a que los usuarios novatos no entenderían las reglas y depositarían fondos directamente en ella.
Aunque esta estafa es peligrosa, la lógica de defensa es muy clara: utilizar canales legítimos, verificar el estado del dispositivo, observar que el dispositivo genere una nueva frase mnemónica por sí mismo y nunca usar una frase mnemónica ya preparada que venga en la caja.
Pero este ataque contra Ledger claramente ha escalado los métodos. El hacker metió un módulo electrónico adicional con un microcontrolador, eSIM y capacidades de comunicación celular dentro de la carcasa. Cuando los usuarios inicializan la cartera por primera vez, en última instancia necesitarán leer la frase mnemónica de la pantalla y anotarla.
En otras palabras, el circuito malicioso implantado no interfiere en absoluto con el proceso de generación de la mnemónica; simplemente monitorea la frase mnemónica y la transmite directamente. Esta es también la razón por la cual "la clave privada no fue extraída directamente del chip de seguridad" no significa que la información de recuperación de la cartera del usuario siga siendo segura.
Lo que es más problemático es que incluso si el dispositivo pasa la verificación oficial Genuine Check, puede que no sea capaz de identificar este hardware adicional, porque la verificación genuina principalmente confirma la identidad del chip de seguridad y la confiabilidad del firmware.
Así que este incidente ciertamente ha expuesto un grave "riesgo de cadena de suministro" que se pasa por alto fácilmente en la vida diaria: la seguridad de una cartera de hardware depende no solo del chip y el firmware, sino también de todo el proceso de entrega desde la fábrica original hasta las manos del usuario.
Después de todo, un dispositivo puede necesitar pasar por múltiples eslabones como distribuidores regionales, almacenes de terceros, logística y minoristas. Cualquier participante con la oportunidad de acceder físicamente al dispositivo puede convertirse en un punto de riesgo que requiera una evaluación adicional.
II. De Trezor a Bitget: ¿Cómo evaden los atacantes las defensas de seguridad centrales?
Habiendo entendido el problema de Ledger, si luego observamos los incidentes de seguridad que Bitget y Trezor enfrentaron uno tras otro recientemente, encontraremos que la lógica subyacente es sorprendentemente similar: los atacantes igualmente evitaron la línea de defensa frontal más fuerte y, en su lugar, penetraron desde los "servicios de terceros" periféricos.
Primero, veamos Trezor.
A principios de septiembre, algunos usuarios de Trezor recibieron un correo electrónico con el asunto "Alerta crítica de seguridad: vulnerabilidad de entropía STM32", que afirmaba que la cartera de hardware tenía una grave vulnerabilidad de seguridad y que se requería acción inmediata.
Este tipo de correos electrónicos fácilmente ponen nerviosos a los usuarios. Después de todo, cuando se trata de carteras de hardware y vulnerabilidades de seguridad, nadie quiere que sus activos sufran pérdidas por ello.
Esto es exactamente lo que sucedió: el atacante explotó Brevo, la plataforma de marketing por correo electrónico de terceros utilizada por Trezor, para permitir que contenido malicioso llegara a las bandejas de entrada de los usuarios a través de la infraestructura normal de envío de correos electrónicos.
Según el informe de incidente posterior de Brevo, el atacante explotó fallos en los límites de permisos de su sistema de inicio de sesión único para obtener acceso no autorizado a otras cuentas de clientes, involucrando finalmente a 138 cuentas de clientes, algunas de las cuales fueron utilizadas para enviar correos electrónicos de phishing o exportar datos de contacto.
Trezor confirmó posteriormente que 347.149 direcciones de contacto de correo electrónico de marketing fueron exportadas en el incidente, y los correos electrónicos de ataque intentaron inducir a los usuarios a descargar aplicaciones maliciosas e ingresar información de respaldo de la cartera.
Cabe señalar que no hay evidencia en este incidente de que las carteras de hardware de Trezor o los sistemas de protección de claves privadas hayan sido comprometidos. Lo que el atacante obtuvo primero fue información de usuario y la capacidad de abusar de los canales de comunicación oficiales.
Pero para los usuarios comunes que recibieron los correos electrónicos, identificar el riesgo se volvió aún más difícil, porque los correos electrónicos pueden haber provenido de un dominio oficial familiar y también podrían pasar las verificaciones normales de autenticación de correo electrónico, mientras que el contenido ya había sido reemplazado por el atacante con información de phishing.
Si los usuarios ingresan voluntariamente su frase mnemónica debido a esto, lo que originalmente era solo un problema del servicio de correo electrónico de terceros podría evolucionar aún más hacia pérdidas reales de activos.
Ahora veamos Bitget.
El 24 de septiembre, se produjeron transferencias de activos no autorizadas en algunas de las carteras calientes y carteras tibias de Bitget, que finalmente se verificó que involucraban aproximadamente US$388 millones.
Según los resultados de la investigación anunciados oficialmente por Bitget, el atacante explotó una vulnerabilidad en un producto de seguridad de terceros para obtener credenciales de alto privilegio dentro del exchange, luego irrumpió en los sistemas backend relacionados con las carteras, falsificó instrucciones de retiro, eludió las verificaciones originales de control de riesgos y provocó que transferencias anómalas entraran en el proceso de ejecución normal.
Bitget declaró que no se encontró filtración de claves privadas en este incidente, y que las carteras frías no se vieron afectadas. Esto suena algo contradictorio: dado que las claves privadas no fueron robadas, ¿por qué el dinero aún pudo ser transferido?
En realidad, no es difícil de entender.
Para plataformas de custodia como los exchanges, después de que un usuario inicia un retiro, no es el caso que una persona firme manualmente cada transacción con una clave privada cada vez. En cambio, debe pasar por todo un conjunto de procesos internos como verificación de cuenta, revisión de control de riesgos, generación de transacciones y firma de cartera.
Esto es como una bóveda bancaria. Incluso si la llave de la bóveda se guarda con mucho rigor, si alguien puede hacerse pasar por una identidad interna de alto privilegio y falsificar una instrucción de transferencia que pase la aprobación, los fondos en la bóveda aún podrían ser transferidos erróneamente.
Lo que Bitget expuso esta vez es exactamente cómo el riesgo se propaga aún más al sistema de ejecución de activos después de que fallan los permisos upstream y la verificación de instrucciones. Por lo tanto, "la clave privada no se filtró" y "los fondos no serán transferidos ilegalmente" son en realidad dos cosas diferentes.
En cuanto al incidente de seguridad de infraestructura divulgado por MetaMask a finales de septiembre, presentó otra dimensión del riesgo operativo.
En ese momento, MetaMask tomó medidas preventivas y salió de forma proactiva de algunos validadores de staking afectados. Según la actualización oficial de la investigación del 1 de octubre, no se han encontrado indicios de que las billeteras MetaMask o los fondos de los clientes se hayan visto afectados, y el negocio de staking relevante no gestiona las claves de retiro en nombre de los clientes.
Sin embargo, esto no significa que los problemas de infraestructura no vayan a tener otros impactos. Las soluciones no custodiales abordan principalmente la cuestión del control de los activos, pero no pueden eliminar automáticamente los riesgos operativos de la infraestructura externa.
Al reunir estos eventos, el hilo conductor es en realidad muy claro:
- Lo que Ledger expuso es el riesgo de manipulación física en el proceso de circulación del hardware, que en última instancia puede llevar al robo de frases mnemónicas;
- Lo que Trezor / Brevo expusieron es el riesgo de filtración de información de usuarios y de abuso de los canales oficiales de comunicación, lo que no significa que la billetera en sí haya sido comprometida;
- Lo que Bitget expuso es el riesgo de que las vulnerabilidades de productos de terceros se transmitan a sistemas internos de altos privilegios, lo que puede afectar directamente la ejecución de fondos;
- MetaMask, a su vez, nos recuerda que el control de los activos y el riesgo operativo del servicio no son el mismo concepto.
En general, los productos Crypto de hoy ya no son islas aisladas.
Las billeteras dependen de nodos RPC externos para leer datos en la cadena y de interfaces de agregación para obtener cotizaciones de mercado; los exchanges no pueden prescindir de la monitorización de seguridad externa, la verificación KYC y los componentes de control de riesgos; y extendiéndose más hacia fuera, también existen operadores de nodos, proveedores de nube, tickets de atención al cliente y sistemas de correo electrónico como Brevo.
Estos servicios externos hacen que los productos funcionen de manera más eficiente y también mejoran la experiencia del usuario, pero al mismo tiempo, cada vez que se introduce una nueva dependencia externa, el producto adquiere otra capa de relaciones de confianza que deben gestionarse:
¿A qué pueden acceder los terceros, cuánta autoridad tienen y, si se ven comprometidos, seguirá el riesgo transmitiéndose a otros sistemas centrales?
III. ¿Cómo deben defenderse los productos y los usuarios?
Ante riesgos de dependencia de terceros cada vez más complejos y relaciones de dependencia entrelazadas, esperar que los equipos de producto retrocedan al estado primitivo de "no depender de ningún servicio externo" es obviamente irreal y no se ajusta a las reglas del mercado.
Lo que realmente pone a prueba la habilidad de una arquitectura de seguridad es minimizar cada posible exposición al riesgo.
Por ejemplo, ¿por qué un proveedor de SaaS que solo gestiona correos de marketing debería conservar a largo plazo los datos de contacto de todos los usuarios? ¿Por qué las herramientas de monitorización de seguridad de terceros pueden acceder al entorno de producción central sin una multi-autorización independiente? Especialmente para acciones sensibles que implican transferencias de fondos, los sistemas internos nunca deben adoptar la "confianza por defecto" y deben implementar un aislamiento estricto de permisos y una verificación cruzada independiente.
Esto es también lo que a menudo se denomina "mínimo privilegio" y "separación de funciones" en la arquitectura de seguridad: una plataforma de envío de correos solo debería tener los permisos necesarios para enviar correos, las herramientas de monitorización de seguridad no deberían poder ejecutar transferencias de fondos a voluntad, y un retiro de gran cuantía no debería aprobarse directamente basándose únicamente en una instrucción transmitida desde algún sistema interno.
El incidente de Ledger recuerda además a los fabricantes de billeteras hardware que la gestión de seguridad necesita extenderse incluso al proceso de circulación física del producto.
Desde el envío de fábrica, el almacenamiento, la logística, hasta la entrega al distribuidor, cómo establecer un proceso de gestión trazable, cómo detectar el desmontaje o reemplazo anómalo de dispositivos y cómo localizar los lotes y usuarios afectados después de que ocurra un problema no deberían considerarse una mera labor de gestión de canales.
Porque para un dispositivo hardware que protege claves privadas, el proceso de entrega en sí mismo es parte del sistema de seguridad.
Por supuesto, para los usuarios comunes, no podemos auditar la cadena de suministro de software de una billetera ni investigar uno por uno cada eslabón de almacenamiento y logística de una billetera hardware.
Pero esto no significa que solo podamos soportar el riesgo pasivamente. Al menos hay varias cosas que vale la pena convertir en hábitos en el uso diario.
Primero, minimizar los intermediarios innecesarios en el proceso de compra de una cartera de hardware.
Si las condiciones lo permiten, priorice pedir desde el sitio web oficial de la marca y que se envíe directamente desde la fábrica original o el almacén oficial, lo que normalmente reduce la posibilidad de que el dispositivo sea contactado, desmontado o intercambiado por terceros después de salir del control de la fábrica original.
Desde la perspectiva de la gestión de riesgos, cuantas más partes independientes entren en contacto con el dispositivo, más eslabones requerirán confianza adicional; además, tras recibir el dispositivo, aún debe verificar si hay anomalías en el embalaje y la apariencia, usar el software oficial para completar la verificación y seguir estrictamente el proceso de inicialización.
Segundo, es necesario volver a entender si los "mensajes oficiales" son confiables.
El incidente de Trezor ya ha demostrado que, incluso si un correo electrónico se envía realmente a través de la plataforma de servicio utilizada oficialmente, eso no significa que los enlaces y los requisitos de operación contenidos en él sean necesariamente seguros.
Especialmente cuando se trata de operaciones sensibles como actualizaciones de carteras, congelación de cuentas, migración de activos y corrección de vulnerabilidades, es mejor no hacer clic directamente en los enlaces del mensaje, sino verificar de forma proactiva a través de la dirección del sitio web oficial que haya guardado o de la App oficial que ya haya instalado.
Para carteras no custodiales como imToken, los usuarios también necesitan identificar los canales oficiales, usar token.im como base para la descarga e instalación, y cuando encuentren información anómala, priorizar la verificación a través de entradas oficiales como "Ayuda y comentarios" en la App.
Independientemente de si la otra parte afirma ser servicio al cliente oficial, un equipo de seguridad, o proporciona una explicación de vulnerabilidad aparentemente muy profesional, nunca debe revelarles su frase mnemónica ni su clave privada.
Por último, es necesario distinguir el impacto real de los diferentes incidentes de seguridad sobre uno mismo.
Una filtración de dirección de correo electrónico significa principalmente que puede enfrentar más phishing dirigido en el futuro; hacer clic en un enlace sospechoso requiere confirmar además si se descargaron o ejecutaron programas maliciosos; si ya se ha introducido una frase mnemónica, debe tratarse de inmediato como una filtración del control de la cartera.
Si se han firmado transacciones o autorizaciones sospechosas, también es necesario combinar las operaciones específicas en la cadena para determinar si existe un riesgo continuo de autorización de contratos.
En cuanto a fallos de servicios de terceros o anomalías de infraestructura, es más necesario consultar el alcance del impacto divulgado oficialmente para determinar si involucra sus activos, la disponibilidad del servicio o los rendimientos.
No puede dar por sentado que la clave privada ha sido comprometida solo porque oye hablar de un "incidente de seguridad de cartera", y ciertamente no debe transferir precipitadamente activos a direcciones desconocidas debido a supuestas notificaciones urgentes de seguridad.
Después de todo, en muchos casos, lo que los atacantes realmente esperan no es romper la línea de defensa técnica más fuerte, sino hacer que los usuarios completen voluntariamente el último paso presa del pánico (Lectura adicional: "¿La IA "desafía" la criptografía? Web3 debe prepararse para los días de lluvia, pero nunca debe apresurarse a migrar").
Reflexiones finales
En el pasado, la frase que más se enfatizaba en la industria Crypto era "Not your keys, not your coins".
Esta frase sigue siendo importante, porque el control de la clave privada determina si los usuarios pueden controlar verdaderamente sus activos de forma independiente.
Pero a medida que las carteras, los exchanges y los productos financieros en la cadena maduran gradualmente, también debemos darnos cuenta de que la protección de la clave privada es solo una parte de todo el sistema de seguridad.
Una cartera de hardware genuina aún puede ser manipulada físicamente durante la entrega; una notificación enviada genuinamente desde un sistema de correo oficial también puede ser explotada por atacantes; e incluso un conjunto de herramientas de terceros originalmente destinado a reforzar la seguridad puede convertirse en una entrada al sistema central de fondos.
Estos casos no significan que debamos perder la confianza en todas las billeteras y servicios externos. Por el contrario, le recuerdan a toda la industria que la seguridad necesita extenderse desde el interior de un solo producto hasta todo el proceso de la cadena de suministro, la gestión de permisos, la comunicación con el usuario y la respuesta a emergencias.
Después de todo, un sistema de seguridad Crypto verdaderamente maduro no solo debe garantizar que las claves privadas no se filtren fácilmente, sino también garantizar en la medida de lo posible que, incluso si algún eslabón externo falla, todo el mecanismo aún pueda detener firmemente el riesgo a mitad de camino y evitar que cruce la línea roja final que protege los activos del usuario.
