miércoles, 2 de diciembre de 2015

fi.py: Haciendo nuestra herramienta de auditoría web IV

Cuarta entrega de la serie y en la que se abordarán las vulnerabilidades Local File Inclusion y Remote File Inclusion. Si queremos saber más de ellas en la página de OWASP tenemos información sobre ambas (LFI y RFI), con lo que en esta entrada no vamos a explicarlas.

Como siempre el código está disponible en el repositorio pyJuanker de GitHub:
https://github.com/0verl0ad/pyJuanker/blob/master/scripts/fi.py

En cuanto al análisis de éste, obviando la primera parte del código que ya ha sido comentada en anteriores entregas (la relacionada con buscar todas las url de un dominio) llegaremos a la función findFi que será la encargada de buscar las vulnerabilidades entre las url proporcionadas:


Su implementación es muy similar a la de la entrada donde explicábamos el script xssUrl.py. Disponemos de un listado de payloads, en este caso uno para probar las LFI que busca el archivo /etc/group y otro para encontrar RFI que es la url de la página http://www.google.es/humans.txt con un fichero que, a priori, siempre es el mismo y debería ser fácil de comprobar.

Una vez conocidos los payloads basta utilizarlos como parámetros en las distintas url y comprobar que, en el caso de LFI la cadena "root" asociada al usuario de este nombre aparece en el código de la página retornada. Si lo hace es que es posible que exista una vulnerabilidad de este tipo. Para el caso de RFI el funcionamiento es similar salvo que, se busca una cadena del texto que aparece en la página visitada.

Un ejemplo de su uso en un entorno controlado (máquina virtual Web for Pentester) es el siguiente:


En la imagen aparece que ha detectado en la url analizada ambas vulnerabilidades.


Una vez concluyamos esta serie de entradas, escribiremos una herramienta para atraerlas a todas y atarlas en las tinieblas que las aglutine a todas y presente los resultados de "forma bonita".

Nos leemos en "breve" ;)


5 0verl0ad Labs: 2015 Cuarta entrega de la serie y en la que se abordarán las vulnerabilidades Local File Inclusion y Remote File Inclusion . Si queremos saber m...

miércoles, 25 de noviembre de 2015

xssFinder.py: Haciendo nuestra herramienta de auditoría web III

Tercera entrada y última centrada en los XSS. En este caso combinaremos las dos entradas previas (Cross Site Scripting tanto en los parámetros de la url y en los formularios de la página) y además, el script buscará automáticamente todas las url del dominio que encuentre por las páginas para analizarlas.

El código, como en anteriores entradas está disponible en el repositorio git de 0verl0ad:
https://github.com/0verl0ad/pyJuanker/blob/master/scripts/xssFinder.py

Sobré su análisis:


Esta función llamada getUrls es original de la aplicación comHunter que vimos en una entrada anterior. Su funcionamiento es recorrer todas las páginas del dominio e ir almacenando las url pertenecientes a éste que encuentre.

Siguiendo con el código nos encontramos con la función findXss:


Esta función se encarga de buscar XSS para cada url que haya encontrado previamente el script. Su funcionamiento se explicó en la entrada xssUrl.py: Haciendo nuestra herramienta de auditoría web II.

El resto de la función corresponde a la parte de buscar XSS en los formularios de la página visto en la entrada bxf.py: Haciendo nuestra herramienta de auditoría web I:


Con todo esto unimos los scripts de las entradas anteriores y recorremos el dominio buscando XSS. Se podría optimizar mediante hilos o similar o incluyendo listados de payloads más grandes, pero esto ya es tarea para otra ocasión :D.


Con esto cerramos la herramienta para buscar XSS, en futuras entradas veremos como encontrar otro tipo de vulnerabilidades.

Nos leemos en "breve",


5 0verl0ad Labs: 2015 Tercera entrada y última centrada en los XSS. En este caso combinaremos las dos entradas previas (Cross Site Scripting tanto en los parámetr...

martes, 24 de noviembre de 2015

xssUrl.py: Haciendo nuestra herramienta de auditoría web II

En la entrada anterior veíamos como probar patrones de XSS sobre todos los formularios de una página con python. A lo largo de esta entrada utilizaremos un procedimiento similar para detectar este tipo de vulnerabilidades en las url de las páginas.

Antes de empezar, el código se encuentra disponible en el repositorio git de pyJuanker:
https://github.com/0verl0ad/pyJuanker/blob/master/scripts/xssUrl.py
 A continuación, como en otras entregas, desglosaremos el código para ver su funcionamiento:


Las primeras líneas, como en el anterior script, corresponden a los parámetros de entrada como son la url y, de forma opcional, un diccionario con payloads para explotar un XSS.

En las siguientes líneas (22-24) se desglosa la dirección pasada por parámetro mediante el módulo urlparse que permite desglosar las url de forma fácil.

Siguiendo con el código:


Recorremos el listado de payloads disponibles y asignamos el valor de cada uno a cada parámetro del campo query de la url. Dicho campo lo obtenemos del desglose de la url realizado con urlparse:

Desglose de la url mediante urlparse extraído de su documentación.
A continuación, mediante el módulo request se realiza una petición get a la url objetivo con los payload del diccionario.
Como en el script de la anterior entrada, si la página resultante contiene el payload es posible que haya una vulnerabilidad XSS.


Un ejemplo de su uso:


En cuanto a las desventajas del script, adolece de las mismas que el anterior (bxf.py), pero basta para entender el funcionamiento básico de una herramienta de este tipo.


Con todo esto me despido, nos leemos en breve ;)




5 0verl0ad Labs: 2015 En la entrada anterior veíamos como probar patrones de XSS sobre todos los formularios de una página con python. A lo largo de esta entrada...

miércoles, 18 de noviembre de 2015

bxf.py: Haciendo nuestra herramienta de auditoría web I

En esta serie de posts vamos a hacer nuestra "herramienta de auditoría web automatizada". Veremos como mediante python podemos escribir herramientas que, aunque simples, pueden servirnos de base para otras más complejas centradas en la auditoría web.

En esta primera entrada dedicada a los XSS, veremos como detectarlos en los formularios de una página. Para ello tenemos el script bxf.py disponible en el github de 0verl0ad:

https://github.com/0verl0ad/pyJuanker/blob/master/scripts/bxf.py
Empezando con el código:



 vemos que utiliza la librería mechanize de python (rama 2.7.x, no lo he probado con python 3) que permite desde este lenguaje emular un navegador web.

A la declaración de éstas (las librerías) le siguen los parámetros de uso, siendo la url objetivo el primero y el segundo, un diccionario de payloads para probarlos en todos los formularios (éste es opcional).

Los siguientes parámetros que aparecen son para configurar mechanize para que funcione correctamente en la mayoría de páginas.

Siguiendo con el código:



A partir de la línea 43 se recorre el listado de payloads proporcionado y va rellenando cada campo de texto de los formularios para después proceder a enviarlos.

Acto seguido comprueba si el payload está contenido en la página respuesta para ver si el formulario es vulnerable a un XSS.


El problema de este método es que producirá bastantes falsos positivos, pero como aproximación y como base de scripts más complejos cumple su cometido.


Para su uso he utilizado el diccionario de payloads que ofrece un plugin de ZAP disponible en:
https://github.com/zaproxy/zap-extensions/blob/master/src/org/zaproxy/zap/extension/fuzzdb/files/fuzzers/fuzzdb-1.09/attack-payloads/xss/xss-rsnake.txt 



Con el diccionario en nuestro poder, basta con ejecutar el script con:
python bxf.py "http://xxx.com" xss-rsnake.txt
donde http://xxx.com es la url objetivo y xss-rsnake.txt es el archivo de payloads.

La salida resultante:


Al detectar un posible formulario vulnerable se muestran información sobre éste y el payload utilizado para explotarlo (el script para una vez detecta un payload vulnerable, es decir, no prueba toda la lista si ya tiene un posible positivo).


Con todo esto me despido, nos leemos en breve ;)


5 0verl0ad Labs: 2015 En esta serie de posts vamos a hacer nuestra "herramienta de auditoría web automatizada". Veremos como mediante python podemos esc...

martes, 17 de noviembre de 2015

Reto #1: Deep Derp

¡Saludos!

Dejo por aquí un pequeño reto que hice el otro día. Para superarlo, deberéis de encontrar un flag (viene denotado por el clásico flag{ AQUI EL FLAG }, por lo que cuando lo tengais será fácil saberlo).

El reto realmente se compone de varias fases, todo comienza a partir de un PCAP. Tiene partes de forense de redes, web, crypto y lenguaje esotéricos. Aunque, pese a que tenga componentes de todas esas áreas, no se trata de un reto de seguridad como tal.

Si encontrais el flag, enviadmelo por mensaje privado a mi tuiter: @TheXC3LL. El write up de quien resuelva el reto lo publicaré aquí. Invitaré a una copa a quien lo resuelva primero en el Cybercamp ;)
El plazo es hasta el 25 de este mes. Si nadie lo resuelve, publicaré la solución en el blog de Ka0labs.

Let's Play: https://mega.nz/#!PBUzSBQB!AC5-0_ZWsnwizEshzgnql3QutGaLrodS74_KO4_UdW4

 Byt3z!
5 0verl0ad Labs: 2015 ¡Saludos! Dejo por aquí un pequeño reto que hice el otro día. Para superarlo, deberéis de encontrar un flag (viene denotado por el clásico...

viernes, 13 de noviembre de 2015

Charla -> Vigila la seguridad de tu web con ZAP


Hace un par de meses di una charla en el grupo de PHP Valencia (buena gente todos, nadie me insulto al acabar) sobre OWASP ZAP.

El contenido de ésta, es un breve repaso por el OWASP TOP 10  repasando, a modo de introducción,  las vulnerabilidades más comunes y peligrosas en el ámbito web. El grueso de la charla lo compone una introducción a la herramienta para mostrar todas las posibilidades que esta ofrece.

La charla la tenéis disponible aquí:





Nos leemos en breve ;)


5 0verl0ad Labs: 2015 Hace un par de meses di una charla en el grupo de PHP Valencia (buena gente todos, nadie me insulto al acabar) sobre OWASP ZAP . El co...

martes, 22 de septiembre de 2015

Buscando comentarios con ComHunter

Muchas veces los desarrolladores dejan en sus páginas comentarios que en ocasiones pueden ser útiles en labores de auditoría.

ComHunter  recorre un dominio indexando todas las url pertenecientes a éste que encuentra para después extraer todos los comentarios del código html, javascript y css. Tanto el código como las urls y los comentarios quedan almacenados en una base de datos que posteriormente puede ser analizada.

Los datos se presentan en una página web realizada con Bootstrap (esto es un capricho mio para ver como funcionaba :D ).

Para ejecutar ComHunter basta con indicar la url objetivo como primer parámetro y el spider indexara todas las direcciones disponibles.


Una vez finalizado el proceso, la aplicación creará un directorio con el código html para presentar los datos:


En cuanto a los comentarios obtenidos:







¿Qué queda para mejorar?
  • Las expresiones regulares se podrían mejorar para obtener resultados algo más precisos.
  • Multihilo, es decir, analizar varias url de forma simultánea.
  • Y algún que otro bug que saldrá por ahí.

Tanto la aplicación como el código esta disponible en:
https://github.com/Aetsu/comHunter

Nos leemos en "breve" ;).


5 0verl0ad Labs: 2015 Muchas veces los desarrolladores dejan en sus páginas comentarios que en ocasiones pueden ser útiles en labores de auditoría. ComHunter  r...

domingo, 26 de julio de 2015

Fingerprinting en Joomla

¡Saludos!

<TL;DR;>

He hecho un script para sacar la versión de los Joomla, así como qué plugins con vulnerabilidades conocidas posee (y link al exploit). Ventajas frente a Joomscan, JoomlaScan, el escáner de Metasploit, etc.: está actualizado para hacer fingerprint a las versiones recientes de Joomla y la base de datos de componentes es mayor.

Kum0nga => https://github.com/0verl0ad/kum0nga

</TL;DR;>


Ahora vayamos al turrón.

Extraer la versión de Joomla

Prácticamente en todos los CMS el proceso de identificación de la versión que anda utilizando la página web objeto de la auditoría viene determinada por dos opciones:

  • Localizar ficheros donde explícitamente se indique la versión instalada
  • Detectar detalles que únicamente aparezcan en una determinada versión
El primer caso sería lo ideal, pero si el administrador de la web ha hecho bien sus deberes eliminará todos los puntos desde los cuales el auditor pueda extraer la información de forma directa.

En joomla podemos encontrar la versión, tal cual, en diferentes ficheros accesibles a través del navegador. Por ejemplo, un buen sitio donde mirar es en el archivo "joomla.xml" que queda alojado en la ruta /administrator/manifests/files/joomla.xml






Por otra parte los archivos XML generados en los packs de lenguajes también puede aportarnos información acerca de la versión, por ejemplo /language/en-GB/en-GB.xml






 En la imagen de arriba se observan también nombres de componentes, sobre eso hablaremos más tarde.

  Cuando estos archivos jugosos no se encuentran accesibles, o les han sido extirpados los datos relevantes, podemos recurrir a realizar un fingerprint de la plataforma. Para ello, lo ideal, es realizar un análisis a todas las versiones de Joomla para hallar diferencias que permitan acotar ante qué versión nos encontramos.

Para que nos entendamos, imaginemos que en la rama 2.X y 3.X en un archivo .JS aparece una determinada línea. Si comprobamos ese archivo en una web, y está sabremos que pertenece a la rama 2.X o a la 3.X (y si no lo está sabemos que no pertece a esas ramas). A continuación buscaríamos algo que sólo estuviese en una de esas ramas, y así continuamente, hasta dar con la versión instalada.

Por suerte para nosotros ya hay personas que han buscado estas diferencias y ya han hecho parte del trabajo (un buen punto de partida es este post https://www.gavick.com/blog/how-to-check-the-version-of-joomla . Esto que nos ahorramos.

Para ganar precisión (y actualizar a las nuevas versiones) procedí a descargarme todas las versiones de joomla publicadas y hacer diffing para encontrar diferencias. Fruto de ello es el script kum0nga que actualmente utilizo para la identificación de la versión. Todavía se podría llegar a afinar mucho más la versión (en muchos casos indico entre y qué versión puede estar, pero no la exacta), pero eso se lo dejo a la gente que quiera colaborar.

Cabe decir que a veces existen discrepancias entre las versiones extraídas directamente, ya que a veces al actualizar algunos ficheros no son cambiados y podemos encontrar que en archivo de lenguaje aparece una versión más antigua que en el joomla.xml, por ejemplo. Ante estos casos el fingerprint es la única salida para estar seguros.

Detectar componentes instalados

 Como vimos en la imagen anterior, a veces los plugins generan entradas en los archivos de lenguaje. Otras veces los ficheros que aparecen listados existen realmente pero no han sido linkeados al .xml, por lo que si accedemos (por ejemplo /language/en-GB.com_weblinks.ini) y vemos que existe el fichero, ese plugin estará instalado. 

  En el fondo, al igual que ocurre con el resto de los CMS, la detección de si un plugin se encuentra instalado o no se reduce al envío de peticiones HTTP a rutas de instalación, y comprobar la respuesta del servidor.

Las rutas habituales de instalación son /components/com_nombre del componete. Por ejemplo, si queremos saber si está instalado weblinks, mandaríamos una petición a url-falsa.com/components/com_weblinks.

En muchas ocasiones podemos llegar a determinar incluso la versión del componente instalado a través de ficheros .xml. Ficheros comunes son los manifest.xml, index.xml, y readme.xml. 

Kum0nga

Se trata de un pequeño script que he hecho para cuando me toca trabajar con Joomla. Básicamente realiza un fingerprint más acertado (aunque todavía queda mucho por mejorar) y actualizado que el resto de herramientas que se encuentran en internet (incluyendo el escaner de Metasploit). 

La lista de componentes que detecta está directamente extraída (scrapeada cutremente y que habría que añadir tropecientos plugins más vulnerables, pero eso lo iré haciendo poco a poco) de joomlaexploit.com. La idea es ir actualizando la base de datos cada dos semanas o mensualmente. 



Kum0nga => https://github.com/0verl0ad/kum0nga



 Espero que os sea de utilidad

Byt3z!

 

 
5 0verl0ad Labs: 2015 ¡Saludos! <TL;DR;> He hecho un script para sacar la versión de los Joomla, así como qué plugins con vulnerabilidades conocidas pos...

jueves, 16 de julio de 2015

Espiando a los vecinos pasivamente

¡Saludos!

  La semana pasada tras el Hack & Beers salimos a tomar un par de copazos. Hubo un momento durante la noche en la que me percaté que dos de las personas que allí estaban vivían en el mismo edificio y que una tercera vivía y tenía su oficina relativamente cerca a mi piso.

En ese momento mi mente empezó a cavilar algunas ideas que empezaría a poner en marcha ese mismo fin de semana. La premisa de la que partía era: ¿Qué información útil puedo obtener de forma no intrusiva de mis vecinos? La meta que me marqué era poder llegar averiguar las rutinas y horarios que mis vecinos tenían, es decir, cuando andaban en casa y cuando no.

Hoy en día todo el mundo tiene wifi en su casa, y dispositivos móviles que les acompañan en su día a día, por lo que si consigo asociar qué dispositivos corresponden a cada piso, podré saber cuando están en casa o no. Por lo tanto el problema lo podemos desglosar en dos puntos a completar:

1.- Averiguar cuando un dispositivo está conectado a la red, y mantener una trazabilidad en el tiempo.

2.- Averiguar qué red corresponde a cada piso.

Esto es algo muy viejo y que varias a veces ha salido a la luz por centros comerciales que utilizaban estas tácticas para trackear a los usuarios (además de con el Wifi, antiguamente con el bluetooth). Lo mío es una simple implementación de andar por casa.

Quien está conectado a que

Los dispositivos móviles emiten contínuamente paquetes Probe Request en modo broadcast, con el fin de mapear qué redes hay alrededor. Estos paquetes Probe Requests contienen la dirección MAC del dispositivo, por lo tanto ya tenemos un elemento que nos aporta la trazabilidad necesaria de los individuos (es muy difiicl que nos vayamos a encontrar dos macs identicas).

Dentro de los paquetes Probe Requests que vayamos pescando deberemos de diferenciar dos grupos: "itinerantes" y "vecinos". Los itinerantes son aquellas personas que simplemente pasean por la calle, y los vecinos son las personas que realmente nos interesan. Más adelante veremos cómo quedarnos sólo con la parte que nos interesa.

Para detectar las redes podemos basarnos en los paquetes Beacons y en los Probe Response. En caso de que la red esté oculta y haya alguien conectado podremos sacar el ESSID a través de los Probe Response; si no hay nadie conectado deberemos de bruteforcear el nombre, ya que de los paquetes podemos sacar el tamaño del ESSID.

Ya tenemos clientes y redes. Ahora toca averiguar quien está conectado a qué, y para ello necesitamos capturar algún paquete donde aparezcan ambos datos (cliente y AP). La respuesta son los paquetes RTS.


En estos paquetes vamos a tener la mac del dispositivo y la de AP, por lo que como previamente sabemos cuales son las macs de los AP, es trivial sacar quien está conectado a qué.

Toda esta parte ya la programé en un ñapa script en NodeJS hace un año (https://github.com/0verl0ad/wifi-scan-js ). Para nuestro propósito básicamente le he añadido la capacidad de volcar cada 20 minutos la información dentro de una base de datos SQLite, de esta forma podremos tener un histórico de cuando han estado conectados los clientes, y de esta forma poder trazar visualmente los horarios de las personas. Además, a través de las direcciones mac se pueden saber los fabricantes de las tarjetas de red y a partir de ahí identificar qué moviles / ordenadores usan esas personas.

Pero no es oro todo lo que reluce. Los dispositivos móviles cuando no están en movimiento, o no están en uso, disminuyen o dejan de enviar prácticamente Probe Request con el objetivo de ahorrar batería. Se entiende que al estar sin moverse en un mismo punto las redes wifi alrededor no van a modificarse, van a ser las mismas.

Esto puede ser un problema si no lo tenemos en cuenta a la hora de representar los datos obtenidos y obtener conclusiones. De los datos observados, es fácil determinar cuando esa persona entra o sale de su casa por la cantidad de paquetes y el vacío que hay cuando abandona el edificio.

Ya hemos completado la primera parte, vayamos al siguiente punto.


¿A qué piso corresponde cada red?

Hay muchas formas de poder responder a esta pregunta. En mi caso no quería parecer un bicho (aun más) raro, por lo que descarté ir por el edifico con el portátil y la antena haciendo mediciones.

Para pasar más desapercibido opté por utilizar una aplicación móvil que hiciera las mediciones. Me decanté por "Wifi Analyzer", que me permitía hacer capturas de la potencia de todas las redes y guardarlas con un nombre identificativo.

La idea es hacer mediciones de la intensidad de la señal cada 2 metros e ir guardando los datos ordenados en una matriz, y posteriormente analizar estos datos para establecer distancias relativas a los puntos de muestreo y así "dibujar" donde estarían los AP.

Los problemas con los que me encuentro en este caso es que la propia forma de la estructura del edificio, junto a las interferencias, hace que en ciertos puntos se falseen los datos porque la cantidad de señal que llega no es la que "debería" de llegar, aparentando que el AP se encuentra más lejos de lo que está en realidad.

Actualmente me encuentro atareado con esta última parte, pero confío en que con un tamaño muestral suficiente y utilizando el sentido común pueda llegar a buen puerto.


Espero haberos dado ideas para entreteneros este verano ;)

Byt3z!



5 0verl0ad Labs: 2015 ¡Saludos!   La semana pasada tras el Hack & Beers salimos a tomar un par de copazos. Hubo un momento durante la noche en la que me per...

sábado, 27 de junio de 2015

Estaremos en Hack & Beers IV Madrid

¡Saludos!

   El día 10 de Julio estaré dando una charla en el Hack & Beers de Madrid. El evento tendrá lugar en el bar +K Copas situado en calle Infantas 13, iniciándose a las 16:30.

   Mi charla irá sobre backdoors en PHP y ofuscación. La he titulado 'From "<? system($_GET 'cmd']) ?> " to  "(..)@$_[]=@!+_; $__=@${_}>>$_;(...)"', y en ella, a parte de teoría, enseñaré (y desofuscaremos) algunas muestras que he ido recopilando con el tiempo.

Por otra parte también estará @KioArdetroya hablando de rubber ducky.

¡Nos vemos allí!


5 0verl0ad Labs: 2015 ¡Saludos!    El día 10 de Julio estaré dando una charla en el Hack & Beers de Madrid. El evento tendrá lugar en el bar +K Copas situad...

martes, 23 de junio de 2015

PyZap → Uniendo Python y ZAP



Zap (Zed Attack Proxy) es una herramienta para auditoria de aplicaciones web disponible en OWASP:
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project

Sin entrar a describir su funcionamiento, en esta entrada veremos como realizar scripts en Python (2) para interactuar con ella. El primer paso será instalar la API de Python, para ello recomiendo no utilizar la versión disponible en pip (pip install python-owasp-zap-v2) pues no trae todas las funcionalidades.

Para instalarla, como recomiendan en su web, descargamos desde SourceForge el código:
http://sourceforge.net/projects/zaproxy/files/client-api/
 Para después instalarlo con:
cd python/api/
python setup.py build
sudo python setup.py install
Una vez instalado, ya podemos empezar a trabajar con la API.

Antes de continuar, necesitaremos lanzar ZAP en modo demonio pues la API actúa como cliente y sigue necesitando que la aplicación se esté ejecutando. Para ello basta con, siendo ZAP_.2.4.0 el directorio donde se encuentra descargada la aplicación, ejecutar:
./ZAP_2.4.0/zap.sh -daemon
 

 Con ZAP funcionando ya podemos probar nuestros scripts en Python.



A partir de la información (en parte desactualizada) disponible en la web del proyecto he creado un script que analiza el sitio objetivo y el cual describiré para explicar el funcionamiento de la API.

El código está disponible en el GitHub de 0verl0ad:


 El código está dividido en 2 clases. Una para gestionar la base de datos (añadido mio externo a la API de ZAP) llamada DataB mientras que la otra clase es la que interactua con ZAP (llamada ZapScanner). Junto a ambas hay <<Un método main para gobernarlas a todas. Un método para encontrarlas, un método para atraerlas a todos y atarlas en las tinieblas en la Tierra de Java donde se extiende ZAP>>.

Antes de continuar aclarar que la clase relacionada con la base de datos la obviaré en la entrada pues no es el objetivo de ésta.


Lo primero que hay que hacer es incluir la clase de ZAP (en la documentación oficial no está actualizado):
from zapv2 import ZAPv2
 Con ello ya podemos trabajar sin problemas. A continuación es necesario inicializar la clase y crear una nueva sesión (esto último no es obligatorio):



A partir de aquí enlazamos la URL con la aplicación mediante el método urlopen y ya se pueden empezar a lanzar los distintos módulos de ZAP:



En esta entrada veremos los módulos Spider, Ajax Spider y Active Scan. Todos tienen un funcionamiento similar aunque veremos cada uno de ellos por separado.

El primero de ellos (Spider), se lanza con la función scan tendiendo como parámetro la URL objetivo. A partir de aquí empezará a "escarbar" por la dirección en busca de las páginas a analizar. El estado de este proceso se muestra con la función status(). Toda la información recabada la guardará ZAP internamente y más adelante veremos como extraerla.



La segunda función, Ajax Spider funciona igual que la anterior con un método scan y la URL como parámetro.


El tercer y último método tratado, Active Scan funciona como los anteriores. Utiliza scan para analizar y status()para mostrar el estado del proceso.

Mención especial a la función z_insertDb() que veremos a continuación.


La función z_insertDb()es la encargada de extraer la información de la sesión de ZAP e insertarla en la base de datos. Vayamos por partes. El primer bucle corresponde al listado de URLs encontradas por la aplicación, para obtener su listado es necesario hacer una llamada al método zap.core.urls. Situación similar ocurre con las alertas, siendo en este caso necesario llamar a la función zap.core.alerts() para obtener su lista.

En el caso del diccionario data, este se encarga de obtener el listado de hosts analizados (zap.core.hosts), el número de alertas (zap.core.number_of_alerts()) y la versión de ZAP (zap.core.version).

Toda la información recogida en esta clase acaba en una base de datos externa a ZAP para si queremos tratar la información con otras aplicaciones o métodos de nuestra cosecha.



Con todo esto, las siguientes imágenes corresponde a una ejecución del script que os he puesto líneas arriba:
python2 pyZap.py -u 192.168.1.21/dvwa


 



El script está por pulir y falta introducir alguna que otra cosa, aunque sirve como muestra de las posibilidades de la API.


Si queréis ampliar información:

Un saludo y nos leemos en "breve" ;)


5 0verl0ad Labs: 2015 Zap (Zed Attack Proxy) es una herramienta para auditoria de aplicaciones web disponible en OWASP: https://www.owasp.org/index.php/OWAS...

jueves, 30 de abril de 2015

Juankeando con la Pitón (10) - Buscando clientes de un AP

Ultima entrada (a priori) relacionada con temas wireless y python. En este caso vamos a ver que clientes están asociados a que punto de acceso a partir de los paquetes probe request.

Dichos paquetes son enviados para buscar los puntos de acceso, por tanto basta con monitorizarlos para ver donde se quieren asociar los clientes:


Para realizar esta tarea, modificaremos el snifer que hicimos en anteriores entradas con scapy cambiando el tipo de paquete a Dot11ProbeReq. Despues simplemente adaptando los print mostramos la información que deseamos:


Al ejecutarlo iremos viendo los distintos mensajes ProbeRequest enviados:


Con esta entrada junto con las anteriores y un par de florituras,  ya tenemos todas las funcionalidades de airodump-ng ;).

El script, como siempre disponible en el GitHub de 0verl0ad:
https://github.com/0verl0ad/pyJuanker/blob/master/scripts/clientScanner.py

A partir de la siguiente entrada ya cambiaremos de tema (o eso espero....).

Si quereis ampliar más información:

Nos leemos en "breve"  ;)



5 0verl0ad Labs: 2015 Ultima entrada (a priori) relacionada con temas wireless y python. En este caso vamos a ver que clientes están asociados a que punto de acce...

jueves, 9 de abril de 2015

Juankeando con la Pitón (9) - AP Scanner con scapy

 En la entrada anterior vimos como crear un escáner de puntos de acceso con sockets lo cual requería conocer el formato de los paquetes beacon que emiten éstos. Si bien da mucha flexibilidad, es bastante laborioso y scapy nos ofrece una capa de abstracción para realizar esta tarea (entre muchísimas otras).

El código como siempre en el GitHub de 0verl0ad:
https://github.com/0verl0ad/pyJuanker/blob/master/scripts/apScannerScapy.py


Si obviamos las funciones ya implementadas en códigos anteriores nos centramos en la función captura heredada del escáner para paquetes deauth que se comentó en entradas anteriores..

Vemos que de todos los paquetes que se pueden capturar solo nos interesan los que sean del tipo beacon, para ello utilizamos Dot11Beacon. Cuando se cumple esta condición la mac del punto de acceso se agrega una lista para evitar repeticiones y se muestran los datos interesantes del paquete, véase el ESSID (p[Dot11].info), el BSSID (p[Dot11].addr3) o el canal (p[Dot11Elt:3].info) para equiparar el script al del post anterior.

El resultado es igual que el de la anterior entrada pero con un código mas entendible:



Como ayuda a la hora de crear o interpretar los paquetes la función command() de scapy es muy útil ;).


Después de esto tengo pensado en dedicarle otra entrada a  wireless y cambiar de temática que ya toca (o quizás no), nos leemos en breve ;)


5 0verl0ad Labs: 2015  En la entrada anterior vimos como crear un escáner de puntos de acceso con sockets lo cual requería conocer el formato de los paquetes beac...

lunes, 30 de marzo de 2015

Juankeando con la Pitón (8) - AP Scanner con sockets

La suite Aircrack tiene la fabulosa herramienta airodump-ng para escanear los puntos de acceso a nuestro alrededor. En esta entrada implementaremos con python (2.7) algunas de sus funcionalidades para entender como funciona.

En esta ocasión utilizaremos sockets puesto que aporta mas valor didáctico, aunque en la siguiente entrada trabajaremos con la librería scapy (vista en anteriores posts) que nos aportará mayor abstracción que los sockets y nos facilitará enormemente la tarea.


De todos los paquetes que intervienen en una comunicación wireless, para nuestro actual cometido solo nos interesan los del tipo beacon (beacon frames) pues contienen el nombre del punto de acceso, su mac o canal entre otros muchos valores. Por tanto, nuestro primer cometido será identificar el subtipo de los beacon comentados antes. Para ello el Sr. Google o wireshark pueden servirnos:

Imagen obtenida de http://www.wildpackets.com/resources/compendium/wireless_lan/wlan_packet_types

Siendo el subtipo 8 este será el que filtraremos. A partir de aquí, el resto de datos los obtendremos de wireshark (o desde las especificaciones del paquete):


Con un paquete de ejemplo obtenido con wireshark procedemos a ver que posiciones ocupan dentro de éste los diversos valores que queremos obtener. Todo esto lo tendremos en cuenta durante el desarrollo del script:


Al principio encontramos las funciones channel_hopper y signal_handler ya explicadas en anteriores entradas, aunque, descritas brevemente, una permite ir cambiando de canal y la otra interrumpir correctamente el programa con CTRL+C.

La parte interesante del código la encontramos en el método main, concretamente a partir de la línea 43.
Las primeras peculiaridades surgen al crear el socket, pues a diferencia de como lo creamos normalmente (con STREAM o DGRAM), en esta ocasión trabajaremos con los datos en bruto (RAW). El tercer elemento que normalmente se omite, en esta ocasión es 3 (ETH_P_ALL) que implica que el socket trabaje con todos los protocolos. Con esto definido ponemos a escuchar una interfaz en modo monitor (usando, por ejemplo, airmon-ng) y que empiece a capturar paquetes.


Trabajamos con los paquetes en RAW, por tanto éstos llevan sus cabeceras. Ésta es de 36 bytes, siendo el 37 el que determina el subtipo del paquete, en este caso tendrá que ser 8 (0x0008) (línea 53 del código):


A partir de aquí se trabaja con una lista para evitar mostrar puntos de acceso repetidos pues continuamente recibiremos beacons. A continuación mostraremos la información que deseemos del paquete  conociendo la posición que ocupa en éste. Siendo interesante conocer que el tamaño del nombre del punto de acceso es un factor determinante y variable pues, en función de su longitud, los valores siguientes (en el caso del script la MAC y el canal) estarán en una posición u otra. La variable ssidLen controla esto (línea 54).

Para probarlo, partiendo de que nuestra interfaz se encuentra en modo monitor, veremos un resultado como el que sigue:


Como siempre, el script está en la correspondiente sección del GitHub de 0verl0ad (si los chinos os dejan acceder a el ;) ):
https://github.com/0verl0ad/pyJuanker/blob/master/scripts/apScannerSock.py

En la siguiente entrada (a saber cuando...), veremos las mismas funcionalidades pero implementadas con la librería scapy.


Si alguien quiere ampliar información...:


C'est fini, nos leemos en breve

5 0verl0ad Labs: 2015 La suite Aircrack tiene la fabulosa herramienta airodump-ng para escanear los puntos de acceso a nuestro alrededor. En esta entrada implemen...

martes, 24 de marzo de 2015

Juankeando con la Pitón (7) - Haciendo nuestro escáner de puertos

Séptima entrada de la serie "Juankeando con la Pitón", esta vez centrada en un script para analizar puertos (TCP). El funcionamiento es simple, pasada (con argparse) una IP junto con el rango de puertos a escanear se realizará una prueba de conexión a cada puerto y en función de la respuesta es posible saber si está o no abierto. Además para agilizar la tarea se ha utilizado la librería multiprocessing de Python  (2.7.x).

El código está disponible en el GitHub de 0verl0ad:
https://github.com/0verl0ad/pyJuanker/blob/master/scripts/portScan.py



Empezando por la parte de multiprocessing, declaramos un máximo de 50 procesos paralelos en la línea 44 y, a continuación, lanzamos la función scan cuyos parámetros son el rango de puertos a escanear.

La función scan abre un socket a cada puerto de la ip destino con un timeout de 1 segundo (este tiempo se propria reducir y no debería haber problemas pero influye la conexión por eso he optado en dejarlo a 1 segundo) y espera la respuesta. Si es 0 el puerto estará abierto, mientras que si es un valor distinto no (o el script no es capaz de confirmar que lo esté).

Con todo esto, conforme vaya obteniendo cada proceso el estado del puerto irá mostrándose por pantalla.



¿Cosas que se podrían mejorar?
  • Que también soporte UDP como protocolo, lo cual es tan simple como cambiar un parámetro en la declaración del socket.
  • Añadir el numero de procesos paralelos como parámetro que basta con añadir otra opcion a argparse.
  • Identificar los servicios asociados a los puertos abiertos. Esto se podría implementar creando un diccionario con el puerto y su servicio asociado a partir de la información del fichero /etc/services (en el caso de GNU/Linux) con lo que sería útil para los puertos por defecto aunque pudiera llevar a falsos positivos en la identificación de servicios.
Si algún día me aburro igual las implemento y publicaré una versión actualizada del post, nos leemos en breve ;)



5 0verl0ad Labs: 2015 Séptima entrada de la serie "Juankeando con la Pitón", esta vez centrada en un script para analizar puertos (TCP). El funcionamien...

jueves, 19 de marzo de 2015

Juankeando con la Pitón (6) - Detectando ataques deauth con scapy

Si en la anterior entrada de Juankeando con la Pitón vimos como desautenticar a un cliente de un punto de acceso, en ésta veremos como descubrir si alguien está realizando este tipo de ataque.

Para ello, al igual que en la anterior, utilizaremos scapy junto con una interfaz en modo monitor para capturar todo el tráfico al alcance. Después basta con filtrar el que queramos y ya tendremos el escáner listo.

El código parte de una versión mucho mas compleja de una aplicación que intenta simular el funcionamiento de airodump-ng (suite aircrack-ng), lo podéis encontrar aquí.

En cuanto a nuestro script, su código está en el GitHub de 0verl0ad:
https://github.com/0verl0ad/pyJuanker/blob/master/scripts/deauthScanner.py

Las peculiaridades del código las encontramos en la función channel_hopper sin la cual solo interceptaríamos paquetes en un determinado canal, de ahí que sea necesario ir saltando entre éstos. La captura la realiza la función de mismo nombre que filtrará los paquetes de desautenticación mostrando datos del cliente atacado.


En fin, nos leemos en "breve" ;)



5 0verl0ad Labs: 2015 Si en la anterior entrada de Juankeando con la Pitón vimos como desautenticar a un cliente de un punto de acceso, en ésta veremos como desc...
< >