Debilidades en los sistemas de restitución de credenciales

Casi siempre cuando hablamos de Seguridad, y más aún de Seguridad Informática, es común escuchar que “una cadena es tan fuerte como su eslabón más débil”. Sí, es casi un cliché, pero no por eso deja de ser verdad.

Con lo omnipresencia de las grandes empresas de servicios de correo gratuito, y con los servicios plus que cada una ofrece (e.g.: calendario, Web disk, Mensajería instantánea, etc.), es común ver cómo la gente protege paranoicamente su cuenta, ya no sólo de correo sino de servicios. Perder la cuenta de correo que usas desde la Universidad o el colegio es peor que perder a tu novia tus tarjetas bancarias, dependiendo de cómo perdiste el acceso a tu cuenta, recuperarla podría ser más complicado que reponer las tarjetas perdidas. Por esta razón, las grandes compañías de servicio de correo electrónico gratuito como Gmail, Hotmail o Yahoo, agregan mecanismos multifactoriales para la recuperación de la cuenta (e.g.: preguntas de seguridad, números telefónicos y cuentas de correo secundarias.) Ahora bien, así como agregan mecanismos varios para la recuperación de la cuenta, también fortalecen los mecanismos de ingreso porque para muchos que nos movemos en el mundo de la seguridad depender únicamente de una clave pareciera ser insuficiente, razón por la cual Gmail agrega, por ejemplo, su doble factor de autenticación.

A propósito de la reciente vulnerabilidad que se encontró en Hotmail, Yahoo y AOL, la cual permitía a cualquier usuario con medianos conocimientos técnicos resetear la clave de cualquiera de estas cuentas, me di a la tarea de reflexionar sobre los mecanismos disponibles para la recuperación de contraseñas en varias de las empresas más grandes que ofrecen este servicio gratuitamente. Una de las opciones que comparten prácticamente todas ellas es la opción de envío de restitución de credenciales a través de un correo secundario previamente asociado por el usuario. El mecanismo en sí es muy lógico, si nos manejamos en un mundo virtual donde el correo es prácticamente la llave de entrada a tu(s) identidad(es) digital(es), es razonable pensar que debes tener más de una cuenta de correo habilitada, y la posibilidad de perder el acceso simultáneamente a ambas cuentas no debería ser algo tan común. No obstante, estos mecanismo de recuperación de contraseñas en términos prácticos representan otra puerta de entrada al correo, y en seguridad, entre más puertas tengas, más puertas tienes que cuidar.

Imaginemos que un usuario A está interesado en ingresar desautorizadamente a la cuenta de un usuario B. Este usuario B tiene su cuenta de correo en Gmail y lo ampara una contraseña irrompible de 16 caracteres combinados entre números, letras y símbolos especiales. Imaginemos también que este usuario A sólo conoce algunos datos básicos del usuario B, datos como el lugar de trabajo, algunos amigos, algunas aficiones, y cualquier detalle que se pueda encontrar en un perfil descuidado de Facebook. Este usuario B tiene como cuenta secundaria asociada la cuenta de correo de su empresa y las preguntas de seguridad convencionales que cualquier usuario podría configurar. Si el usuario A prepara su ataque descartará como primera opción hacer un ataque de fuerza bruta a Gmail, ya sabemos que desde hace años y con la implementación de los validadores de Recaptcha estos ataques se han complicado, en el caso de que aún así decida efectuarlo no le funcionará porque ya sabemos que la contraseña es robusta.

También podría pensar en un ataque más a largo plazo analizando la plataforma de Gmail haciendo recolección de información técnica, escaneo de puertos, análisis de paquetes de red, y cualquier estrategia que busque hallar debilidades en los sistemas de seguridad de Google, lo cual seguramente no le será fácil y mucho menos le garantizará el éxito de la operación. Adivinar las preguntas de seguridad son una posibilidad, sin embargo, se requiere conocer muy bien a la víctima para poder tener acertar la respuesta, al fin de cuenta, cuando se configura la pregunta secreta siempre se está pensando en algo que sólo conozcamos nosotros, al menos debería ser así.

Como tercera y última opción le queda comprometer la cuenta secundaria asociada para ingresar de manera indirecta a la cuenta Gmail. El hecho de que lo logre o no ya es lo de menos, lo que podemos ver aquí es que la seguridad de Gmail es directamente proporcional a la seguridad de la segunda cuenta de correo electrónica asociada:

• Si es una cuenta Hotmail, y créanme que un gran porcentaje de asociaciones entre cuentas para recuperación de credenciales está entre Hotmail-Gmail, la seguridad de Gmail será equivalente a la seguridad de Hotmail, la cual se puso en evidencia hace pocos días tal como vimos. 
• Si la cuenta secundaria es de una empresa, la seguridad de la cuenta de Gmail (y todos sus servicios) será igual a la seguridad de la plataforma tecnológica de esa empresa. Podríamos seguir profundizando el análisis comentando que un gran porcentaje de las empresas que realizan sus implementaciones para correo corporativo no usan conexión SSL para sus usuarios, por lo que con un ataque de MITM quedarían expuestas las credenciales de todas las cuentas que ingresen. Podríamos referir otro tipo de ataques también comunes como los de SQLi el cual afecta a sistemas de correos de empresas muy importantes en la actualidad y a través del cual también se podrían comprometer las credenciales de acceso de cualquier usuario. De igual forma aplicarían los ataques de fuerza bruta para las implementaciones que carecen de Recaptcha o que no controlan el número de intentos de ingreso permitidos.

La conclusión es que si la seguridad es un punto crítico de tu plataforma, debes pensarla en todas las perspectivas y enfoques. No sirve de nada que una empresa invierta millones en tener los sistemas de IDS/IPS más robustos, los Sistemas Operativos con las últimas actualizaciones de seguridad disponibles, los sistemas de monitoreo más completos y que, la recuperación de credenciales dependan de una segunda plataforma que no controlas.

--------------------------------------------------------------

Artículo cortesía de Carlos Rondón A. @phronimos

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...

Gmail Security Center

Gmail, el servicio sobre el que pivotan otros tantos servicios de Google y que mucha gente emplea como 'cuenta principal' y tienen asociada a servicios como Twitter, Facebook o cosas mas serias como bancos, compañías telefónicas, servicios de hosting, etc.

Se podría decir que para mucha gente es su activo mas valioso en su 'ciber-vida', por lo que protegerlo debería de ser algo importante.

Hace algún tiempo liberamos una pequeña guía de seguridad para Gmail y hoy vamos a presentar una herramienta que permita monitorizar el uso de una cuenta en Gmail.

Como probablemente todo el mundo sepa, Gmail tiene de serie un histórico de uso que permite comprobar el uso reciente de la cuenta

El problema es que solo registra los 10 últimos accesos, por lo que, o tomas la sana costumbre de revisar esa información casi a diario, o probablemente perderás información. No existe forma de consultar un histórico de actividad mas allá de esos 10 últimos accesos.

Dándole un par de vueltas a esto se me ocurrió crear una herramienta que hiciese tres cosas:

• Poder generar un histórico de accesos a la cuenta virtualmente 'infinito' para consultar los accesos según fuese necesario

•  Ampliar la información que ofrece Gmail, no solo con IP / País sino también ciudad e ISP

• Tener la posibilidad de enviar alertas en función de la nueva actividad que se generase en esa cuenta (accesos)

Y la solución a esos problemas la he llamado 'Gmail Security Center' y está basada en este excelente ejemplo sobre como usar el módulo 'mechanize' en Python que he modificado para acceder a la información de actividad, añadido soporte para enviar 'tweets' para las alertas en tiempo real e incorporado el uso de Geolocalización .

# This Python file uses the following encoding: latin-1

import mechanize
import cookielib
import re
import sys
import getpass
import time
import GeoIP
import commands
import tweepy

#Twitter Auth

CONSUMER_KEY = ''
CONSUMER_SECRET = ''
ACCESS_KEY = ''
ACCESS_SECRET = ''

auth = tweepy.OAuthHandler(CONSUMER_KEY, CONSUMER_SECRET)
auth.set_access_token(ACCESS_KEY, ACCESS_SECRET)
api = tweepy.API(auth)

#Geoip

gi = GeoIP.open("GeoLiteCity.dat",GeoIP.GEOIP_STANDARD)

# Browser
br = mechanize.Browser()

# Cookie Jar
cj = cookielib.LWPCookieJar()
br.set_cookiejar(cj)

# Browser options
br.set_handle_equiv(True)
#br.set_handle_gzip(True)
br.set_handle_redirect(True)
br.set_handle_referer(True)
br.set_handle_robots(False)

# Follows refresh 0 but not hangs on refresh > 0
br.set_handle_refresh(mechanize._http.HTTPRefreshProcessor(), max_time=1)

# User-Agent (this is cheating, ok?)
br.addheaders = [('User-agent', 'Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.1) Gecko/2008071615 Fedora/3.0.1-1.fc9 Firefox/3.0.1')]

# The site we will navigate into, handling it's session
br.open('http://gmail.com')

# Select the first (index zero) form
br.select_form(nr=0)

# User credentials

print "Gmail Security Center [ Security By Default http://www.securitybydefault.com ]"

login = raw_input("Login:")
password = getpass.getpass("Password: ") 

br.form['Email'] = login
br.form['Passwd'] = password

# Login
br.submit()

req = br.click_link(text='Información detallada')
br.open(req)

ips = []

while 1==1:

    html = br.response().read()

    ipscitas = re.findall('(?:[\d]{1,3})\.(?:[\d]{1,3})\.(?:[\d]{1,3})\.(?:[\d]{1,3})', html)

    if ipscitas:
        
        for resultado in ipscitas:
        
            if not ips.count(resultado):

                ips.append(resultado)
                
                command_str = 'whois %s | grep "desc"' % resultado
        
                whoisret= commands.getoutput(command_str)
        
                whoisret = whoisret[1:-1].split('\n')
        
                m =re.search("(escr|descr):          (.+)",  whoisret[0])
        
                isp= m.group(2)
        
                gir = gi.record_by_name(resultado)
        
        
                if gir != None:
            
                    print resultado, gir['country_name'],  gir['city'], gir['region_name'], isp
                    
                    twittersend = resultado + " " + str(gir['country_name']) + " " + str(gir['city']) + " " + str(gir['region_name']) + " " + isp
                    
                    try:
                        api.send_direct_message(screen_name= '@YJesus', text = twittersend )
                        
                    except :
                
                        pass
    
    br.reload()

    time.sleep(900)

Para poder usarlo, primero debéis tener instalado en el sistema el módulo 'mechanize', lo mas fácil para instalar ese y otros módulos ajenos al core de Python es usar el comando -como root- 'easy_install' disponible en el paquete python-setuptools (al menos en Fedora)

# easy_install mechanize

Una vez instalado ese módulo, hay que dar soporte GeoIP instalando la librería en C de Maxmind y su bind a python (información para hacerlo aquí) y descargar una base de datos actualizada

Finalmente, viene la parte mas engorrosa de todo el asunto y es que Twitter, cuando forzó a usar OAuth en todo aquello que tuviese que interactuar con el, hizo que enviar tweets desde una aplicación fuese un proceso bastante laborioso. Aquí hay un tutorial bastante bueno sobre como registrar una aplicación hecha en Python para poder usar Twitter

De lo que se trata es de poder rellenar los siguientes campos en el script:

CONSUMER_KEY = ''
CONSUMER_SECRET = ''
ACCESS_KEY = ''
ACCESS_SECRET = ''

Una vez hecho eso, el script monitorizará la actividad de la cuenta GMail y cuando vea nueva actividad enviará alertas parecidas a esta:

Que serán cómodamente recibidas y procesadas vía Twitter, adicionalmente se puede sacar un histórico volcando la salida del script a un fichero

Leer más...

Guía de seguridad para Gmail

Gmail tal vez sea el gestor de correo online mas popular en cuanto a usuarios y, obviando el debate sobre si tener nuestra correspondencia alojada en servidores que no controlamos es o no una buena praxis, vamos a explicar unos cuantos consejos para fortificar nuestra cuenta Gmail.

Nos dirigimos a 'Configuración' --> 'General' y ahí debemos seleccionar la opción 'Preguntar antes de mostrar contenido externo' de forma que nos aseguramos que tendremos pleno control sobre imágenes y links que puedan llegarnos vía correo. (click para ampliar las imágenes)

El siguiente paso lo encontramos en 'Imágenes de los contactos' y debemos seleccionar 'Mostrar únicamente las imágenes que yo haya elegido para mis contactos' tal vez sea una medida un tanto paranoica, pero se han dado casos de exploits cuyo vector era el procesamiento de imágenes


Por último, punto de crucial importancia, activar las sesiones HTTPS


Seguimos por 'Reenvío y correo POP/IMAP' ahí, salvo que vayamos a usar externamente Gmail, deshabilitamos el re-envío, POP e IMAP.


Continuamos en las opciones de 'Chat'. Aquí es recomendable deshabilitar el archivado de conversaciones mantenidas en Gtalk. Bien es cierto que es igual de problemático dejar los correos en Gmail, pero si podemos limitar la exposición, mejor.

Otro punto que debemos marcar es 'Permitir sólo a las personas que he aceptado de forma explícita que chateen conmigo y que vean cuando estoy conectado' Por defecto, Gmail asume que tu deseas tener a alguien en tu lista de contactos del chat si has intercambiado algunos correos con esa persona, y ambos tenéis Gmail. A mi me ha pasado, súbitamente aparecen contactos nuevos a los que incluso me resulta violento 'entrarles' vía chat.

Siguiendo en las opciones de 'Configuración' de Gmail nos detenemos en Labs y activamos una extensión bastante útil para identificar correos autenticados de proveedores como Ebay o PayPal


La última parte de la configuración está en la parte de gestión de cuentas Google. Para localizar esta parte, nos situamos en 'Configuración' --> 'Cuentas e importación' --> 'Configurar la cuenta de Google' --> 'Configuración de tu cuenta de Google' Una vez ahí, vamos a 'Cambiar opciones de recuperación de contraseña'. Por todos es bien sabido que la famosa 'pregunta secreta' es el punto de entrada mas usado a la hora de comprometer cuentas en Webmails (véase asunto Palin o Twitter) Dado que Google ofrece opciones mas interesantes, mi consejo es que el campo de la pregunta secreta sea rellenado con caracteres aleatorios (cuanto mas mejor) e inutilizarla. Por contra, activamos la recuperación mediante segunda cuenta de correo, y también una opción francamente valiosa: recuperación por mensaje de texto (debemos proporcionar un número de móvil -evidentemente-)



Por último, me gustaría destacar algo de Gmail que me parece extremadamente útil. Por la parte de abajo, se encuentra una opción donde poder ver y contrastar las IPs y orígenes (navegador, barra google ...) que han abierto sesión en tu cuenta Google. Es muy saludable verificar con cierta frecuencia que solo IPs que has usado tu han abierto sesión en tu cuenta. (Si tienes dudas sobre una IP, puedes preguntarle a nuestro bot :)


Espero que la guia haya sido amena y útil, y aprovecho también para recomendar los posts sobre protección de dominios, Youtube y nuestro 'hardenizador' para Firefox: FFhardener

Leer más...

Google Docs y el problema de las macros, versión 2.0

En el momento que las suites de oficina Office incorporaron la posibilidad de incluir código Visual Basic como parte del documento creando las famosas 'macros', los documentos .doc .xls y compañía dejaron de ser ficheros 'sin peligro' y pasaron a ser ficheros sobre los que tener cien ojos encima como si se tratara de ficheros .exe

Con el advenimiento de las aplicaciones ofimáticas web como la archifamosa GoogleDocs era evidente que la técnica mutaría en sus formas pero no en su concepto.

¿En que han cambiado las cosas? Simplemente donde antes eran funciones escritas en Visual Basic, ahora el peligro está en los documentos que contengan código en JavaScript.

Alfredo Melloni ha descubierto que formateando debidamente funciones JavaScript en un documento GoogleDoc, se puede llegar a ejecutar código JavaScript en el navegador de la persona que esté visionando el documento.

El ataque no es nada nuevo, un XSS puro y duro, del tipo a los que hemos comentado antes por aquí, cuyo riesgo más evidente es que se puede robar la sesión de la víctima, y a la postre siendo una sesión en Google, la perdida de tu cuenta de correo electrónico en Gmail. ¿Inquietante, verdad?

A partir de ahora, cuando nos lleguen las típicas invitaciones para visitar un documento en GoogleDoc, habrá que tener las mismas precauciones que cuando interactuamos con un fichero .doc

Leer más...

Gmail + DNI-E

Recientemente tuve que darme de baja en un servicio que me requería un correo electrónico para confirmar mi baja.

Enviando el correo electrónico, pensaba en que este tipo de procedimientos, en pleno 2008, deberían ser mucho mas fiables y que desde la llegada del DNI-e, no hay demasiadas excusas para no implantar mecanismos mas seguros. Al hilo de eso y dado que soy usuario habitual de Gmail, se me pasó por la cabeza que sería genial poder emplear mi Dni-e directamente en la interface web de Gmail (hasta ahora estaba usando Thunderbird para el firmado digital). Así que me puse a ver "el estado del arte" con respecto a firmado S/MIME en Gmail, al final di con esta extensión que hace justamente lo que yo buscaba.

La extensión aun está en etapas tempranas de desarrollo y no es plenamente funcional, en concreto Si puede hacer:

• Firmar digitalmente un correo electrónico
  
• Cifrar un correo electrónico
  
• Descifrar un correo electrónico que nos haya llegado

Por contra, se echa y mucho de menos la verificación de firmas digitales, es decir, si alguien nos envía un correo firmado digitalmente no sera posible verificar la firma, ni a nivel certificado digital ni mucho menos comprobando CRLs.

Tal vez en este punto algún que otro lector este pensando en jubilar sus vetustas claves GPG y pasarse al apasionante mundo de los certificados digitales, antes de eliminar sus claves ha de saber que, el dni electrónico, provee dos certificados en el chip, Firma y Autenticación ¿que significa esto? básicamente que los certificados digitales NO están preparados par cifrar información, por tanto, con el estándar PKI en la mano, ningún certificado del DNI-e debería ser usado para cifrar correos electrónicos. Para el que se haya perdido y le resulte incongruente la situación, aclarar un par de puntos sobre certificados digitales, todos ellos contienen una clave publica y otra privada RSA plenamente funcional "para cualquier cosa" adicionalmente, cada certificado lleva inscritas sus extensiones que definen su propósito de uso y es ahí donde se define si un certificado sirve para firmar digitalmente, para autenticarse o para cifrar información (entre otras muchas opciones). En el caso del DNI-e, los certificados sirven para autenticación y firma. Obviamente tu eres libre de extraer las claves RSA de los certificados y usarlas "a pelo" para lo que te de la gana, pero estarías violando el estándar PKI

No obstante, si pretendes usar certificados digitales para cifrar y firmar correos electrónicos, Firefox tiene una extensión que te permite crear tus propios certificados a medida que deberían funcionar perfectamente con la extensión S/MIME.

Aclarado este punto, prosigo con un mini how-to usar el dni-e para firmar digitalmente correos en Gmail.

Dando por hecho que ya tienes configurado el dni-e en tu Firefox (existen ya muchos tutoriales escritos sobre el tema) esta guía debería funcionar tanto en Windows como en Linux.

La integración de Gmail S/MIME con Gmail es total, y el uso, de lo mas sencillo, una vez hayamos abierto el editor de correos para enviar un correo, podemos observar que aparece a la derecha, un símbolo de firmado (resaltado con el cuadrito en rojo), y un candado para cifrar. (las imagenes son 'clicables' para verlas completas)

Simplemente hemos de marcar esa opción para activar el firmado digital del correo, como consejo, es recomendable activar el uso de "solo texto" y de esa forma eliminar los tags HTML que pueden provocar warnings durante el procesado del correo. Una vez marcada esa casilla y escrito el texto, simplemente pulsamos enviar.

Al hacer esto, nos aparecerá una ventana indicando con cual de los dos certificados del DNI-e queremos firmar el correo, como hemos dicho antes, PKI en la mano, deberemos seleccionar el certificado de firma y no el de autenticación.

En esta ventana, habremos de introducir el PIN de nuestro DNI-e.

Si todo ha ido bien, nos aparecerá otra ventana que nos pedirá confirmación para el proceso de firmado

Una vez aceptada la ventana, se lanza el proceso de envío, que, en este caso, se hace mediante la interface SMTP de Gmail, por lo que nos pide que introduzcamos nuestra contraseña (la misma que para acceder via web a Gmail)


Si la petición de envío ha ido bien, veremos en la parte superior de Gmail un mensaje indicando que nuestro correo electrónico ha sido firmado y enviado


Espero que el tutorial os haya resultado útil y, si sois usuarios de Gmail, no tenéis excusa para no agregar a nuestro bot

Leer más...