La promesa de seguridad que era solo marketing

Cuando Lenovo lanzó la línea ThinkPlus con un lector de huella digital integrado, el discurso de ventas era claro: cifrado AES-256 por hardware, protección biométrica contra accesos no autorizados, un archivo seguro para quienes transportan datos sensibles. El consumidor que compró un ThinkPlus FU100 creía que, sin la huella registrada, sus archivos eran inaccesibles. La realidad, descubierta por un investigador de seguridad, era mucho más simple — y más incómoda: era una tarjeta SD ordinaria dentro de una carcasa plástica con un sensor biométrico que, como mucho, encendía o apagaba la conexión USB del dispositivo.

La revelación salió a la luz en octubre de 2026, cuando Xusheng Li, ingeniero de ingeniería inversa de Vector 35 y desarrollador de herramientas de depuración, publicó un relato detallado en su blog HackingPassion, acompañado de una presentación en la conferencia RE//verse de marzo de 2026. Lo que Li encontró al abrir el FU100 no fue ningún circuito de criptografía dedicado — fue una tarjeta soldada a una pequeña placa de circuito, con datos en texto plano, sin ninguna capa de protección. El lector de huellas digitales hacía exactamente una cosa: decidía si el controlador USB se comunicaba con el ordenador o permanecía en silencio. En una analogía sencilla, es como poner un candado en la puerta de una caja fuerte que deja el interior perfectamente expuesto.

El descubrimiento y la respuesta de Lenovo

Li reportó la vulnerabilidad a Lenovo el 2 de agosto de 2025. La respuesta inicial de la empresa, según documentado por Tech Prolonged, fue sorprendentemente primitiva: en lugar de corregir el fallo de diseño, Lenovo simplemente pegó epoxy sobre la tarjeta SD para impedir que alguien la retirara físicamente. Esta corrección, descrita por la propia empresa en la advisory LEN-210545 como una debilidad que permite la lectura de datos por alguien con acceso físico, no resolvía el problema de raíz — solo hacía el dispositivo aún más difícil de abrir, dando una falsa sensación de seguridad.

La advisory oficial, publicada el 13 de enero de 2026 y clasificada como de alta gravedad, cubría cuatro modelos: los drives ThinkPlus FU100, FU200 y TU800, y el SSD externo TSD303. Se asignaron tres CVEs. El CVE-2025-13453 describía la vulnerabilidad primaria — cualquier persona con acceso físico al dispositivo podía leer los datos almacenados. El CVE-2025-13454 concernía al software complementario de Lenovo, que exponía información sensible del dispositivo a cualquier usuario local conectado. El CVE-2025-13455 era aún más grave: permitía que un usuario ya autenticado añadiera una nueva huella digital sin la aprobación del propietario.

La solución definitiva propuesta por Lenovo también fue inusual. En lugar de una actualización de firmware o software descargable, la empresa instruyó a los usuarios a contactar su línea de atención al cliente en China, donde un verificador de número de serie decidía si el drive sería reemplazado o actualizado presencialmente. La empresa recomendó hacer backup y limpiar el drive antes del procedimiento.

El caso del TSD303: datos cifrados, contraseña en texto plano

El SSD externo ThinkPlus TSD303 presentaba un escenario diferente, pero igualmente preocupante. A diferencia del FU100, efectivamente cifraba los datos. El punto débil estaba en el mecanismo de autenticación. Cuando el programa de Lenovo en el ordenador consultaba al drive por la contraseña, el drive devolvía la contraseña correcta a través del cable USB en texto plano. El programa luego comparaba este valor con lo que el usuario tipeaba. El paquete USB capturado por Li mostraba la contraseña de prueba en texto legible en los últimos bytes del paquete — cualquiera con un dispositivo de sniffing USB podría interceptar y leer la contraseña.

Lenovo envió a Li tres versiones de corrección para probar. En la primera, tres meses después del reporte inicial, el drive empezó a enviar un blob cifrado en lugar de la contraseña en texto plano. Li rastreó el código con un debugger y descubrió que el blob venía de SM4, un cifrador de bloques similar al AES, y su clave se derivaba de algo que parecía un timestamp. En sus pruebas, la clave era 2021012700000000 — un valor fijo y predecible.

En la segunda corrección, en diciembre de 2025, el check de contraseña se movió al propio drive. En una tercera corrección, se descubrió que la clave AES-256 era un valor fijo de 32 bytes embebido en el ejecutable del software complementario — la contraseña del usuario no tenía ninguna parte en la generación de la clave. Copiar el programa era suficiente para abrir archivos bloqueados sin saber la contraseña.

El seguimiento con IA: cinco fabricantes rotos en minutos

Lo que pudo haber sido solo un caso aislado de producto defectuoso se transformó en un estudio de caso sobre la seguridad de dispositivos de almacenamiento cifrados cuando Li volvió al tema en octubre de 2026. Esta vez, usó el OpenAI Codex, conectado a su herramienta de ingeniería inversa, y le dio un único prompt: "esta es una utilidad de cifrado de archivos, analice su sistema criptográfico y vea si es seguro".

En aproximadamente siete minutos, el Codex encontró la clave fija en el ejecutable del software de Lenovo. El programa escribía la contraseña del usuario en los logs de diagnóstico. Verificaba contraseñas con MD5. Cifraba bloques de 16 bytes uno por uno, sin vector de inicialización — lo que significaba que bloques de entrada idénticos producían salidas idénticas. La opción SM4 usaba otra clave fija. En modo rápido, archivos mayores a 1.024 bytes eran parcialmente cifrados — formatos como PDF, ZIP, PNG, JPEG, WAV y MPEG eran vulnerables.

Li luego extendió el análisis a otros cuatro fabricantes. El Codex tardó aproximadamente 10 minutos cada uno en romper el software de Netac, KakaSoft y Nexopy. El Nexopy, que vendía drives Copy Secure con protección "por hardware", usaba Triple-DES para proteger los archivos, pero la clave estaba en un archivo de configuración que cualquier copia del programa visor podía abrir, porque la app llevaba un certificado fijo de 32 bytes embebido.

Li resumió el problema en una frase: diez dispositivos compartían el mismo kit de fallos. Seis enviaban la contraseña en texto plano por USB, dos mantenían datos no cifrados en tarjetas microSD, y dos enviaban la contraseña de manera que aún permitía recuperarla. Los nombres de los otros fabricantes estaban ofuscados en las diapositivas — lo que, irónicamente, reforzaba la gravedad: el problema no era un caso aislado, era un patrón de toda la industria.

Por qué importa

La seguridad por oscuridad nunca ha sido verdadera seguridad. Lo que distingue a un sistema criptográfico real es que resiste incluso cuando el atacante conoce el algoritmo, el firmware y el software complementario — la seguridad depende exclusivamente de la clave, que solo el propietario legítimo conoce. El FU100 fallaba en todos los niveles. La contraseña era interceptable. La clave de cifrado, si existía, era fija y copiable desde el ejecutable. Los datos en sí, en el caso del FU100, ni siquiera eran cifrados.

El problema se agrava por el hecho de que los pendrives con biometría o contraseña se venden precisamente al público que más necesita protección — profesionales que manejan documentos confidenciales, personal médico con expedientes de pacientes, abogados con contratos. Si la confianza en el dispositivo es la única barrera, la seguridad se disuelve en el momento en que alguien tiene el drive en sus manos.

Los especialistas en seguridad recomiendan una regla simple: cuente un lector de huellas o pantalla de contraseña en un pendrive solo como una puerta de entrada, a menos que el fabricante demuestre que la clave de cifrado depende de ese factor de autenticación. Para archivos que realmente importan, use su propio cifrado — VeraCrypt, BitLocker To Go o gpg con AES-256 — antes de poner cualquier cosa en el dispositivo.

La pregunta que queda es si la industria de seguridad para el consumidor todavía necesita que un investigador individual, con ayuda de IA, descubra que sus productos prometen más de lo que entregan — o si es hora de que los fabricantes reconozcan que la seguridad no es un sticker en la caja.

Fuentes: Tom's Hardware, Tech Prolonged, HackingPassion

✓ Fuentes independientes cruzadas y verificadas antes de la publicación