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

Además 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 tipo de 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, que puede 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 digno de atención en tiempos recientes.

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 ruptura que los atacantes buscan.

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

Primero, desglosamos lo que le ocurrió a Ledger.

Cuando compramos billeteras de hardware, las preocupaciones son principalmente dos: recibir un producto falso o recibir un dispositivo que ha sido inicializado previamente por alguien más.

Una de las estafas más comunes en el pasado era que algunos intermediarios maliciosos generaban las palabras de recuperación, las imprimían en una tarjeta rasca y las volvían a meter en el empaque, apostando a que los nuevos usuarios no conocían las reglas y depositaban dinero directamente.

Aunque esta estafa es peligrosa, 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 palabras de recuperación que vienen en la caja.

Pero el ataque a Ledger ha llevado las cosas a un nuevo nivel. Los hackers insertaron un módulo electrónico adicional con un microcontrolador, eSIM y capacidades de comunicación celular dentro de la carcasa. Cuando el usuario inicializa la billetera por primera vez, inevitablemente tiene que leer las palabras de recuperación en la pantalla y anotarlas.

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

Lo que es más problemático es que, incluso si el dispositivo pasa la verificación de autenticidad de Genuine Check, 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 el 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 físico 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 y se infiltraron desde los "servicios de terceros" en el exterior.

Primero, veamos 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.

Esto es precisamente lo que los atacantes aprovecharon al utilizar la plataforma de marketing por correo electrónico de terceros que usa Trezor, Brevo, para que el contenido malicioso llegara a la bandeja de entrada de los usuarios 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 contacto de correos electrónicos de marketing 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 billetera.

Es importante señalar que este incidente no presenta evidencia de que la billetera de hardware de Trezor o el sistema de protección de claves privadas hayan sido comprometidos; 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 aún más difícil, ya que el correo puede provenir de un dominio oficial familiar y también puede pasar las verificaciones de autenticación de correo normales, aunque el contenido ya ha sido reemplazado por los atacantes con información de phishing.

Si el usuario decide ingresar las palabras de recuperación, un problema que originalmente era del servicio de correo de terceros podría transformarse en una pérdida real de activos.

Ahora veamos Bitget.

El 24 de septiembre, algunos monederos calientes y fríos de Bitget experimentaron transferencias de activos no autorizadas, lo que finalmente se verificó que involucraba 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 del intercambio, luego invadieron el sistema backend relacionado con la billetera, falsificaron instrucciones de retiro y eludieron las verificaciones de riesgo originales, permitiendo que las transferencias anormales entraran en el proceso 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 parece 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 se requiere que una persona firme cada transacción con la clave privada; en su lugar, debe pasar por un conjunto completo de procesos internos que incluyen verificación de cuentas, revisión de riesgos, generación de transacciones y firma de billetera.

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 interna y falsificar una instrucción 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 al sistema de ejecución de activos después de que se pierden los controles de permisos y verificación de instrucciones en la parte superior, por lo que "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 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 ciertos validadores de participación afectados. Según la actualización de 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 generen otros impactos. Las soluciones no custodiadas abordan principalmente el problema del control de activos, pero no eliminan automáticamente el riesgo operativo 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 podría 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 el riesgo operativo del servicio no son el mismo concepto.

En general, los productos de criptomonedas de hoy ya no son islas aisladas.

Las billeteras dependen de nodos RPC externos para leer datos en la cadena, de interfaces agregadas para obtener precios; los intercambios no pueden prescindir de la supervisión de seguridad externa, la verificación KYC y 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 añade una capa más de relaciones de confianza que deben ser gestionadas:

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

III. ¿Cómo pueden los productos y 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 reglas del mercado.

La verdadera prueba de la arquitectura de seguridad es minimizar 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, no debe haber "confianza por defecto" entre los sistemas internos; debe haber un estricto aislamiento de permisos y verificación cruzada independiente.

Esto también se relaciona con lo que se dice comúnmente en la arquitectura de seguridad sobre "mínimos permisos" 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 una gran transferencia no debería ser liberada solo con la instrucción de un sistema interno.

El incidente de Ledger también recuerda a los fabricantes de billeteras de hardware que la gestión de seguridad incluso necesita extenderse 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 procesos de gestión trazables, cómo detectar anomalías en el desensamblaje o reemplazo de dispositivos, y cómo localizar lotes y usuarios afectados después de que surjan problemas, no debería considerarse simplemente como un trabajo de gestión de canales.

Porque para un dispositivo 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 oficial de la marca, o que el envío provenga directamente de la fábrica o almacén oficial, lo que generalmente puede reducir las oportunidades de que el dispositivo sea tocado, desensamblado 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 tocan el dispositivo, más pasos adicionales de confianza se requieren; además, después de recibir el dispositivo, se debe verificar cualquier anomalía 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, aunque el correo se envíe a través de la plataforma de servicio utilizada oficialmente, no significa que los enlaces y las solicitudes de acción dentro sean necesariamente seguros.

Particularmente en operaciones sensibles que involucran actualizaciones de billetera, congelación de cuentas, migración de activos, correcció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 has instalado.

Para billeteras no custodiadas como imToken, los usuarios también deben asegurarse de utilizar 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, no se debe revelar la frase de recuperación o la clave privada.

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 ha descargado o ejecutado un programa malicioso; si ya se han ingresado palabras de recuperación, se debe tratar como una filtración de control de la billetera.

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

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

No se debe 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.

Porque, muchas veces, lo que los atacantes realmente esperan no es romper la defensa técnica más sólida, sino que los usuarios, en su 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, porque el control de la clave privada determina si los usuarios pueden realmente controlar sus activos de manera autónoma.

Pero a medida que las billeteras, intercambios y productos financieros en la cadena maduran, también necesitamos darnos cuenta de que la protección de 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 un conjunto de herramientas de terceros que originalmente se diseñaron para mejorar la seguridad puede incluso convertirse en la entrada al sistema de fondos centrales.

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

Porque, un sistema de seguridad de criptomonedas verdaderamente maduro no solo debe garantizar que las claves privadas no se filtren fácilmente, sino que también debe asegurarse de que, incluso si un eslabón externo falla, todo el mecanismo pueda mantener el riesgo bajo control y no permitir que cruce la última línea de defensa de los activos del usuario.