Tras la filtración del algoritmo de SecurID el año pasado, aún no se conocía cómo se generaba la semilla inicial. Sin embargo el investigador Behrang Fouladi, de SensePost, ha publicado un estudio en el que se concreta cómo se calcula y dónde se almacena esta semilla en las versiones software de RSA SecurID. A partir de esta información, el número podría ser fácilmente clonado en un equipo ajeno al sistema de autenticación.
SecurID es uno de los productos estrella de RSA, compañía subsidiaria de EMC. Ofrece autenticación de doble factor, que consiste en complementar un PIN conocido por el usuario (“algo que se sabe“) con un número generado por un dispositivo llamado token (“algo que se tiene“). Este número cambiaría tras un intervalo de tiempo determinado. La contraseña, por tanto, sería la concatenación del PIN y el número generado pseudo-aleatoriamente.
Una implementación diferente a este sistema es la versión software, que permite utilizar un sistema de escritorio, (smartphones o incluso tablets) como dispositivo generador de tokens. Para ello, utiliza un valor llamado semilla o seed, que junto al valor del tiempo convenientemente transformado, conforma la entrada del algoritmo que genera dicho número pseudo-aleatorio.
Fouladi ha aplicado ingeniería inversa sobre el almacenamiento de los valores semilla y su protección en la versión Windows de “SecurID software token“. SecurID utiliza tokenstoreplugin.dll para relacionar un sistema operativo en una máquina concreta con el token mediante el valor DeviceSerialNumber. Este se construye a partir de dos valores relativamente fáciles de obtener en sistemas Windows: el nombre de host del sistema y el SID (SecurityIdentifier) del usuario que haya instalado la aplicación. En resumen, la expresión que lo calcula sería:
device_serial_number=Left(SHA1(host_name+user_SID+”RSA Copyright 2008″),10)
¿Y con esto bastaría?
En realidad, no para todos los escenarios. El DeviceSerialNumber sólo representa un sistema de protección ante la importación de tokens provenientes de otros sistemas.
RSA normalmente realiza la provisión del servicio a través de correo electrónico. Consiste en la descarga de un programa que, una vez instalado, lee el SID y el nombre de host de la máquina y muestra un DeviceSerialNumber, que el usuario enviará a RSA. En un segundo correo, se le proporcionará el fichero de configuración relacionado con ese DeviceSerialNumber. Un tercer correo contendría una contraseña para activar el token.
Por tanto, el único escenario posible para que este método por si sólo tenga éxito es aquel en el que un atacante remoto tuviera acceso a esta cadena de correos, ya sea física o remotamente. Una vez activado el token, este es protegido por otros sistemas anti-copia y necesitaría acciones adicionales.
La información de los tokens una vez activados se almacena en una base de datos SQLite llamada RSASecurIDStorage, totalmente accesible, pero cuyos datos sensibles (por ejemplo, la semilla) están cifrados. Se protege de la copia a través de dos valores también cifrados contenidos en la tabla PROPERTIES: DatabaseKey y CryptoChecksum.
Utilizando ingeniería inversa sobre estos, Fouladi también descubrió que relacionan la base de datos con el sistema donde se instala y su usuario, ya que para descifrar dichos valores se usa la clave maestra de ambos. Adicionalmente, la base de datos también se protege con Windows Data Protection API (DPAPI).
Pero estos dos “problemas” son eludibles por un atacante: el descifrado de datos protegidos por DPAPI es posible, usando http://dpapick.com, o simplemente usando la API CryptUnprotectData, y las claves maestras se pueden volcar desde el servicio de gestión de autenticación Windows LSASS. Así, se podría extraer el fichero de base de datos de un sistema e importarlo totalmente, con la semilla incluida, a otro dispositivo.
Pero, ¿no era esto ya posible?
Sí. Dado un número pseudo-aleatorio visto por el atacante y la hora en que se obtuvo, era posible calcular el valor devuelto por el token en un momento dado usando el algoritmo que se filtró el año pasado.
La diferencia es que, si este nuevo proceso es funcional, cualquier persona con acceso físico a la máquina que corra SecurID Software token, o que haya comprometido esta a través de un troyano o rootkit, podría extraer las claves maestras del sistema y el fichero RSASecurIDStorage y crear desde cero el token, siendo sólo necesario conocer el PIN y rompiendo la autenticación de doble factor.
Más información:
A closer look into the RSA SecureID software token
RSA SecureID software token update
una-al-dia (18/03/2011) Comprometen la seguridad de RSA y roban información sobre el producto SecurID
Francisco López
Deja un comentario