miércoles, 26 de febrero de 2014

0verCheck: script para comprobar si una dirección e-mail existe o no

¡Saludos!

    Más de una vez os habrá tocado gestionar algún tipo de plataforma en la que habeis necesitado comprobar si los correos que los usuarios os han suministrado son reales, o comrpobar tras estar pescando metadatos si los correos son reales (o teneis el dumpeo de una db y quereis saber a cuales podeis mandar spam),. He visto que existen servicios online que pagando una cuota al mes permite subir un listado de correos y ellos comprueban si son existen o no, pero creo que se puede hacer lo mismo con un script sencillo.

   Mi idea es extraer el dominio a partir del correo  y comprobar a través de los DNS cual es el servidor SMTP (mirando los registros MX). Una vez que sabemos el servidor SMTP procedemos a lanzar unos sockets para conectarnos a él y proceder a intentar mandarle un e-mail a la cuenta que queremos comprobar si es válida. Mirando los códigos de respuesta, vemos que si el correo es válido nos devolverá un 250, y si no (en teoría) nos devuelve un 550.

    0verCheck implementa estos dos conceptos:



 Si os es de utilidad, comentadlo ;)

Descarga del script => https://github.com/0verl0ad/0verCheck


5 0verl0ad Labs: febrero 2014 ¡Saludos!     Más de una vez os habrá tocado gestionar algún tipo de plataforma en la que habeis n...

lunes, 24 de febrero de 2014

DNmap: Distributed nmap framwork


DNmap es un framework que permite utilizar nmap de forma distribuida (quien lo iba a imaginar viendo el título del post). Disponible en la distribución de seguridad Kali Linux, funciona mediante una arquitectura cliente-servidor por la que el primero distribuye los comandos entre los clientes permitiendo así paralelizar los distintos escaneos.

Para explicar su funcionamiento lo abordaremos desde ambas partes. En la parte del servidor tenemos el fichero de comandos que contendrá las órdenes que se irán distribuyendo, su formato es como el siguiente:


Guardamos el archivo (para el ejemplo lo llamamos comandos.txt) y ahora lanzamos el servidor:
dnmap_server -f comandos.txt -p 9999 -L log_snmap


Donde:
  • -f  indica el archivo de ordenes a distribuir entre los clientes.
  • -p indica el puerto al que se conectarán los clientes.
  • -L indica el archivo de log de la aplicación, hay que tener en cuenta que este archivo no es el mismo que almacena la salida de los comandos. 
Con esto ya tendremos al servidor esperando conexiones entrantes.

En cuanto a los distintos clientes deben ejecutar:
dnmap_client -s 192.168.0.11 -p 9999 -a pc1


Donde:
  • -s es la dirección ip del servidor, esté éste en la misa red o no.
  • -p el puerto por el que nos conectaremos al servidor. 
  • -a es un alias para identificar un cliente concreto en los logs del servidor, si no se especifica este campo aparecerá como Anonymous.
A modo de información cada cliente muestra las ordenes recibidos y que está ejecutando:


  Además también envían constantemente información al servidor de forma que este lleva un breve log sobre el funcionamiento de las otras partes:



Por último, el informe del escaneo de cada cliente se almacena localmente además de ser enviado al servidor. Por tanto, éste último reúne toda la información y la podemos encontrar en la carpeta nmap_results:



Antes de cerrar la entrada, destacar que las comunicaciones entre el cliente y el servidor se realizan mediante cifrado TLS (pudiendo especificar nosotros los certificados) lo que aporta algo de privacidad a las comunicaciones. También os ofrezco la posibilidad de ampliar la información sobre la aplicación mediante el README de ésta. 


Nos leemos en breve ;)


5 0verl0ad Labs: febrero 2014 DNmap es un framework que permite utilizar nmap de forma distribuida ( quien lo iba a imaginar ...

domingo, 16 de febrero de 2014

WordPress Backdoors III: JavaScript e infección de bases de datos

¡Saludos!

     Continúo trayendo pinceladas del PDF que estoy preparando sobre BackDoors en la plataforma WordPress.

     Cuando estuve en la WordCAMP Sevilla -con trágico resultado- en una de las conversaciones que se mantuvieron en la puerta mientras la gente fumaba hubo alguien, no recuerdo quien exactamente, que nos contó que cuando sufre un ataque en un WordPress lo que hace es hacer un backup de la base de datos, borrar todo el WordPress, instalarlo de nuevo y volver a poner el backup tal cual lo había sacado. Por lo que he podido preguntar me he dado cuenta de que al parecer esta es una práctica bastante habitual... y hace que me lleve las manos a la cabeza. ¿Por qué? Por la sencilla razón de que si el atacante tuvo acceso a la base de datos pudo colar cualquier bicho en ella.

    Si eliminas todos los archivos, y reinstalas en limpio por completo WordPress, te habrás cargado los posibles backdoors que se hubieran escondido en los archivos, pero no habrás erradicado aquellos que se encuentran autocontenidos en la DB. Cuando un usuario visita la web, en el HTML que recibe su navegador se envia texto procedente de campos dentro de la base de datos, véase por ejemplo el nombre del blog, la descripción, el usuario que ha escrito el post, etc. ¿Qué ocurriría si en ese contenido servido hubiera código JavaScript malicioso?

    Como PoC sencillo podemos utilizar WordPressa Lab. Procedemos a modificar en la tabla wp_options el valor de "home" (por poner un ejemplo, existen muchos otros campos susceptibles de ser usados), añadiendole

 "><script>alert(/0wned/)</script><a foo= 

    Para ocultar a los ojos el JS podemos añadir muchos espacios desde el final de la URL hasta que empiece el JS, de tal forma que pasará prácticamente desapercibido:





   Si únicamente queremos que afecte a los administradores (para quitar morralla) podemos editar la tabla wp_comments para añadir JS en el nombre del autor del post más reciente, de tal forma que al visitar el dashboard se le ejecute al admin el payload.

  Ahora que sabemos que cuando se vuelva a poner esa DB se va a ejecutar nuestro JS... ¿Qué hacer? Podemos contentarnos con robar las sesiones a los admins simplemente... o podemos hacerlo al estilo Max Power con BeEF




   Usando BeEF vamos a poder controlar totalmente el navegador de aquellos que visiten la web, abriendonos un abanico de posibilidades según nuestra imaginación: usar los visitantes como proxys, infectarlos con malware, escanear sus redes, extraer credenciales, geolocalizar, etc. Aetsu ya nos habló de BeEF en algun post, pero en proximas entregas entraremos más en profundidad.



Byt3z

5 0verl0ad Labs: febrero 2014 ¡Saludos!      Continúo trayendo pinceladas del PDF que estoy preparando sobre BackDoors en la pla...

jueves, 13 de febrero de 2014

GOJIRA: herramienta para auditorias en WordPress

¡Saludos!

      Hoy os quiero presentar una herramienta en la que he estado trabajando las últimas noches. Como bien sabeis aquellos que leeis este blog, estoy un pelín harto de tener que recurrir a las herramientas de otros, y siempre que puedo hacer algo por mí mismo intento que así sea. De esta forma quiero poder evitar usar WPScan, y en vez de eso, usar mi propia herramienta con casinos y furcias. Por este motivo nace Gojira.

     Claramente es inferior a WPScan y hay que mejorarla mucho, pero como solía decir un compañero de piso mío "para un pueblo sin alcalde sirve".



  Las funciones que tiene por ahora implementadas:

-Creación de un diccionario con plugins (3.000 por defecto) para realizar la enumeración a través del parámetro "--dic". Para generar el diccionario utilizo el método que publiqué el otro día. Actualmente estoy creando un diccionaro de aproximadamente 15.000 plugins ordenados por popularidad que colgaré en el Github para que os lo descargueis y no tengais que esperar mientras se genera uno nuevo en un par de horas estará  disponible.


-Detección de la versión del WordPress (parámetro "--version"). Gojira realiza utiliza tres métodos para realizar el fingerprint de la versión: buscar en el meta generator, comprobar si hay un readme.html y analizar las URLs que contiene el HTML del index.

-Extrae los usuarios registrados haciendo un bruteforce (/?author=ID), usando el mismo método que utiliza la herramienta que programé el otro día,  Dumb0

-También permite analizar el archivo robots.txt, de forma similar como lo hace Parsero .

-Enumera los plugins instalados utilizando un diccionario.

   A la herramienta le quedan muchas horas de llave inglesa puesto que el código hay que limpiarlo y simplificarlo (para muchas tareas repetitivas debo de crear subrutinas), hacer que funcione con hilos para acortar tiempo, y quisiera integrarlo con la API de Shodan para que automáticamente la búsqueda en Exploit-DB de los plugins encontrados, por si alguno es vulnerable. Partiendo de estas premisas de cosas que tengo que modificar, ¿Qué le añadiríais? ¿Qué echais en falta cuando haceis una auditoria a un WordPress y podría implementar?  Cualquier feedback es bien recibido.


El código de Gojira lo podeis encontrar aqui => https://github.com/0verl0ad/gojira . El diccionario se está creando y cuando lo termine lo subiré también.


Byt3z

5 0verl0ad Labs: febrero 2014 ¡Saludos!       Hoy os quiero presentar una herramienta en la que he estado trabajando las últimas noches. Como bien sabeis aquellos que l...

lunes, 10 de febrero de 2014

Dumb0.pl: herramienta para extraer usuarios de foros y CMS

¡Saludos!

    Estaba programando la función de extracción de usuarios de WordPress para un script que ando haciendo (en el link que pone "Herramientas" lleva al GitHub del blog, donde de vez en cuando dejamos algún script)  y me he planteado si el mismo esquema quehe  utilizado para este CMS podría aplicarlo a otros distintos, reutilizando el código. La respuesta es sí.

   Dumb0.pl es un script bastante sucio que te permite extraer los usuarios de varios foros (SMF, vBulletin, myBB, Invision Powerboard, etc.) de forma bastante simple y rápida. Se puede editar el mil maneras para mejorarlo, y añadir más foros/CMS donde usarla, pero eso ya os lo dejo a vosotros (si haceis alguna modificación, avisad y lo añado al source).

Algunos ejemplos:

1.Probando en WordPressa Lab :


2.Probando en un foro SMF:

3.Probando en XEN forums


    Además utilizando el parámetro "--log", permite colocar tu cookie de sesión por si necesitas estar registrado para poder ver los perfiles de los usuarios. El uso básico seria:

perl dumb0.pl --type=[TIPO DE FORO/CMS] --url=[URL] 

   Os aparecerá un diálogo en el que se os mostrará una prueba. En caso de que después del usuario venga algún texto, y quereis limpiarlo, copiais la parte y la pegais ahí (tal y como se observa en las imagenes de arriba). Si os da igual, podeis pulsar enter. Y sí, debería de permitir eliminar el inicio, pero me da pereza.

Descarga => https://github.com/0verl0ad/Dumb0/blob/master/Dumb0.pl

Byt3z!

5 0verl0ad Labs: febrero 2014 ¡Saludos!     Estaba programando la función de extracción de usuarios de WordPress para un script ...

domingo, 9 de febrero de 2014

Construir diccionarios para enumeración de plugins en WordPress

¡Saludos!

    A la hora de construir nuestras propias herramientas dirigidas a la enumeración de los plugins instalados en un WordPress podemos encontrarnos con la dificultad de poder construir nuestro propio diccionario con los plugins que comprobar ya que sería descabellado el intentar mirar plugin a plugin cuál es el directorio que crea para poder mandarle la petición HTTP y comprobar si existe o no. Una alternativa es usar los diccionarios utilizados por otras herramientas (como WPScan) o, la que a mí más me gusta, construir nuestro propio script que se dedique a generar de forma automática nuestro diccionario. ¿Pero de donde extraemos la info?


   La mejor solución que he encontrado es utilizar el propio buscador de WordPress.org. Normalmente (es decir, en algunos casos remotos casos no es así) la url que muestra un determinado plugin (por ejemplo la de NextGEN Gallery) tiene una estructura tipo http://wordpress.org/plugins/nextgen-gallery/ , coincidiendo lo que está en negrita con la misma porción de la URL a la que deberemos de mandar la petición HTTP a la hora de una enumeración. Si tenemos aetsuodiacentOS.com/wordpress/, mandaríamos la petición hacia aetsuodiacentOS.com/wordpress/wp-content/plugins/nextgen-gallery/. 

   Conociendo esto podemos utilizar el buscador de WordPress.org para extraer X número de plugins ordenados por popularidad. Un ejemplo de script para esta tarea:


   Utilizando este simple script se nos generaría un diccionario con una estructura tipo /ruta/====Nombre:
/contact-form-7/=====Contact Form 7
/jetpack/=====Jetpack by WordPress.com
/wordpress-seo/=====WordPress SEO by Yoast
/all-in-one-seo-pack/=====All in One SEO Pack
/google-analytics-for-wordpress/=====Google Analytics for WordPress
/wordfence/=====Wordfence Security
/wordpress-importer/=====WordPress Importer
/google-sitemap-generator/=====Google XML Sitemaps
/wp-pagenavi/=====WP-PageNavi
/akismet/=====Akismet
/captcha/=====Captcha
/woocommerce/=====WooCommerce - excelling eCommerce

  El siguiente paso sería obtener un diccionario sólo con los que poseen vulnerabilidades conocidas, parte que si requiere más trabajo manual, aunque siempre se puede hacer una primera aproximación extremadamente tosca si combinamos el escáner que va a utilizar el diccionario con la API de Shodan para hacer peticiones a Exploit-DB con los nombres de aquellos plugins encontrados, y almacenarlos en un segundo diccionario. De tal forma que nuestro diccionario de plugins vulnes vaya incrementandose  a medida que nosotros escaneamos diferentes sitios.

  O, si tienes mucho tiempo libre, hacer que busque tooodos los plugins y almacenar los resultados. De cualquier forma, es una aproximación simplemente, lo mejor seria hacerlo a mano para asegurarnos.

Byt3z!

5 0verl0ad Labs: febrero 2014 ¡Saludos!     A la hora de construir nuestras propias herramientas dirigidas a la enumeración de l...
< >