Un error frecuente de muchos usuarios es pensar que no son objetivo de ningún atante (¿a quién podría interesar mi cuenta?). Lo cierto es que es posible que no seamos nada interesantes pero aún así nuestras cuentas puedan ser utilizadas como vía de acceso a otros recursos o personas y por eso hay que mentalizarse y concienciar a los usuarios.

El dato viene de 21% of users think their passwords are of no value to criminals y nos recuerda que las contraseñas son el paso necesario para obtener nuestros datos, información privada e incluso nuestro dinero. Muchas veces toda esta información está disponible gracias a las alertas y avisos que llegan a nuestra cuenta de correo. Incluso aunque no seamos famosos, un atacante puede estar interesado en alguna de nuestras propiedades (virtuales o físicas). También puede utilizarnos como puente para acceder a otros.

En este sentido puede ser una buena lectura el artículo que puede descargarse en Handcrafted Fraud and Extortion: Manual Account Hijacking in the Wild donde nos cuentan el proceso de un atacante cuando consigue las credenciales de una cuenta: formas de ataque, explotación, …

El trabajo se hizo con datos de Google:

We observe an average of 9 incidents per million Google users per day.

y habla de cómo se roban credenciales, cómo se monetiza ese robo y también (aunque para este caso es menos interesante) lo que hacen en la empresa para devolver el control al usuario.

Las técnicas de robo son las que podemos imaginar:

This can occur in a multitude of ways: phishing a user’s credentials; installing malware on the victim’s machine to steal credentials; or guessing a victim’s password. Overall we find corroborating evidence throughout our measurements that phishing is likely to be the main way hijackers compromise user accounts.

Una vez obtenidas estas credenciales se pasa al prefilado del usuario: ver qué hay interesante en la cuenta.

The account profiling part where the hijacker decides on a concrete exploitation plan and the exploitation itself.
The existence of this profiling phase is one of the most surprising insights we gained by fighting manual hijackers. Instead of blindly exploiting every account, hijackers take on average 3 minutes to assess the value of the account before deciding to proceed.

El resultado puede ser que nuestra cuenta termine siendo considerada poco valiosa (y abandonada), que encuentren algún objetivo de interés, o que intenten exteorsionarnos (pidiéndonos un rescate).

El phishing normalmente llegaría a través de mensajes de correo electrónico.

Finalmente habla de una cierta profesionalización de estos ataques: los atacantes parecen tener sus horarios, protocolos de actuación e incluso utilizan herramientas comunes.

Hace no mucho parecía que POP iba a ser el protocolo preferido para el correo. Sin embargo, con la movilidad permanente y la necesidad de consultar nuestro correo en cualquier parte parece que todo ha cambiado y las soluciones preferidas son los sistemas de correo basados en proveedores con sus aplicaciones (y típicamente su reflejo en webmail para el escritorio. Si nuestro proveedor no tiene aplicación, parece que la solución más adecuada es el IMAP. POP estaba orientado a la descarga, e IMAP estaba pensando para que el correo permaneciera en el servidor y se accediera a él mediante conexión.

A mi me gusta seguir viviendo la ficción de que una parte de mi correo es más o menos privada y eso pasa por usar los servidores del trabajo (o de un proveedor privado) con algunos inconvenientes: por un lado, malas herramientas de filtrado y gestión del correo; por otra parte, limitaciones en el espacio (todavía hay otra, y es la capacidad de buscar que pude solucionar -más o menos- con mairix).

Estas limitaciones me llevaron a montar un servidorcillo de correo (lo que viene llamándose en los últimos tiempos hacer un Hillary Clinton). Empecé montando los servicios por mi cuenta hasta que probé Zentyal que no es exactamente lo que necesito (tiene muchas más cosas y está pensada para algo más grande, pero me libera de algunas tareas de gestión). Miro con simpatía iniciativas como mailinabox o el fallido -por ahora- ownmailbox. Zentyal me proporciona un sistema con SOGo, Dovecot, filtrado (pronto, espero, otra entrada específica sobre el tema), antispam (no va demasiado bien, al menos en mi experiencia) y algunas herramientas más.

De todas formas, lo que quiero presentar hoy aquí puede ser de utilidad para cualquier cuenta de correo. Se trata de borrar algunos mensajes de una carpeta IMAP basado en reglas sencillas: en nuestro caso, recibimos mensajes de diversas tareas de cron que repetitivamente (sobre todo cuando todo va bien) llegan a nuestro correo. Lo que haremos será recorrer las carpetas donde se reciben las copias de seguridad y borrarlas.

La primera tarea es buscar un poco para ver si existe algún proyecto que nos ayude en la tarea de programación. Python incluye la imaplib que permite hacer las tareas necesarias. El proceso será:

1. Leer la configuración de las cuentas que vamos a examinar
2. Solicitar las contraseñas
3. Seleccionar los mensajes y borrarlos

Además, para añadirle un poco de gracia a la cosa hemos añadido un uso muy básico de threading de manera que se hace el borrado de manera concurrente en las cuentas que haya configuradas. El código de la versión actual del programita se puede encontrar en deleteCronMesgs.py.

Comenzamos leyendo la configuración

config = ConfigParser.ConfigParser()
config.read([os.path.expanduser('~/IMAP.cfg')])

En este fichero está la información de las cuentas de correo, tantas como sea necesario:

[IMAP1]
server:imap.server.com
user:myAccount@server.com
[IMAP2]
server:imap.otherServer.com
user:myUsername

Ahora recorremos las cuentas configuradas y pedimos la contraseña (se podrían poner también en el fichero de configuración pero no termino de sentirme confortable con eso)

for section in config.sections():
	SERVER = config.get(section, 'server')
	USER   = config.get(section, 'user')

	print SERVER
	PASSWORD = getpass.getpass()

El código para borrar los mensajes se encuentra en la función mailFolder y para ello realiza los siguientes pasos:

Primero nos conectamos al servidor, con los datos leídos del fichero de configuración y del teclado.

	M = imaplib.IMAP4_SSL(SERVER)
	M.login(USER , password)

Seleccionamos la carpeta sobre la que vamos a trabajar (en este caso el INBOX) y en ella buscamos los mensajes que nos interesan (los que contienen la cadena ‘Cron Daemon’ en el campo ‘FROM’):

	M.select()
	typ,data = M.search(None,'FROM', 'Cron Daemon')

En search se devuelven dos valores, el estado (¿ha ido todo bien?) y una lista que contiene una cadena de caracteres con los números que identifican a los mensajes que cumplen las condiciones de búsqueda.

Ahora, para borrarlos recorremos la lista y actualizamos la marca (flag) para que refleje la condición de borrado:

	if data[0]: 
		for num in data[0].split():
			M.store(num, '+FLAGS', '\\Deleted')

Además hemos incluido código para ir contando cuántos mensajes borramos y mostrar una actualización cada diez (que no mostramos aquí). Finalmente, cerramos la conexión y terminamos:

	M.close()
	M.logout()

La parte concurrente es muy sencilla, consta de tres pasos.

Para cada cuenta de correo se crea un hilo:

	t = threading.Thread(target=mailFolder, args=(SERVER, USER, PASSWORD,space*i))

En target está la función que se ejecutará cuando se active el hilo y en args los parámetros de esa función.

Ahora acivamos los hilos (hemos separado la creación de la activación para que no haya interferencias de la salida que refleja la actividad con la entrada; podríamos prescindir de la realmientación y lanzarlas sobre la marcha):

for t in threads:
	t.start()

Finalmente, necesitamos esperar a que terminen los hilos, con un par de instrucciones como:

for t in threads:
	t.join()

Siguientes pasos: no tengo claro que el código de los hilos vaya a sobrevivir. Estuvo bien recordar un poquito (¡muy poquito!) de concurrencia pero en este caso no tiene demasiado interés. Tendría sentido poder incluir más reglas de borrado para otros mensajes e incluirlo en la configuración en lugar de en el propio código (por ejemplo, una lista de cademas para buscar o incluso algo más sofisticado).

También me gustaría explorar sistemas alternativos de autentificación (GMail permite utilizar OAuth, si no me equivoco). Como mínimo, poder tener la contraseña cifrada en el fichero de configuración y tener sólo una contraseña manestra.

¿Ideas? ¿Comentarios? Estaremos escuchando en @mbpfernand0 o en @fernand0.

Actualización (2015-12-07) quise terminar esta entrada rápido y olvidé otro ejemplo que tengo a mano. En este caso se trataría de borrar basado en el contenido. Recibimos ciertos mensajes repetidos que querríamos eliminar de nuestras coias de seguridad. Para examinar el contenido de los mensajes utilizaríamos:

	typ, data = M.fetch(num, '(BODY.PEEK[TEXT])')

Para determinar si el mensaje en cuestión es repetido, calculamos el hash (que tenemos precalculado) y lo comparamos:

	m = hashlib.md5()
	m.update(data[0][1])	
	if (binascii.hexlify(m.digest())==HASH):
		M.store(num, '+FLAGS', '\\Deleted')
		i = i + 1

En Deterministic Doom hace la prueba de eliminar la aleatoriedad del conocido juego Doom. Para ello, primero observa que el juego no utiliza ninguna fuente de aleatoriedad externa, sino que incluye una tabla de valores de donde se toman los valores para diversas acciones en el juego:

Rather than consume system randomness, Doom has a fixed 256-value random number table from which numbers are pulled by aspects of the game logic

Por otra parte, los efectos son los que uno podría imaginar (y algunos otros): desde el comportamiento de los atacantes a diversos efectos de imagen, pasando por las armas que se utilizan.

Prueba con distintos valores, por ejemplo:

With 0x00, monsters never make their idle noises (breathing etc.) On the other hand, with 0xFF, they always do: so often, that each sample collides with the previous one, and you just get a sort-of monster drone. This is quite overwhelming with even a small pack of monsters.

Curioso.

Es un tema recurrente hablar sobre el mito de los miles de ojos mirando. Ni en código abierto Bugs con una larga historia. El caso de LZO ni, por supuesto, en código propietario (supuestamente profesionalmente controlado).

Traemos esta vez un fallo con casi 20 años, 18-year-old bug can be exploited to steal credentials of Windows users en el que no entraremos en los detalles técnicos:

A new technique for exploiting an 18-year-old bug in Windows Server Message Block (SMB), which would allow attackers to intercept user credentials, had been uncovered by Cylance researcher Brian Wallace.

Pero que muestra que a veces los fallos son muy resistentes al paso del tiempo. Y algún día se descubren.

Para los interesandos, más detalles técnicos en SPEAR: Redirect to SMB.

Desde hace tiempo tengo una idea un poco loca: en estos tiempos en los que tanto software se ejecuta directamente en un servidor y no tenemos ninguna forma de verificar lo que sucede sería interesante poder ‘certificar’ de alguna forma que el código que se ejecuta es el debido. Por ejemplo, si alguien está usando el servidor web Apache, tal vez debería ser posible en algunos casos poder verificar que efectivamente se ejecuta el código sin modificar, etc. Ya que no podemos auditar el programa que utilizamos, sería una forma de poder ver el código (que tal vez estaría disponible en algún repositorio) y estar seguros de que lo que se ejecuta es justamente lo que vemos.

Por eso me llamó la atención la propuesta/pregunta de Propuesta: ¿Un plugin para autorizar JS en cifrados online? donde se limita el problema a la ejecución de código en JavaScript:

En todos estos casos se emplea código javascript (JS) que se descarga y ejecuta en el navegador del usuario, de manera que el servidor nunca llega a conocer su pasword, desarrollándose todo el proceso de cifrado y descifrado siempre del lado del cliente.

El punto débil de este criptosistema ocurre cuando la web ve comprometida su seguridad y con ella la de su código JS, ya sea por la intervención de un programador deshonesto de la misma organización, ya sea por la intervención de terceros que pueden introducir fragmentos de código malicioso con objeto, por ejemplo, de abrir un socket durante el proceso de cifrado para capturar y enviar la clave del usuario a un determinado sitio.

No se si la propuesta ha avanzado en alguna dirección pero a lo mejor valía la pena probar.