Archive for June 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í!

Leer artículo original: Estaremos en Hack & Beers IV Madrid

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” 😉

Leer artículo original: PyZap → Uniendo Python y ZAP

Ejecutar como servicio un programa que no es demonizable

Hoy estuve lidiando con una aplicación que se ejecuta desde consola y queda escuchando en un puerto, pero que no provee la posibilidad de correr como demonio (tipo Apache, sshd, etc). Para no tener que loguear un usuario y dejar la aplicación en ejecución en alguna consola colgada, mejor es convertirla en un servicio. Mi caso en particular se dió con la aplicación CherryMusic, que permite compartir musica a través de una interfaz web.
Como primer paso, vamos a crear un directorio donde alojar la aplicación, y para un caso como el que describo, creo que el mejor lugar es /opt:

# mkdir /opt/cherrymusic

Para cherrymusic, si hacen un clone del proyecto, el directorio se crea sólo, lo mismo si descomprimen un tar.gz.
A continuación creemos el usuario con el que se ejecutará la aplicación:

# useradd cherrymusic -d /opt/cherrymusic -s /bin/false

El comando anterior indica que el home del usuario será /opt/cherrymusic y que utilice /bin/false como shell… es decir, que no tenga shell.
Para ver qué sucede con nuestra aplicación, estaría bueno ver algún log, así que creemos uno, con los permisos necesarios para que la aplicación pueda escribir:

# touch /var/log/cherrymusic
# chown cherrymusic /var/log/cherrymusic

La ejecución del programa la haremos de la siguiente forma:

# sudo -u cherrymusic -H /usr/bin/python /opt/cherrymusic/cherrymusic –port 8080 &>>/var/log/cherrymusic

Esto es, le decimos que ejecute la aplicación con el usuario cherrymusic (-u), usando el home de dicho usuario (-H), y redirigimos la salida a /var/log/cherrymusic
Como último paso, creamos un init script. Si usamos el viejo estándar, podemos meter un script como el siguiente en /etc/init.d/cherrymusic

#!/bin/bash
### BEGIN INIT INFO
# Provides:          cherrymusic
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6
### END INIT INFO
case “$1” in
  start)
    iptables -t nat -A PREROUTING -p tcp –dport 80 -j REDIRECT –to-port 8080
    sudo -u cherrymusic -H /usr/bin/python /opt/cherrymusic/cherrymusic –port 8080 &>>/var/log/cherrymusic
    ;;
  stop)
    iptables -t nat -D PREROUTING -p tcp –dport 80 -j REDIRECT –to-port 8080
    killall -u cherrymusic
    ;;
  *)
    echo “usage: $0 <start | stop>”
    ;;
esac

Ok, tal vez un killall no es lo mejor, pero sirve para mostrar un script muy simple.
Al script le agregué un “plus” que es levantar una regla iptables que redirija lo que llegue por el puerto 80, al 8080. Esto se debe a que, al ejecutar el script con un usuario no privilegiado, el mismo no se puede hookear al puerto 80.
Faltaría sólo agregarlo para que se ejecute al inicio:

  # update-rc.d cherrymusic defaults

Si quisieramos hacer lo mismo, pero utilizando upstart, podemos crear el siguiente archivo en /etc/init/cherrymusic.conf:

# Cherry Music
#
start on runlevel [2345]
stop on runlevel [!2345]
script
  iptables -t nat -A PREROUTING -p tcp –dport 80 -j REDIRECT –to-port 8080
  sudo -u cherrymusic -H /usr/bin/python /opt/cherrymusic/cherrymusic –port 8080 &>>/var/log/cherrymusic
end script
post-stop script
  iptables -t nat -D PREROUTING -p tcp –dport 80 -j REDIRECT –to-port 8080
end script

Eso es todo, ya pueden utilizar “service cherrymusic start” y “service cherrymusic stop”, y además la aplicación se ejecutará cada vez que se encienda el equipo. Los pasos serían los mismos si ejecutaran cualquier otra aplicación =)

Leer artículo original: Ejecutar como servicio un programa que no es demonizable