De Ledger a Bitget: ¿Cuáles son las "zonas de confianza" descuidadas en la seguridad de las criptomonedas?

Más allá de las claves privadas, los riesgos pueden fluir a través de la circulación de dispositivos, servicios de terceros y permisos internos, llegando hasta los activos del usuario.

Escrito por: imToken

¿Es posible que los activos en una billetera de hardware, que tiene un chip original, firmware legítimo e incluso pasa la verificación de autenticidad (Genuine Check), sean robados por hackers?

El reciente incidente de seguridad de Ledger ha expuesto precisamente este riesgo que parece imposible.

Según los resultados de la investigación divulgados posteriormente por el equipo de seguridad de Ledger, los atacantes implantaron un circuito malicioso adicional dentro del dispositivo involucrado, capaz de interceptar las palabras de recuperación mostradas en la pantalla y enviarlas al atacante a través de la red de comunicación móvil.

En otras palabras, aunque el chip de seguridad original no fue comprometido, las palabras de recuperación podrían haber caído en manos de los hackers en el momento en que se mostraron por primera vez en la pantalla.

Además, este no es el único incidente de seguridad reciente que merece atención.

Desde septiembre, desde la explotación de vulnerabilidades en productos de seguridad de terceros en Bitget, hasta la invasión del proveedor de servicios de correo electrónico de Trezor, Brevo, y problemas de seguridad en parte de la infraestructura de MetaMask, una serie de eventos nos están recordando que a medida que los productos de criptomonedas se vuelven más complejos, la seguridad ya no se trata solo de proteger las claves privadas y evitar vulnerabilidades en contratos inteligentes.

Los riesgos ocultos en la circulación de dispositivos, servicios de terceros, permisos internos y comunicaciones de usuarios también pueden convertirse en puntos de entrada para los atacantes.

I. La nueva alarma de "seguridad de la cadena de suministro" que suena en Ledger

Comencemos a desglosar lo que le sucedió a Ledger.

Cuando compramos billeteras de hardware, generalmente nos preocupan dos cosas: recibir un producto falso o recibir un dispositivo que ha sido inicializado previamente por alguien más.

Antiguamente, el truco más común era que algunos intermediarios maliciosos generaban las palabras de recuperación, las imprimían en una tarjeta rasca y la devolvían al empaque, apostando a que los nuevos usuarios no conocían las reglas y depositaban dinero directamente.

Aunque este tipo de fraude es peligroso, la lógica de defensa es clara: buscar canales legítimos, verificar el estado del dispositivo y asegurarse de que el dispositivo genere nuevas palabras de recuperación por sí mismo, sin usar las que vienen en la caja.

Sin embargo, el ataque dirigido a Ledger ha elevado claramente el nivel de sofisticación, ya que los hackers insertaron un módulo electrónico adicional con un microcontrolador, eSIM y capacidad de comunicación celular dentro de la carcasa, lo que significa que el usuario debe leer y anotar las palabras de recuperación en la pantalla durante la primera inicialización de la billetera.

En otras palabras, el circuito malicioso implantado no interfiere con el proceso de generación de palabras de recuperación; simplemente monitorea las palabras y las envía directamente, lo que explica por qué "la clave privada no fue extraída directamente del chip de seguridad", pero eso no significa que la información de recuperación de la billetera del usuario sea segura.

Lo que es más problemático es que incluso si el dispositivo pasa la verificación de autenticidad, no necesariamente puede identificar este hardware adicional, ya que la verificación de autenticidad se centra principalmente en confirmar la identidad del chip de seguridad y la confiabilidad del firmware.

Por lo tanto, este incidente ha expuesto un grave "riesgo de cadena de suministro" que a menudo se pasa por alto: la seguridad de las billeteras de hardware no solo depende del chip y del firmware, sino también de todo el proceso de entrega desde el fabricante hasta el usuario.

Dado que un dispositivo puede pasar por distribuidores regionales, almacenes de terceros, logística y minoristas, cualquier participante que tenga la oportunidad de tener contacto real con el dispositivo puede convertirse en un punto de riesgo que necesita ser evaluado adicionalmente.

II. De Trezor a Bitget: ¿Cómo evaden los atacantes la línea de defensa de seguridad central?

Entendiendo el problema de Ledger, al observar los recientes incidentes de seguridad en Bitget y Trezor, se puede notar que la lógica subyacente es sorprendentemente similar: los atacantes también evadieron la línea de defensa frontal más sólida, dirigiéndose a los "servicios de terceros" en la periferia.

Primero, veamos a Trezor.

A principios de septiembre, algunos usuarios de Trezor recibieron un correo electrónico con el asunto "Alerta de Seguridad Crítica: Vulnerabilidad de Entropía STM32", afirmando que la billetera de hardware tenía una grave vulnerabilidad de seguridad que requería medidas inmediatas.

Este tipo de correos electrónicos puede poner nerviosos a los usuarios, ya que involucra billeteras de hardware y vulnerabilidades de seguridad; nadie quiere que sus activos se vean afectados por ello.

Esto es precisamente lo que los atacantes aprovecharon al utilizar la plataforma de marketing por correo electrónico de terceros que Trezor emplea, permitiendo que el contenido malicioso llegara a la bandeja de entrada del usuario a través de la infraestructura de envío de correos normal.

Según el informe posterior del incidente de Brevo, los atacantes aprovecharon una falla en los límites de permisos de su sistema de inicio de sesión único, obteniendo acceso no autorizado a las cuentas de otros clientes, afectando finalmente a 138 cuentas de clientes, algunas de las cuales se utilizaron para enviar correos electrónicos de phishing o exportar datos de contactos.

Trezor confirmó posteriormente que se exportaron 347,149 direcciones de contactos de correos electrónicos de marketing durante 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 billetera.

Es importante señalar que este incidente no presenta evidencia de que la billetera de hardware de Trezor o su sistema de protección de claves privadas haya sido comprometido; lo que los atacantes obtuvieron primero fue la información del usuario y la capacidad de abusar de los canales de comunicación oficiales.

Sin embargo, para los usuarios comunes que recibieron el correo, identificar el riesgo se vuelve más complicado, ya que el correo podría provenir de un dominio oficial conocido y pasar las verificaciones de autenticidad del correo, aunque el contenido ya ha sido reemplazado por información de phishing por los atacantes.

Si los usuarios completan las palabras de recuperación debido a esto, un problema que originalmente era del servicio de correo de terceros podría evolucionar en una pérdida real de activos.

Ahora veamos a Bitget.

El 24 de septiembre, algunos wallets calientes y fríos de Bitget experimentaron transferencias no autorizadas de activos, verificándose finalmente que estaban involucrados aproximadamente 388 millones de dólares.

Según los resultados de la investigación publicados oficialmente por Bitget, los atacantes aprovecharon una vulnerabilidad en un producto de seguridad de terceros para obtener credenciales de alto nivel dentro de la plataforma, luego infiltrándose en el sistema backend relacionado con las billeteras, falsificando órdenes de retiro y eludiendo las verificaciones de control de riesgos existentes, permitiendo que las transferencias anómalas entraran en el flujo de ejecución normal.

Bitget declaró que en este incidente no se encontró evidencia de filtración de claves privadas y que las billeteras frías no se vieron afectadas, lo que suena un poco contradictorio: si 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 intercambios, cuando un usuario inicia un retiro, no siempre hay un proceso manual donde alguien firma cada transacción con la clave privada; en cambio, debe pasar por un conjunto completo de procesos internos que incluyen verificación de cuentas, auditoría de riesgos, generación de transacciones y firma de billeteras.

Es como una caja fuerte bancaria. Incluso si la llave de la caja fuerte se guarda de manera muy estricta, si alguien puede hacerse pasar por una identidad de alto nivel dentro, falsificando una orden de transferencia aprobada, los fondos en la caja fuerte aún pueden ser transferidos erróneamente.

Lo que se expone en este caso de Bitget es cómo el riesgo se transmite a través de la ejecución de activos después de que se pierde el control de permisos y la verificación de órdenes en la parte superior, por lo que "no se filtraron claves privadas" y "los fondos no serán transferidos ilegalmente" son en realidad dos cosas diferentes.

En cuanto al incidente de seguridad de infraestructura revelado por MetaMask a finales de septiembre, presenta otra dimensión de riesgo operativo.

En ese momento, MetaMask tomó medidas preventivas, retirándose proactivamente de algunos validadores de participación afectados. Según la actualización de la investigación oficial del 1 de octubre, no se encontraron indicios de que la billetera MetaMask o los fondos de los clientes se vieran afectados, y los servicios de participación relacionados no reemplazan la gestión de claves de retiro de los clientes.

Sin embargo, esto no significa que los problemas de infraestructura no puedan tener otros efectos. Las soluciones no custodiadas abordan principalmente el problema del control de activos, pero no eliminan automáticamente los riesgos operativos de la infraestructura externa.

Al juntar estos eventos, el hilo conductor es bastante claro:

• Ledger expone el riesgo de manipulación física en la circulación de hardware, que puede llevar al robo de palabras de recuperación;
• Trezor / Brevo expone el riesgo de filtración de información del usuario y abuso de canales de comunicación oficiales, lo que no significa que la billetera en sí haya sido comprometida;
• Bitget expone el riesgo de vulnerabilidades en productos de terceros que se transmiten a sistemas internos de alto nivel, que pueden afectar directamente la ejecución de fondos;
• MetaMask nos recuerda que el control de activos y los riesgos operativos del servicio no son el mismo concepto.

En general, los productos de criptomonedas hoy en día ya no son islas aisladas.

Las billeteras dependen de nodos RPC externos para leer datos en la cadena, de interfaces agregadas para obtener cotizaciones; los intercambios no pueden prescindir de la supervisión de seguridad externa, la verificación KYC y los componentes de control de riesgos; y más allá, hay operadores de nodos, proveedores de nube, tickets de servicio al cliente y sistemas de correo como Brevo.

Estos servicios externos hacen que los productos funcionen de manera más eficiente y mejoran la experiencia del usuario, pero al mismo tiempo, cada vez que se introduce una nueva dependencia externa, el producto agrega una capa más de relación de confianza que necesita ser gestionada:

¿Qué puede acceder un tercero, qué permisos tiene y si una vez que se pierde, ¿transmitirá el riesgo a otros sistemas centrales?

III. ¿Cómo pueden los productos y los usuarios protegerse?

Frente a los riesgos de dependencia de terceros cada vez más complejos y las relaciones de dependencia interconectadas, esperar que los equipos de productos regresen al estado original de "no depender de ningún servicio externo" es evidentemente poco realista y no se ajusta a las leyes del mercado.

Lo que realmente pone a prueba la capacidad de la arquitectura de seguridad es reducir al mínimo cada posible exposición al riesgo.

Por ejemplo, ¿por qué un proveedor de servicios SaaS que solo se encarga de enviar correos de marketing debería retener los datos de contacto de todos los usuarios a largo plazo? ¿Por qué una herramienta de monitoreo de seguridad de terceros puede acceder al entorno de producción central sin múltiples autorizaciones independientes? Especialmente en acciones sensibles que involucran transferencias de fondos, los sistemas internos nunca deben operar con "confianza por defecto"; debe haber un estricto aislamiento de permisos y validación cruzada independiente.

Esto también se relaciona con lo que se dice comúnmente en la arquitectura de seguridad sobre "mínimos privilegios" y "separación de responsabilidades": la plataforma de envío de correos solo debería tener los permisos necesarios para enviar correos, las herramientas de monitoreo de seguridad no deberían ejecutar transferencias de fondos arbitrariamente, y un retiro grande no debería ser autorizado solo por una instrucción proveniente de un sistema interno.

Además, el incidente de Ledger recuerda aún más a los fabricantes de billeteras de hardware que la gestión de seguridad debe extenderse incluso a la circulación física del producto.

Desde la fábrica, almacenamiento, logística hasta la entrega por parte de distribuidores, cómo establecer un proceso de gestión rastreable, cómo detectar modificaciones o reemplazos anómalos de dispositivos, y cómo localizar lotes y usuarios afectados después de que surjan problemas, no deberían ser considerados simplemente como trabajo de gestión de canales.

Porque para un dispositivo de hardware que protege claves privadas, el proceso de entrega en sí es parte del sistema de seguridad.

Por supuesto, para los usuarios comunes, no podemos auditar la cadena de suministro de software de la billetera, ni investigar cada etapa de almacenamiento y logística de la billetera de hardware uno por uno.

Pero esto no significa que solo podamos asumir riesgos pasivamente; al menos hay algunas cosas que vale la pena cultivar como hábitos en el uso diario.

Primero, minimiza los intermediarios innecesarios en el proceso de compra de la billetera de hardware.

Si es posible, elige hacer el pedido directamente en el sitio web de la marca, con envío directo desde la fábrica o almacén oficial, lo que generalmente puede reducir las oportunidades de que el dispositivo sea manipulado, desmontado o cambiado por terceros después de salir del control del fabricante.

Desde la perspectiva de gestión de riesgos, cuanto más independientes sean los sujetos que tengan contacto con el dispositivo, más pasos de confianza adicionales se requerirán; además, después de recibir el dispositivo, aún se debe verificar si hay anomalías en el empaque y la apariencia, utilizar software oficial para completar la verificación y seguir estrictamente el proceso de inicialización.

En segundo lugar, es necesario reinterpretar si "los mensajes oficiales" son confiables.

El incidente de Trezor ya ha demostrado que incluso si el correo se envía a través de la plataforma de servicio oficial, no significa que los enlaces y las solicitudes de acción sean necesariamente seguros.

Particularmente en operaciones sensibles que involucran actualizaciones de billetera, congelación de cuentas, migración de activos, reparación de vulnerabilidades, es mejor no hacer clic directamente en los enlaces dentro del mensaje, sino verificar proactivamente a través de la dirección oficial que has guardado o la aplicación oficial que ya tienes instalada.

Para billeteras no custodiadas como imToken, los usuarios también deben asegurarse de utilizar los canales oficiales, descargar e instalar desde token.im, y en caso de recibir información anómala, verificar primero a través de los accesos oficiales como "Ayuda y Retroalimentación" dentro de la aplicación.

No importa si la otra parte se presenta como servicio al cliente oficial, equipo de seguridad, o proporciona explicaciones de vulnerabilidades que parecen muy profesionales, nunca se debe revelar las palabras de recuperación o las claves privadas.

Finalmente, es importante distinguir el impacto real de diferentes incidentes de seguridad en uno mismo.

La filtración de direcciones de correo electrónico significa principalmente que en el futuro se pueden enfrentar más ataques de phishing dirigidos; hacer clic en enlaces sospechosos requiere confirmar si se descargó o ejecutó un programa malicioso; si ya se ingresaron palabras de recuperación, se debe tratar inmediatamente como una posible pérdida de control de la billetera.

Si se han firmado transacciones o autorizaciones sospechosas, también se debe evaluar en función de las operaciones en la cadena específicas, para determinar si existe un riesgo continuo de autorización de contratos.

En cuanto a fallos en servicios de terceros o anomalías en la infraestructura, se debe consultar el alcance de impacto revelado oficialmente para determinar si afecta a los activos propios, la disponibilidad del servicio o los ingresos.

No se puede asumir automáticamente que "los incidentes de seguridad de la billetera" significan que las claves privadas han sido comprometidas, y no se debe apresurarse a transferir activos a direcciones desconocidas debido a supuestas notificaciones de seguridad urgentes.

Después de todo, muchas veces lo que los atacantes realmente esperan no es romper la defensa técnica más sólida, sino que los usuarios, en medio del pánico, completen el último paso por sí mismos.

Reflexiones finales

En el pasado, una frase que se enfatizaba mucho en la industria de las criptomonedas era "No son tus claves, no son tus monedas".

Esta frase sigue siendo importante, ya que el control de las claves privadas determina si los usuarios pueden realmente controlar sus activos.

Pero a medida que las billeteras, intercambios y productos financieros en cadena maduran, también debemos darnos cuenta de que la protección de las claves privadas es solo una parte de todo el sistema de seguridad.

Una verdadera billetera de hardware aún puede ser manipulada físicamente durante el proceso de entrega; una notificación que proviene realmente del sistema de correo oficial también puede ser utilizada por atacantes; y una herramienta de terceros que originalmente se utilizó para mejorar la seguridad puede incluso convertirse en una puerta de entrada al sistema de fondos central.

Estos casos no significan que debamos perder la confianza en todas las billeteras y servicios externos; por el contrario, nos recuerdan a toda la industria que necesitamos extender la seguridad desde el interior de un solo producto hasta todo el proceso de la cadena de suministro, gestión de permisos, comunicación con usuarios y respuesta a emergencias.

Después de todo, un verdadero sistema de seguridad de criptomonedas maduro no solo debe garantizar que las claves privadas no se filtren fácilmente, sino que también debe asegurar que, incluso si un eslabón externo falla, todo el mecanismo aún pueda contener el riesgo en el camino, sin permitir que cruce la última línea de defensa de los activos del usuario.