Posted by q3it on martes, octubre 26, 2021 in Ciberseguridad
Para vulnerar un servicio web utilizaré OWASP-Mutillidae y se hará capturando las credenciales de un usuario cuando accede a la página web www.xxxxx.com, aún teniendo en cuenta que se está enviando por un protocolo seguro HTTPS, la herramienta burpsuite nos enseñará en texto claro el user y el password cuando capture la petición de logueo como se ve en la siguiente figura.
Prueba en el mecanismo de autenticación
La enumeración de usuarios es muy común en ataques y con ello saber si un usuario existe, normalmente en el panel de autenticación muestra dos mensajes tales como:
Error: Incorrect password
Account does not exist
Según el mensaje que lance la aplicación se ejecutará una acción, porque la diferencia radica en que el mensaje de contraseña incorrecta significa que el usuario existe, pero le estamos escribiendo una contraseña que no es.
Para explotar esta vulnerabilidad se necesita crear un archivo .txt con los usuarios más comunes y cargarlo como payload en el intruder de la herramienta burpsuite o también se puede descargar de la red un diccionario con el mismo contenido.
Burpsuite haría fuerza bruta a la aplicación y esta arrojaría por longitud la respuesta de la petición de los usuarios enumerados, después tendríamos la tarea de diferenciar cual tiene una longitud anómala y probar con ese user en el panel de autenticación.
Una vez confirmado que existe el usuario se haría la misma operación con el password.
Para dar un ejemplo de como se ejecuta este ataque se utilizará el servidor web OWASP, en el cual se aloja una web construida en WordPress y que en su panel de autenticación pide user y password. Siguiendo las instrucciones del párrafo anterior como resultado obtuve user=admin y password=admin.
Ataques web conocidos
Aquí se empieza a ver dos de las vulnerabilidades más críticas y explotadas para atacar una aplicación web, como lo son:
- Cross-site scripting (XSS).
- SQL Injections.
Cross-site scripting (XSS)
Los ataques XSS tienen como objetivo el código de una página web que se ejecuta en el navegador del usuario, no en el servidor del sitio web.
Cuando el usuario es atacado, se introducen secuencias de comandos maliciosos en su navegador que intentarán dañar su equipo. La variedad de ataques XSS es prácticamente ilimitada, pero los más comunes suelen ser la recopilación de datos personales, el redireccionamiento de las víctimas a sitios controlados por ciberdelincuentes.
La vulnerabilidad se explota mediante la manipulación de los parámetros de entrada (input) de la aplicación con el objetivo de obtener una salida (output) determinada que contenga el código introducido como HTML o código scripting.
Existen diferentes tipos de ataques entre los que podemos distinguir:
- XSS Reflejados.
- XSS Persistentes.
Para identificar dichas vulnerabilidades es necesario comprobar los diferentes puntos de entrada de la aplicación normalmente: Formularios, cuadros de búsqueda, etc. En caso de que los datos introducidos no sean validados correctamente por el servidor, será posible explotar dicha vulnerabilidad.
XSS Reflejado: Cuando se abre una URL manipulada o se rellena un formulario adulterado se envía el script dañino al servidor web, que es devuelto al cliente sin ser comprobado, el código malicioso no se almacena en el servidor, sino que existe de forma temporal hasta que el cliente abre la página web.
Las páginas webs dinámicas y las aplicaciones de correo son especialmente vulnerables a este tipo de ataque.
Para desarrollo de este ataque se utilizará el Servicio Web DVWA. Lo primero que se hará es enviar una cadena de caracteres por medio del cajón submit que pregunta ¿Quién eres? Nosotros enviaremos cualquier texto para estar seguros de que funciona.
Ahora vamos al código fuente, revisamos dónde y cómo está introduciendo la información en el código, en nuestro caso lo está recibiendo normal, sin ningún tipo de variable, para verificar si está aplicando filtros se podría poner en el cajón submit la etiqueta <b> </b>, con esto se consigue inyectar código html y poner una respuesta en negrita como se ve en la siguiente figura. Esto nos da certeza de que la información que se está enviando a la aplicación, la recoge el navegador y la está almacenando en el código html.
Captura XSS reflejada con HTML.
Ahora se prueba si la aplicación es vulnerable a código JavaScript, se le inyecta un alert de la siguiente manera <script>alert(“Alerta Diego”)</script> y esto devolverá un aviso con el texto que le pongamos.
XSS Persistente: En este caso, los archivos maliciosos se almacenan en el servidor web y son liberados cada vez que se accede a una página desde un navegador, con este objetivo se eligen aquellas aplicaciones web que guardan datos de usuario en su propio servidor y los transfieren sin métodos de control o codificación. Los blogs y los foros son especialmente vulnerables para este tipo de ataques.
Las intervenciones de los usuarios en un foro generalmente se guardan en una base de datos sin un control suficiente, esto se toma como una oportunidad para añadir un script dañino en un post aparentemente normal, un usuario que no sospecha nada recibe el enlace del post por correo electrónico y en el momento en que lo abre se activa el script.
Sql Injections
Es un método de infiltración de código intruso, que se vale de una vulnerabilidad informática presente en una aplicación en el nivel de validación de las entradas para realizar operaciones sobre una base de datos, el atacante se aprovecha de aquellos fallos de seguridad en la superficie de la base de datos que no han sido correctamente enmascarados y que contienen metacaracteres como el guion doble, las comillas o el punto y coma, estos caracteres representan funciones especiales para el intérprete de SQL y permiten la influencia externa sobre las instrucciones ejecutadas. De esta forma, los atacantes pueden crear, leer, modificar o eliminar los datos guardados en el back-end, normalmente para acceder a información confidencial, como los números de la seguridad social, los datos de las tarjetas de crédito u otra información importante.
Esta sería una sentencia de consulta correcta sobre una base de datos:
Ahora se verán algunas alteraciones en las consultas a una base de datos:
Ejemplo de consulta con parámetros vacíos:
Ejemplo de consulta para la explotación de la vulnerabilidad:
Permitiría acceso como el usuario especificado.
Provocaría que la consulta devolviera todos los resultados.
Anteriormente se enumeraron usuarios, y se vió que habían usuarios que no existían en el sistema y otros que el password era incorrecto, entonces se comprobará si el Servicio Web OWASP es vulnerable a la Inyección SQL, se empezará con la inyección de una comilla simple en el panel de autenticación.
Esto arroja un error bastante descriptivo y es debido a que la aplicación no está controlando debidamente los errores que genera y con esto bastaría para saber que esta aplicación es vulnerable.
Ahora, si se le pone comillas dobles arrojará que la cuenta no existe, de antemano ya se sabe que la comilla simple existe como parámetro de petición en una cadena de caracteres y las dobles no existen como se ve en la siguiente figura.
Qué pasa si se cambia la petición por la siguiente:
Como ya se sabe que la comilla la acepta y que 1=1 siempre es cierto, el resultado que arroja es que nos deja acceder como admin.
Y la razón de ¿Porqué nos deja acceder como admin? es que realmente esta consulta comprueba por un lado user vacío o 1=1 que es siempre cierto y pass vacío o 1=1 es siempre cierto, por lo tanto esta instrucción lo que va a devolver son todos los usuarios de la base de datos, y con qué usuario se va a quedar cuando nos devuelve la petición, con el primer usuario de la base de datos que siempre es el usuario administrador, por ese motivo nos loguea como admin.
