RSA.O.S

Hace tiempo ya hablamos de la intrusión que sufrió RSA en marzo del 2011, incluso hicimos algún relato de novela negra sobre posibles consecuencias de la misma

Ahora RSA vuelve a ser noticia porque según un artículo publicado en arstechnica, los autenticadores SecurID 800 serían vulnerables y pueden romperse.

El artículo en cuestión cuenta que se pueden extraer las claves criptográficas almacenadas en la memoria de los tokens en 13 minutos y lo adorna hablando de crackeo del dispositivo. Para quienes no lo sepan estos dispositivos (a.k.a. tokens) proporcionan un número pseudo-aleatorio que está sincronizado con una parte servidora, de tal modo que a la hora de autenticarse en un equipo o aplicación solicita, además de un PIN o clave conocida por el usuario, ésta ristra de 6 dígitos que cambian cada 60 segundos.

Este sistema recibe el nombre de One-Time Password (OTP) o clave de un sólo uso. De esta forma se obtiene lo que se denomina "autenticación de doble factor", algo que sabemos (nuestro PIN) y algo que tenemos (el token). En este caso además de la funcionalidad descrita, el dispositivo incorpora otra a modo de tarjeta inteligente (gestión de certificados).

 Volviendo al tema, el ataque (consiste en dos formas ataque) está descrito en un documento que se presentará en la próxima conferencia CRYPTO 2012 que tendrá lugar en la Universidad de California en agosto y en dicho paper comentan como el problema reside en la interfaz de dispositivos criptográficos RSA PKCS#11, lo cual descartaría un problema a nivel de algoritmo OTP.

 Como respuesta, RSA ha lanzado un comunicado en el que explica que la magnitud del problema no es tal debido a que el ataque, además de no afectar a las claves privadas de los usuarios, requiere unas condiciones específicas, acceso a la máquina y poseer el PIN de usuario, por las que no se requeriría vulnerar el dispositivo para obtener la información deseada.

 En este intercambio de "dimes y diretes" aparece otro actor que da otra vuelta de tuerca al asunto. En éste último artículo se expone como los argumentos de RSA, que no contradice, son válidos hasta cierto punto, ya que las debilidades de los estándares PKCS involucrados pueden hacer alcanzar el mismo objetivo sin hacerse con las claves privadas: "it allows an attacker to decrypt and recover other “wrapped” keys encrypted by the token’s key pair.".

Del mismo modo que la implementación de la API del dispositivo criptográfico basado en PKCS #11 podría comprometer el PIN del usuario "...Some applications may proxy access to the token via a web frontend or other network access. An application may cache the PIN", por último menciona el autor que si bien PKCS #1 v2.0 with OAEP es seguro, RSA permite al usuario 'elegir' entre la versión vulnerable (1.5) y la que no contiene la vulnerabilidad  (2.0).

Para terminar, hay que mencionar que esta vulnerabilidad no solo es cosa de RSA ya que afecta a múltiples implementaciones comerciales (como Aladdin eToken PRO, Feitian epass 2000, etc.) por lo que enfocarlo a un dispositivo en concreto, parece que obedece más a una noticia sensacionalista que a otra cosa.

 Artículo cortesía de Ricardo Ramos

Leer más...

Google Authenticator 2

Habilitar autenticación de doble factor sobre nuestra cuenta de google, nos proporcionará una capa de seguridad adicional al tener que generar una clave basada en el tiempo de un sólo uso junto con nuestra contraseña habitual.

Esta es la segunda versión de Google Authenticator que nada tiene que ver con la primera. Han mejorado la seguridad y su facilidad de uso. Expondré unas pequeñas nociones de cómo funciona y su uso.

Tengo que decir, que técnicamente, sólo es necesario disponer de la clave secreta para generar la clave OTP. Aunque en la práctica, estas claves se generan en el móvil o vía sms.

La habilitación de dicha funcionalidad la encontraremos en la página principal de configuración de cuentas.

Tendremos que validar nuestro número de móvil. Nos enviarán un sms con un código que deberemos de introducir.

En el caso de que no dispongamos de Android, IOS ó Blackberry, nos queda la alternativa del sms (o generar nuestro propio OTP basado en el timestamp actual junto con la clave secreta).

Para los que tengamos un smartphone compatible, google nos proporciona un QRCode que debemos de escanearlo a través de la aplicación Google Authenticator 2, ya que almacenará la clave secreta que servirá de semilla para la generación de nuestros OTP's.

Escanear qrcode y validar.

• La url del qrcode tiene un aspecto así:
  OTPauth://tOTP/alice@google.com?secret=JBSWY3DPEHPK3PXP
• La clave secreta está compuesta en base32 y es de tipo TOPT (Time-based One-time Password).
• Deberemos introducir una clave OTP para validar la autenticación de doble factor a través del movil.
• + info https://code.google.com/p/google-authenticator/

La generación de códigos OTP en el móvil, se basan en el timestamp actual junto con la clave secreta

Google por su lado, verifica el OTP, ya que posee la clave secreta y la configuracion de nuestra fecha/hora basada en el número de móvil, que lógicamente debe coincidir con la fecha/hora de nuestro móvil (valga la redundancia).

Si está marcada la opción de recordar el equipo desde donde nos logamos, se guarda una cookie para el dominio google.com con 30 días de duración, así, cada vez que iniciemos sesión desde éste, no nos pedirá el OTP.

El OTP tiene una duración máxima de 30 segundos desde que se generó. Aclaremos esto:

• Google, debido a los desfases horarios, según mis pruebas, tiene establecido un margen de +4 y -3.5 minutos (240 y 210 segundos respectivamente) por delante y por detrás de la fecha/hora actual.
• Esto es, si tenemos el OTP 123456 generado a las 14:12:00, google calculará los OTP's correspondientes, 8 por delante y 6 por detrás respecto a la fecha/hora de logado:
• 14:16:00        234925
• 14:15:30        357532
• 14:15:00        843793
• 14:14:30        332266
• 14:14:00        234123
• 14:13:30        490645
• 14:13:00        998832
• 14:12:30        294211
• 14:12:00       123456
• 14:11:30        324483
• 14:11:00        123548
• 14:10:30        483246
• 14:10:00        678314
• 14:09:30        729603
• 14:09:00        736294
• Google comprobará si cualquiera de los OTP's generados corresponden con el introducido. 

Además de ofrecernos seguridad en el inicio de sesión de nuestra cuenta, podemos administrar contraseñas para cada uno de las aplicaciones de terceros que necesiten acceder a nuestros datos. Esto nos proporciona una capa de seguridad adicional para porteger nuestra cuenta al poder revocar estas contraseñas cuando queramos.

A continuación, os dejo un script en php para poder generar nuestros propios OTP. Los parámetros necesarios para que funcionen con la autenticación de doble factor de google son la clave secreta y una correcta configuración de la fecha/hora del sistema.

Código extraído de http://www.idontplaydarts.com/2011/07/google-totp-two-factor-authentication-for-php/

Artículo cortesía de Adrián Ruiz Bermudo 

Leer más...

Autenticación de doble factor Google: Casi perfecta

Hace algún tiempo hablamos sobre como configurar autenticación de doble factor en Apache y en Linux, por eso cuando Google lanzó este servicio, lo activé para evaluar su funcionamiento

El sistema se basa en la combinación de tu contraseña habitual + un token que se puede obtener o bien mediante una aplicación para teléfonos móviles o bien mediante un SMS.

Llevo un tiempo usando el sistema y tengo que decir que funciona francamente bien, está muy bien pensado ya que cubre la mayoría de eventualidades de las que suelen adolecer estos sistemas:

-Al activarlo, Google te da una serie de 'tokens maestros' a modo de sistema para uso en caso de emergencia.

-Durante mis pruebas, la aplicación para Android dejó de funcionar (probablemente por algún problema de sincronización horaria) y fue realmente sencillo hacer el cambio al sistema de SMS (aunque admito que cuando empezaron a fallar los tokens una gota de sudor recorrió mi frente)

No obstante, el sistema tiene, a mi parecer, una importante laguna de la que es conveniente hacer partícipe a la gente.

Una vez activado el sistema, muchas de las aplicaciones ajenas a google que acceden a sus servicios dejan de funcionar, esto es debido a que no están preparadas para trabajar con el sistema de doble autenticación.

Google, que ha pensado en todo, permite configurar contraseñas 'satélites' para usar con esas aplicaciones

Lo que permite que programas como Thunderbid o clientes de mensajería para Gtalk puedan funcionar.

El problema es que Google ha obviado lo que podría haber sido la solución perfecta: Que esas contraseñas tengan ACLs para indicar a cada contraseña que servicio puede acceder.

Al no haber hecho eso, implica que cualquiera de esas contraseñas tiene acceso pleno a todos los servicios (menos a la interface mediante página web) sin restricción alguna, y estas contraseñas son custodiadas según el mecanismo de seguridad que haya implementado el programa en cuestión. 

En muchos casos estos mecanismos dejan mucho que desear y por tanto supone que esa contraseña puede ser fácilmente robada.

Creo que esto es un fallo menor pero que desluce bastante el sistema. Que la contraseña que pretendo usar para mi cliente de mensajería tenga acceso al servicio POP y pueda acceder al correo, lo veo totalmente innecesario.

De hecho es conveniente tener claro que en el momento que se habilita una de esas contraseñas satélites, cualquiera con esa password puede acceder al correo

La solución perfecta pasa por añadir la posibilidad de definir para qué servicio se va a usar la contraseña. De esa forma, si quiero tener mi correo seguro e inaccesible salvo que se use el doble factor, puedo mantenerlo así y además definir contraseñas para acceder a servicios menos peligrosos como Gtalk o Greader.

Leer más...

Contraseñas de un solo uso en Apache

Hace unos días hablábamos de 'Contraseñas de un solo uso en Linux' y explicábamos como configurar Linux vía PAM para aceptar contraseñas temporales. Hoy le toca el turno al servidor web mas empleado en Internet: Apache.

El objetivo de este post es configurar Apache para proteger un directorio cuyo acceso sea mediante contraseñas de un solo uso, para ello vamos a emplear mod-authn-otp, que se integra perfectamente dentro de Apache.

Una vez descargado y compilado (el típico ./configure && make && make install) procedemos a configurarlo.

Lo primero es decidir cual va a ser el directorio que vamos a proteger, en este caso será el directorio 'test' localizado físicamente en /var/www/html/test/ que a su vez se mapea vía http en www.midominio.com/test

Localizamos el fichero httpd.conf (en sistemas RedHat / CentOS / Fedora /etc/httpd/conf/httpd.conf) y añadimos lo siguiente:

#Configuracion para OTP

LoadModule authn_otp_module modules/mod_authn_otp.so

<Directory "/var/www/html/test">

    AuthType basic
    AuthName "My Protected Area"
    AuthBasicProvider OTP
    Require valid-user
    OTPAuthUsersFile /etc/httpd/otp/passwd
    OTPAuthMaxOffset 4
    OTPAuthMaxLinger 1000

</Directory>

De este punto de la configuración lo más interesante son las directivas OTPAuthUsersFile OTPAuthMaxOffset y OTPAuthMaxLinger la primera sirve para indicar donde Apache encontrará el fichero con los usuarios / tokens y PINs, para explicar la segunda y la tercera requiere meter un poco de teoría sobre HOTP, que es el algoritmo que emplea mod-authn-otp (aunque también soporta mOTP, pero no lo vamos a ver en este post). Este algoritmo basado en HMAC tiene dos formas de ser empleado, o bien como algoritmo basado en 'tiempo' (es decir, para calcular el password temporal se emplea la fecha+hora del sistema) y también en formato 'evento'.

El comportamiento basado en 'tiempo' implica que la contraseña que espera el servidor se computa tomando como elemento de la fórmula la fecha del sistema y requiere que tanto cliente como servidor estén sincronizados. En el caso de 'evento' el concepto cambia y funciona de la siguiente manera:

1. Cliente y servidor empiezan en una situación de inicialización (número de contraseñas generadas 0)
2. La primera vez que el cliente quiere acceder al servidor, este genera una contraseña OTP y la suministra al servidor, cuando el servidor da por buena la contraseña, aumenta en +1 el contador de contraseñas creadas
3. La siguiente vez que el cliente accede al servidor, cuando va a generar la contraseña debe indicar que ahora ha de generar la contraseña numero 2 (la número uno ya no vale, el servidor ya NO espera esa contraseña)
4. Y así sucesivamente

Por tanto para emplear este modo requiere 'llevar la cuenta' de cual contraseña se ha de crear. Si existe un desfase entre las contraseñas que has creado y las que has enviado al servidor se puede romper la sincronización.

Explicado esto volvemos a la directriz OTPAuthMaxOffset que define el número de contraseñas de 'desfase' que va a calcular el servidor, es decir el servidor te ofrece de margen hasta 4 contraseñas (si el servidor espera la contraseña número 2 y tu envías la número 4, podrás acceder ya que cae dentro del margen)

En el caso de la directriz OTPAuthMaxLinger especifica el tiempo máximo en segundos que puede permanecer el cliente conectado al recurso del servidor sin necesidad de generar otra nueva contraseña. En función de 'que' estamos protegiendo debemos calcular este parámetro, ya que si esperamos que el cliente esté conectado mucho tiempo puede ser realmente molesto estar cada 2 x 3 calculando contraseñas si ponemos una ventana de tiempo pequeña.

Ahora vamos a explicar como crear el fichero con los usuarios / contraseñas. Mi elección para la ubicación de este fichero es /etc/httpd/otp/passwd pero puede ser cualquier otra. Creamos el fichero:

# mkdir -p /etc/httpd/otp/

# touch /etc/httpd/otp/passwd

# chown -R apache.apache /etc/httpd/otp/

A la hora de crear este fichero, echo mucho mucho en falta algún tipo de herramienta que debería formar parte de mod-authn-otp (y la documentación no es para nada evidente). El formato del fichero es el siguiente:

HOTP    sbdtest       1234    167aa8035341c4e812adce9c26a9f71c

En este caso vamos a usar auth HOTP por eventos (sin sincronización de tiempo) El primer campo es el tipo de auth que vamos a usar, el segundo el username, el tercero es el PIN y el cuarto el token/key.

Teóricamente la parte mas problemática es el token (que, según leo en la documentación, es una representación hexadecimal de un dato aleatorio binario), si usas uno de los soft tokens que recomiendan en el proyecto (hay clientes para Iphone y para Android) el token lo auto-genera el software. Como en este caso queremos usarlo utilizando la herramienta para generar OTPs de mod_authn_otp (otptool) tenemos que crear la parte del token 'a mano'.

Probablemente haya métodos mas fáciles, pero yo lo he hecho así;

Primero generamos un montón de datos binarios aleatorios y los volcamos en el fichero 'random':

# dd if=/dev/urandom of=random count=1

Luego sacamos la representación hexadecimal del fichero:

# hexdump random

Lo que nos dará una salida como:

0000000 003c 19f5 32d8 b89d c982 c854 9471 be51

0000010 b0d2 1fd7 7ddc 7612 4b85 1665 8a47 43b1

0000020 8122 12f3 3f36 5dca 4b3a 751b c0cd 97eb

0000030 12d8 01c8 2860 4176 d637 27f4 f554 61d1

0000040 6056 fd89 055f e72c 0882 0698 4797 2b21

0000050 7532 f86a 3786 1221 d28d e8dd 57c2 30c3

de ahí seleccionamos una fila, por ejemplo:

003c19f532d8b89dc982c8549471be51

Y ya tenemos nuestro token !

Por tanto podemos crear al usuario sbdtest de la siguiente forma

HOTP    sbdtest       1234    003c19f532d8b89dc982c8549471be51

En este caso el PIN es 1234 y el token, lo que anteriormente generamos. Con todo esto re-iniciamos el servidor httpd y empleando la herramienta otptool (que se compila e instala junto con mod_authn_otp), generamos nuestro primer password temporal tomando como parámetro el token:

# otptool 003c19f532d8b89dc982c8549471be51

0: 944668 61a95c

De aquí, nos quedamos con 61a95c, apuntamos nuestro navegador hacia el directorio protegido www.midominio.com/test y debería pedirnos login y password, como login --> sbdtest y como password el PIN+OTP, es decir 123461a95c

Et voila ! deberíamos haber accedido al recurso protegido

La siguiente vez que queramos acceder debemos indicar a otptool que ha de generar la siguiente contraseña con el parámetro -c 1, la siguiente vez será -c 2 y así sucesivamente:

# otptool -c 1 003c19f532d8b89dc982c8549471be51

1: 044536 8202f8

Un último apunte, como decía al principio existen soft-tokens para Iphone y Android aquí

Leer más...

Contraseñas de un solo uso en Linux

OTP son las siglas de 'One Time Password' es decir, contraseñas de un solo uso. Habitualmente empleadas en entornos con elevados requerimientos de seguridad, fueron popularizadas a través de los tokens 'RSA SecureID' como herramientas para hacer logins empleando factor doble de autenticación.

Groso modo, el sistema funciona de la siguiente manera:

• No existe un concepto de contraseña inmutable 
• Cada vez que se quiera acceder al sistema se necesita una contraseña nueva

Es decir, en cada momento el servidor espera una contraseña que va cambiando de forma que si esa contraseña fuera interceptada, apenas serviría para un corto periodo de tiempo.

Existen varias implementaciones de OTP, en este caso vamos a usar Mobile-OTP ya que se integra perfectamente en el subsistema PAM de linux y además tiene clientes para Iphone, Android o Windows mobile.

Mobile-OTP es bastante sencillo y funciona de la siguiente manera:

1. El cliente genera el valor de md5(PIN+SECRET+TIME)
2. Envía el valor al servidor
3. El servidor calcula el valor de md5(PIN+SECRET+TIME) en un intervalo de 3 minutos hacia atrás
4. Si el valor suministrado por el cliente coincide con alguno de los generados por el servidor, la autenticación será positiva

Para instalarlo necesitamos dos cosas, un cliente para generar las contraseñas y el módulo PAM para el servidor.

Como cliente, podemos usar cualquiera de los disponibles para teléfonos móviles (interesante tener el generador de tokens en el móvil) o bien un sencillo cliente hecho en Javascript que podemos ejecutar en casi cualquier navegador (e instalarlo en nuestro servidor).

Para el servidor descargamos el módulo PAM desde aquí y lo compilamos de la forma habitual:

# make

Si todo ha ido bien (necesitarás pam-devel instalado en tu sistema) se habrá creado el fichero pam_mobile_otp.so que debemos copiar en /lib/security/

# cp pam_mobile_otp.so /lib/security/

Después de eso copiamos el fichero de configuración con el listado de usuarios + PIN + Token:

# cp motp.conf /etc/security/

Un ejemplo de fichero de configuración para tener acceso OTP para el usuario root sería el siguiente:

# cat /etc/security/motp.conf

root    1234567890abcdef        1234    0

Lo que significa que el PIN del usuario root es 1234 (el módulo PAM tiene una limitación de 4 caracteres en el PIN) y su semilla 1234567890abcdef. Estos datos deben ser cambiados en tu instalación.

Con esto hecho, procedemos a configurar el servicio SSH para que acepte esta nueva fórmula de autenticación editando /etc/pam.d/sshd dejándolo así:

#%PAM-1.0

auth  sufficient /lib/security/pam_mobile_otp.so not_set_pass

password required /lib/security/pam_mobile_otp.so debug

account required /lib/security/pam_mobile_otp.so

auth       required     pam_sepermit.so

auth       include      system-auth

account    required     pam_nologin.so

account    include      system-auth

password   include      system-auth

# pam_selinux.so close should be the first session rule

session    required     pam_selinux.so close

session    required     pam_loginuid.so

# pam_selinux.so open should only be followed by sessions to be executed in the user context

session    required     pam_selinux.so open env_params

session    optional     pam_keyinit.so force revoke

session    include      system-auth

Con esta configuración seguimos aceptando autenticación 'normal' basada en contraseña mapeada en /etc/shadow y además passwords OTP. Si únicamente pretendemos aceptar contraseñas OTP podemos modificar /etc/pam.d/sshd

Una vez configurado el servidor, si volvemos a la pagina web generadora de contraseñas, podemos rellenar los campos

PIN --> 1234

Secret --> 1234567890abcdef

y nos dará como respuesta una contraseña temporal para acceder con el usuario root al sistema vía SSH.

Notas: Esta configuración ha sido probada en una Fedora Core 11. Es MUY IMPORTANTE que la hora del cliente y la del servidor estén sincronizadas, de lo contrario las contraseñas temporales NO funcionaran, asegúrate que el comando

# date +%s

devuelve valores parecidos en cliente y servidor

Leer más...