Cualquier usuario con acceso a un dispositivo iKey puede leer y
escribir cualquier información almacenada en su interior, sin necesidad
de introducir el PIN del usuario.
iKey es un dispositivo USB de la empresa Rainbow Technologies, ideado
para actuar como “testigo” o “token” y almacenar en su interior
certificados, claves de acceso, credenciales y demás información
confidencial que pueda poseer un usuario. Dicha información está
teóricamente protegida por una clave personal, pero en la práctica
todos los datos del usuario son accesibles si se utiliza una clave
administrativa. Dicha clave administrativa puede ser grabada por el
atacante, por lo que éste puede programar el dispositivo iKey para
responder a la clave administrativa que desee y, por tanto,
proporcionarle acceso total al mismo.
Para realizar estas operaciones, el atacante necesita desmontar y
reprogramar el iKey, tarea sencilla y barata, tan sólo necesita
materiales accesibles a cualquier persona.
La clave administrativa por defecto es “rainbow” (el nombre del
fabricante), y su valor se almacena codificado con el algoritmo de hash
MD5. Sólo se utilizan los 8 bytes superiores del hash, que se almacenan
“codificados” en la memoria externa de iKey. Dicha codificación es muy
sencilla:
Sean a1..a8 los 8 primeros bytes del hash MD5, los 8 bytes
“codificados” resultantes son:
b1 = a1 XOR 0x1F
b2 = a2 XOR (a1 + 0x01)
b3 = a3 XOR 0x0F
b4 = a4 XOR (a3 + 0x10)
b5 = a5 XOR 0x1F
b6 = a6 XOR (a5 + 0x07)
b7 = a7 XOR 0x0F
b8 = a8 XOR (a7 + 0xF3)
Así pues, un atacante que desease grabar una nueva clave administrativa
de su elección, solo tendría que:
1. Calcular el hash MD5 de dicha clave.
2. Tomar los 8 primeros bytes del hash.
3. “Codificar” esos 8 bytes utilizando las fórmulas anteriores.
4. Almacenar esa codificación en la memoria, a partir de la posición 8.
Otro ataque posible es acceder a iKey mediante el HASH MD5 de la clave
administrativa original. Para ello:
1. Se lee el hash codificado de la memoria de iKey
2. Recuperamos los 8 primeros bytes del hash original utilizando las
fórmulas *inversas* a las indicadas con anterioridad.
3. Suministramos a iKey el valor de dicho hash (para lo cual hay que
utilizar “drivers” específicos).
Esto es posible porque a iKey sólo se le envía el hash MD5 de la clave,
no la clave en sí.
Este ataque es similar al encontrado hace unos meses para el testigo
“eToken” de Aladdin.
jcea@hispasec.com
Más información:
iKey 1000 Administrator Access and Data Compromise:
http://www.l0pht.com/advisories/ikey-admin.txt
Ataque físico a Aladdin eToken 3.3.3.x:
http://www.hispasec.com/unaaldia.asp?id=562
Deja un comentario