martes, 22 de julio de 2014

Create tu propio escaner de redes wifi

¡Saludos!

     Sigo entreteniendome con NodeJS y las redes wifi. En esta ocasión estaba probando  a desautenticar usuarios conectados enviando paquetes deauth, para lo cual estaba cazando las MACs con airodump-ng. Cual fue mi sorpresa cuando no me aparecía uno de mis ordenadores -el que quería echar fuera de la red- como asociado a mi AP. Como se puede apreciar en la imagen únicamente me aparece asociado 1 solo ordenador, cuando deberían de aparecerme los 3. O como mínimo otro más, pues estaba navegando por él y generando tráfico que debiera de ser detectado. Nada.






    En ese momento pensé: pues si airodump-ng no me lo está pillando, probemos a hacernos un escáner a ver si lo pillamos nosotros. Por supuesto que existen muchos escáneres geniales que podrían haberme solucionado la papeleta (o incluso simplemente usando WireShark y parseando el PCAP con un script en PERL) pero la idea es utilizar algo creado por uno mismo y de esta forma seguir aprendiendo.

    La única información que quiero obtener son el nombre de la red, su mac, y quién esta conectado, ya que es lo único que necesito para mandar el deauth. Entonces... ¿de donde sacamos esos datos?

   Lo primero que nos debería de venir a la mente son los beacons . Básicamente son frames cuya función es indicar la presencia de un punto de acceso. Se envían de forma automática contínuamente y contienen mucha información, entre ella la MAC del AP y el ESSID con el nombre de la red - es decir, gran parte de lo que necesitábamos-.

   Los beacons parece que pueden aportarnos toda la información sobre el AP y tan sólo nos quedaría buscar en otra parte quien está asociado, pero... ¿nos quedamos sólo con este frame? La respuesta es un rotundo NO. No podemos recopilar datos únicamente de los beacons porque si la red se encuentra oculta éstos van con el ESSID vacío, de tal forma que no podríamos ver el nombre de la red. Luego toca buscar dónde más aparece el ESSID.




   Y nuestra respuesta está en los probe response  frames. Cuando un AP recibe un probe request, ésta va a responderle con un probe response donde vendrá el ESSID -y disfruten de esto- que no es ocultado. En los probe request también puede aparecer la red, pero no los utilizaremos porque cuando un equipo tiene guardada una red oculta, éste envía contínuamente probe request para ver si ese AP está disponible. Incluso si la red está totalmente fuera del alcance. Es decir, contínuamente está preguntando "¿Está la red Sífilis aqui? ¿Está la red Sifilis aquí?" , por lo que si utilizásemos estos frames podríamos creer que existe una red cuando en realidad no está ni cerca: simplemente hemos pillado a un ordenador preguntando.


  ¡Ya sólo nos queda averiguar quien está asociado a cada AP! Tras mirar unos cuantos minutos capturas de WireShark concluí que los paquetes RTS podrían ser un buen candidato del que obtener información: aparecen tanto la dirección de quien envía el paquete como de quien la recibe, por lo que tan sólo nos quedaría correlar esta información con el listado de AP que obtenemos de los beacons y probe response y mostrarla.

   El resultado final es este:




  Ahora sí estamos pillando los  3 ordenadores que estaban conectados en esa red. Si os fijais la tercera red que se muestra tiene el nombre vacío debido a que se trata de una red oculta (el beacon tenia el nombre vacio) pero sin embargo justo debajo aparece su nombre (0verl0ad). Ésto es debido a que ha conseguido extraer la información  de los probe response.

  En caso de que no hubiese nadie mandando probe request (para que responda) no podríamos saber el nombre real de la red...pero sí la longitud del ESSID. Eso significa que podremos bruteforcearlo con probe requests hastsa que obtengamos un probe response que nos indique que el string era el correcto (este es el siguiente script que tengo en mente ).


  Vuelvo a repetir lo que dice al inicio, existen múltiples escáneres que podría haber usado, la idea era simplemente jugar un rato y solventar un problema.

 El script lo dejo en el GitHub del blog ( https://github.com/0verl0ad/wifi-scan-js ) . Los requisitos para usarlo son los mismos que para AP-Flooder ( http://blog.0verl0ad.com/2014/07/ap-flooder-inundandolo-todo-con-puntos.html ). Una vez teniendo los requisitos tan sólo ejecutar "node wifi-scan" y con el navegador ir a localhost:777. Refrescad el navegador para actualizar los datos obtenidos.



Byt3z!

5 0verl0ad Labs: julio 2014 ¡Saludos!      Sigo entreteniendome con NodeJS y las redes wifi. En esta ocasión estaba probando  ...

lunes, 14 de julio de 2014

AP-flooder: inundandolo todo con puntos de acceso ficticios

¡Saludos!

   Llevo apenas dos días trasteando en serio con nodeJS y me está gustando mucho. Para matar dos pájaros de un tiro también me he puesto a tontear con el 802.11. Durante el partido de anoche hice este script para realizar un flooding.

  Utilizando la librería PCAP enviamos beacons con los ESSID que queramos (guardamos los nombres en un .txt) de tal forma que los usuarios que haya cerca nuestra al comprobar las redes disponibles, verán cientos de nombres.

    El beacon que se manda es uno prefabricado (cogido con Wireshark de una red cercana) al cual le he quitado la parte del length del ESSID, y el propio ESSID, de tal forma que en el beacon final que es enviado es añadido estas partes en base al .txt donde hayamos guardado los nombres.

  Para usarlo necesitamos estar en modo monitor (en mi caso uso  wlan0 ):

airmon-ng start wlan0

Y a continuación ejecutamso el script:
node AP-flooder interface list.txt

Siendo la interfaz aquella que está en monitor y lista el archivo .txt que contiene los nombres. Aquí una muestra del flooding en plena acción:



Podeis descargar la herramienta desde nuestro GitHub => https://github.com/0verl0ad/AP-flooder-js

Viendo lo sencillo que es trabajar con libpcap desde nodeJS, voy a intentar en mis ratos libres crear una librería para poder crear distintos frames de 802.11 al gusto.

Byt3z!

EDIT =========

Añado información de instalación por si alguien está perdido. En primer lugar utilizo la librería pcap, por lo que previamente debemos de tenerla instalada (suele venir por defecto, de no ser así instalar libpcap-dev -apt-get install libpcap- ).

  Teniendo nodeJS instalado (seguir los pasos del sitio oficial) y NPM, procedemos a instalar la librería encargada de comunicarse con pcap para ello:

npm install pcap
Teniendo todos los pre-requisitos listos, procedemos a hacer un git-clone o a descargar todo en un .zip. Una vez tengamos todos los archivos, nos colocamos en esa carpeta y (siendo root o usando sudo) ejecutamos el script tal y como puse en la entrada. Lógicamente, como ya dije, primero deberemos de estar en modo monitor.

Espero haber aclarado cualquier duda.

5 0verl0ad Labs: julio 2014 ¡Saludos!    Llevo apenas dos días trasteando en serio con nodeJS y me está gustando mucho. Para m...

viernes, 4 de julio de 2014

Explotando MailPoet (<= 2.6.6) con g0jira

¡Saludos!

   Alguna vez he hablado por aquí (o por el blog de estación informática de @n0ipr0cs) de g0jira, esa pequeña herramienta para auditar / atacar la plataforma WordPress. Todavía está en fase de corregir bugs y añadir muchas cosas (apenas tiene 61 exploits), pero aun así me está encantando usarla. Podeis descargaroslo desde el GitHub del blog => https://github.com/0verl0ad/g0jira

   Imagino que si os moveis en el mundo de la seguridad  web, o al menos os toca lidiar con la seguridad de algún WordPress, os habreis enterado de la noticia de que MailPoet (versiones de la 2.6.6 e inferiores) con 1.7 millones de descargas  sufre de una vulnerabilidad crítica que permite a un atacante subir una webshell al servidor (aqui noticia del reporte de Sucuri => http://blog.sucuri.net/2014/07/remote-file-upload-vulnerability-on-mailpoet-wysija-newsletters.html). He creado un exploit para la vulnerabilidad y lo he añadido a g0jira. Ahora os toca a vosotros jugar :)

   Como siempre, lo primero que haremos será una enumeración de los plugins instalados en nuestro laboratorio:

perl gojira.pl --enum=dic_populares.txt --url=http://localhost/wordpress --max=2000

Limitamos la búsqueda a los 2.000 plugins más populares


Vemos como aparece el plugin (MailPoet) con una versión vulnerable. Lo siguiente será comprobar si tenemos algún exploit en g0jira:

perl gojira.pl --exploit

 Elegimos la opción 3 y buscamos "mailpoet". Observamos como tenemos un exploit para el plugin.


  Al ser vulnerable a arbitrary file upload lo que vamos a hacer es usar shell2me para crear un webshell pequeña que reciba los comandos desde las cookies. De esta forma pasará más desapercibido en los logs. Asi que procedemos a abrir otra pestaña y ejecutar:

perl gojira.pl --tools

 Elegimos la opción 3 y escribimos "shell2me" para ejecutar la herramienta. Una vez dentro de shell2me, crearemos el PHP llamado shell.php.

Sin cerrar esta pestaña volvemos a la anterior y elegimos la opción 2 para poder ejecutar el exploit. Como vimos anteriormente el código de este exploit es el "OTHER-0061". Rellenamos los datos que nos pida el exploit y se lanzará automáticamente:


  Podemos ver que el exploit ha tenido éxito y que la shell se ha subido. Copiamos la URL de donde está nuestra webshell y volvemos a la pestaña donde estaba shell2me para poder conectarnos a ella y mandar comandos:


Y ya está. WordPress pwned!

Como bola extra podemos usar g0jira para realizar un escaneo de un listado de dominios para ver si alguno es vulnerable, para ello:

perl gojira.pl --check=/wysija-newsletters/ --url=lista_dominios.txt

   El archivo .txt contiene el listado de dominios a comprobar. Nos devolverá aquellos dominios que tenga ese plugin y su versión.

Byt3z!

5 0verl0ad Labs: julio 2014 ¡Saludos!    Alguna vez he hablado por aquí (o por el blog de estación informática de @n0ipr0c...
< >