Recientemente en el blog de Lenny Zeltser, se ha publicado una entrada donde hace referencia a un documento realizado por “CompuCom”, donde se explicaba una prueba de concepto de una técnica para identificar la distribución de un malware mediante la cabecera HTTP ETags.

En estos momentos dos de las principales fuentes para poder filtrar y prevenir la distribución a los usuarios finales es mediante listas de IPs o listados de dominios maliciosos (ver MDL por ejemplo). Pero todos sabemos que tanto las IPs como los dominios van variando de una manera muy rápida, lo que hace muy difícil la tarea de filtrar y prevenir la distribución en base a estos listados.

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.

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.

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:

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.

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.

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.

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.

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: