Me gustaría compartir con vosotros unas reflexiones sobre el uso de ataques a cliente hoy en día en las pruebas de “Ethical Hacking”. Lo primero de todo es aclarar que cuando hablo de ataque a cliente me refiero a pruebas diseñas explícitamente para atacar al usuario final de una organización, donde estas pruebas o ataques pueden buscar cualquier usuario de la organización o buscar determinados perfiles (ataques dirigidos), como administradores de sistemas, directivos, responsables del departamento de compras, etcétera. Además, estas pruebas o ataques combinan ingeniería social y técnicas de explotación de software cliente para conseguir objetivo.

Una vez introducido el concepto de “ataque a cliente”, desde mi punto de vista no incluir este tipo de pruebas dentro de la batería de pruebas de un “Ethical Hacking” significa que no estamos poniendo a prueba nuestra organización frente a la vía principal de infección y ataque en la actualidad. Normalmente se contemplan pruebas sobre nuestras aplicaciones Web, sobre nuestro sistemas situados en el perímetro y sobre nuestra red interna; estas pruebas son totalmente necesarias, pero me pregunto ¿son suficientes? ¿nos hemos puesto a prueba realmente? Podemos estar aplicando muchas medidas de seguridad a diferentes niveles pero, ¿son efectivas ante un ataque a cliente?

En esta pequeña entrada me gustaría comentaros un detalle interesante, que dentro de la fase de information gathering (N. del E. véase el informe sobre este tema que Josemi y Borja Merino publicaron hace unos días) a alguno le puede llegar a ser de utilidad. El otro día estaba haciendo una revisión de una aplicación Web y dentro de la fase de “Testing for web Application Fingerprint” (OWASP-IG-004) me encontré que el servidor Web en cuestión me devolvía en la cabecera HTTP Server el texto “Apache”.

HTTP/1.1 200 OK
Date: Wed, 23 Nov 2011 15:50:43 GMT
Server: Apache
Content-Language: es-ES
Content-Type: text/html;charset=UTF-8
Content-Length: 57942

En entradas previas hemos visto qué era UMO y una pequeña guía de cómo instalarlo, por lo que ha llegado el momento de ver algunos ejemplos de cómo usarlo y donde puede ayudarnos.

Antes de empezar me gustaría comentaros que se han eliminado los ficheros de la sección de descargas donde estaba la versión empaquetada en tar.gz y es necesario por el momento descargarlo vía un cliente de subversión, tal que así, “svn checkout http://umo.googlecode.com/svn/ umo-read-only”. Añadir también que si os encontráis problemas en el uso de la librería MySQLDb con la librería para Safebrowsing en python, deciros que he propuesto un pequeño cambio en el issue 11 del proyecto para que no dé problemas.

Supongo que a muchos de ustedes les sonarán las reglas de Emerging Threats y sobretodo les sonarán el conjunto de reglas de la archiconocida “Russian Business Network” (RBN), sobretodo si disponen de sus sondas NIDS en un entorno mediano/grande, con gran cantidad de tráfico, donde por regla general suelen hacer acto de presencia. Estas reglas para el que no las conozcan alertan de conexiones realizadas o recibidas de direcciones de red que han sido clasificadas como maliciosas, sospechosas, peligrosas o similar. Este listado se actualizada de manera diaria, por lo menos en Emerging Threats, por lo que es bastante recomendable que nosotros también actualicemos este conjunto de reglas a la par que la fuente, ya que es un grupo bastante dinámico.

Estas reglas son muy útiles y no lo vamos a negar, ya que son un indicador que nos alerta de que existen conexiones sospechosas, desde orígenes o hacia destinos sospechosos; y lo que aportan merece la pena. Pero por otro lado, hemos podido comprobar que generan falsos positivos ciertos segmentos de red que están incluidos y que se han producido tras una simple navegación de un usuario.

Una vez presentada UMO en una entrada anterior, vamos a ver con un poco más de detalle cómo desplegarla para empezar a jugar con ella. Se ha probado la herramienta en un sistema con GNU/Linux Debian Squeeze y se ha utilizado Python 2.6.6.

Lo primero es descargar la herramienta:

Una vez descargada la descomprimimos:

Me gustaría en esta breve entrada presentaros a Url Malware Owned (UMO), una mini herramienta hecha en Python. Como podéis ver en el título se trata de la versión Beta 0.1; espero sobretodo en las siguientes versiones ir puliendola y darle estabilidad, como principal objetivo. UMO nace para poder detectar enlaces maliciosos. Las funcionalidades por el momento implementadas son:

• Permite recopilar enlaces a través de una consulta a Google y Bing.
• Permite hacer “crawling” de una página Web concreta.
• Permite analizar un enlace que creamos puede estar comprometido.
• Estos enlaces recopilados de diversas maneras, se buscan en la base de datos en local del safebrowsing de Google. Si se encuentran el enlace ha sido registrado por Google y lo tiene indexado.
• Permite actualizar la base de datos de Google Safebrowsing.
• La salida de la aplicación es un fichero con los enlaces maliciosos.

La aplicación ha sido sobre todo basada en el código de la aplicación fimap (descubierta a través de la librería xgoogle en su README, ¡gracias!), a cuyo desarrollador quiero agradecer la gran labor realizada en la aplicación, ya que me ha permitido en poco tiempo iniciar esta aplicación que va orientada a descubrir enlaces con malware en vez de vulnerabilidades de Remote File Inclusion :)

En una próxima entrada mostraré cómo instalar UMO, sus dependencias y cómo ejecutarla, de modo que sea más fácil su puesta en marcha. Por otro lado, si alguien se anima a probarla, cualquier fallo que detectéis os agradeceré mucho que me lo comuniquéis, bien en un comentario, bien a través de la dirección de correo indicada en los ficheros de umo. Además, si alguien echa de menos determinada funcionalidad, pero no la ve en el TODO (ahora mismo algo escaso), también será bien recibida.

Como espera cualquiera que inicia un proyecto de este tipo, espero que os sea de utilidad aunque sea “cachito”.

En estos días que corren está sonando mucho para lo bueno y para lo malo el servicio “pastebin.com”. Este servicio se utiliza para pegar texto, un servicio sencillo como la vida misma :).

Como no podía ser de otra manera el servicio está siendo utilizado para subir todo tipo de contenido: dumps de base datos de terceros tomadas sin pedir permiso, usuarios, contraseñas, código fuente de aplicaciones, listados de proxys, configuraciones de botnets, etcétera. Otra de las cosas destacables, es el hecho de que el servicio lo usan determinados keyloggers para almacenar lo que van capturando, como os mostramos a continuación:

Esto no es algo novedoso como se puede leer en en thetechherald y hackhispano. Pero nos gustaría volver a resaltarlo dado que se sigue registrando contenido actualmente por keyloggers.

Aconsejamos por tanto en la medida de lo posible monitorizar este tipo de servicios, dado que la información pública en ellos es de lo más variopinta. Para esta monitorización os aconsejamos herramientas como Pastenum.

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.