Foto: GBHackers

Cifrado USB y Codex de OpenAI: claves fijas al descubierto

El cifrado USB y Codex de OpenAI se cruzaron en una prueba incómoda: el agente de programación de OpenAI, conectado a Binary Ninja, abrió productos de cifrado USB que prometían proteger archivos con contraseña y terminó recuperando el contenido sin conocer esa contraseña. La falla no estaba en la matemática del cifrado. Estaba en las llaves, guardadas dentro del propio programa que debía protegerlas.

Xusheng Li publicó el experimento en el blog de Binary Ninja, la herramienta de ingeniería inversa de Vector 35. Li ya había roto memorias cifradas a mano a principios de año, con depuración de viaje en el tiempo, y quiso medir qué tan lejos llegaba un agente de inteligencia artificial con la misma tarea. El resultado le tomó minutos: una sola instrucción bastó para que Codex revisara el sistema criptográfico de NetacFileLock y llegara a la falla central en siete minutos.

Cifrado USB y Codex de OpenAI: la clave ya venía escrita

NetacFileLock inicializaba su cifrado AES, el Estándar de Cifrado Avanzado, con una clave fija de 32 bytes incrustada en el ejecutable. La contraseña del usuario se comprobaba por otro carril y nunca determinaba la clave real, así que cualquier persona con acceso al programa podía descifrar los archivos sin escribirla. El agente halló más desorden en la misma pasada: contraseñas anotadas en texto claro en los registros de diagnóstico, verificación con el algoritmo MD5, bloques independientes de 16 bytes sin vector de inicialización ni encadenamiento, y otra clave fija para la opción de cifrado SM4.

Un detalle que Li no había cerrado en su investigación manual también quedó resuelto. En el modo rápido, solo una fracción de cada archivo de más de 1.024 bytes quedaba cifrada, en formatos tan comunes como PDF, documentos de Office, imágenes y archivos comprimidos. Una memoria llena de documentos «protegidos» podía guardar, en la práctica, buena parte de su contenido legible para quien supiera dónde mirar.

El turno de YutianDun, de SecZure, fue peor. GBHackers reportó que el producto guardaba dos cuentas internas, Buffer y System, con contraseñas fijas que el propio investigador hizo públicas en su análisis. Ambas cuentas conservaban una copia del identificador del que se deriva la clave de los archivos, y en las dos memorias probadas ese atajo permitió abrir el contenido sin la contraseña del administrador. Li lo describió como una puerta trasera técnica, sin atribuir intención maliciosa a la empresa. La derivación de claves, rápida y con truncamiento hexadecimal, dejaba la entropía efectiva en un máximo de 64 bits.

Cuatro productos, el mismo error de diseño

KakaSoft USB Copy Protection, en su versión 5.6.0.299, ofrecía tres niveles de protección. El nivel normal ni siquiera cifraba los archivos. El nivel alto aplicaba una operación XOR a los primeros 16.385 bytes con una clave de un solo byte: 256 combinaciones posibles, un candado de juguete. El nivel máximo usaba Blowfish en modo CBC, con vector de inicialización y sal por archivo, pero la clave nacía de una semilla incrustada en el programa, no de la contraseña del usuario. Codex desarmó una variante modificada de MD5 que la empresa había alterado a mano y recuperó la contraseña interna en unos nueve minutos de análisis inicial; la demostración completa, memoria en mano, tomó 26 minutos más y seis instrucciones cortas.

DE INTERES
WordPress 7.1.1 fallos de seguridad: parche urgente para webs

Nexcopy Copy Secure, aprovisionado con Drive Wizard 1.0.81, cayó en unos diez minutos y cinco instrucciones. Su cifrado Triple-DES en modo CBC protegía los archivos, pero el visor oficial guardaba un valor fijo de 32 bytes que abría el archivo de configuración cifrado, y dentro dormían la clave de contenido y el vector de inicialización. Contraseña y verificación de la memoria solo decidían si el visor seguía funcionando. La cerradura impresionaba por fuera; la llave quedaba pegada debajo del felpudo.

Qué revisar antes de confiar una memoria cifrada

El patrón se repite en los cuatro casos y es la lección que deja el cifrado USB y Codex de OpenAI como pareja de auditoría: si la clave no nace de la contraseña del usuario, la contraseña es teatro. Quien guarda copias de declaraciones de impuestos, expedientes de clientes o respaldos de una oficina en una memoria «segura» comprada por internet debe preguntar tres cosas concretas: si la clave se deriva de su contraseña con un algoritmo lento y moderno, si el producto tiene auditorías públicas de terceros y si el fabricante publica cómo corrige fallos. Li difundió sus hallazgos sin el proceso habitual de divulgación coordinada, con un argumento práctico: actualizar o retirar memorias ya vendidas y repartidas es casi imposible.

Nada de esto convierte a Codex en una llave maestra universal. Fueron demostraciones de laboratorio, sin ataques en circulación reportados contra estos productos, y el mismo trabajo que expone el fallo sirve para auditar antes de comprar. La diferencia de fondo es el tiempo: una revisión que a un investigador le tomaba días de depuración ahora cabe en una mañana de instrucciones cortas, y los productos con llaves incrustadas quedaron sin escondite.

Fuente: Binary Ninja

Foto: GBHackers


Descubre más desde Tecnología Geek

Suscríbete y recibe las últimas entradas en tu correo electrónico.