Como vimos en el primer articulo de la serie sobre XXE, la vulnerabilidad de XML External Entity o XXE (como se la conoce) se basa en un sistema deficiente al parsear los XMLs que recibe la aplicación web, en este post veremos como ejecutar un ataque para explotar esta vulnerabilidad.
La vulnerabilidad de XML External Entity o XXE (como se la conoce) se basa en un sistema deficiente al parsear los XMLs que recibe la aplicación web, permitiendo la inyección de entidades externas de XML posibilitando ataques como conseguir ficheros del servidor de producción o ejecución de código. En el fondo, sucede igual que en el SQL injection (SQLi) nunca te fíes de lo que recibes del usuario.
El ataque de toma de control de un subdominio (o subdomain takeover en ingles) es una vulnerabilidad facil de detectar si sabes lo que estas buscando y muy peligrosa para la empresa en si mismo. Y os puedo asegurar que no es una vulnerabilidad unicornio de las que se encuentran una cada cinco años, sino que suelen pasar, yo mismo en la auditoria web que estoy haciendo esta semana me la encontre.
Las cookies o HTTP cookies consiste en que informacion enviada o recibida en cabeceras HTTP queda almacenada en el lado del cliente por un tiempo. El objetivo principal de las cookies era para facilitar el acceso de los usuarios a sus paginas web favoritas, pero actualmente se usan para muchas cosas y no todas son buenas.
Una de las partes más importantes del pentesting es la enumeración, en la que recabaremos toda la información necesaria para que después en las siguientes fases poder atacar al objetivo. En la la parte de la enumeración web se centra en los subdominios, es necesario saber encontrarlos para poder ver que posibles vectores de ataque usar. En este articulo hablare de varias opciones para extraer todos los subdominios posibles de una web.
Cross-Site Scripting (XSS) es un tipo de ataque por inyección, donde un tercer usuario puede inyectar codigo javascript en una pagina web, provocando que la pagina realice funciones que ni el usuario ni el programdor web esperaban. Este grave problema surge cuando la aplicación web acepta lo que escribe el usuario sin validarlo ni codificarlo. En este blog ya hemos hablado anteriormente del xss, pero en este articulo, quiero entrar mucho más a fondo.
La inyección de CSV es un tipo de ataque que fue descubierto por primera vez en 2014, consiste en que el atacante introduce codigo malicioso en formularios que luego seran descargados en excel o csv. El ataque va dirigido a quien se descarga el fichero, normalmente es un ataque que no se suele tener en cuenta, por ejemplo el programa de Bug hunting de Google no lo considera como una vulnerabilidad que entre dentro de su programa de recompensas.
Todas las configuraciones relacionadas con la seguridad de una aplicación deben ser definidas, implementadas y mantenidas, ya que las configuraciones por defecto no suelen ser correctas. Ademas se debe mantener todo el codigo actualizado incluido las librerias de terceros que se usen en la aplicación. Esto incluye, cuentas de usuario por defecto, paginas sin usar, acceso a ficheros y directorios desprotegidos, fallos no arreglados, configuraciones incorrectas, que nos den acceso al sistema o a informacion relevante del sistema.
Este ataque referencia directa a objetos ("direct object reference") ocurre cuando un desarrollador expone una referencia hacia un objeto interno de la aplicación, (parametro web, formulario, fichero, base de datos). Un atacante podría cambiar estas referencias y acceder a otros recursos de la aplicacion sin autorización
El ataque por CSRF o XSRF, consiste en forzar al usuario a ejecutar peticiones no deseadas en una web, en la que estan autentificados, si que este se de cuenta. En este tipo de ataque es necesaria la utilización de ingenieria social para engañar a la victima y que ejecute la petición falsa, sea mediante un email, o un link de una red social.
La validación cliente en las paginas webs, es totalmente recomendable tanto para el servidor como para el usuario pero el problema llega cuando solo se valida al cliente y no se valida en el servidor, y con fiddler se puede pasar esa validación facilmente pudiendo dejar codigo xss persistido en la base de datos de la pagina web.
El ataque XSS Persistido consiste en que el atacante consiga que su ataque se quede guardado en la base de datos de la pagina web. El vector de ataque XSS o Cross Site Scripting, es una de las vulnerabilidades más extendidas en las paginas web, según OWASP es la tercera en importancia en su TOP 10.
El vector de ataque XSS o Cross Site Scripting, es una de las vulnerabilidades más extendidas en las paginas web, según OWASP es la tercera en importancia en su TOP 10. Esta vulnerabilidad consiste en que un atacante es capaz de inyectar codigo javascript en una pagina visitada por el usuario y poder secuestrar la sesion del usuario o comprometer su navegador web.
El ataque XSS Reflejado consiste que el atacante comparta un link creado a sus victimas para que estas lo ejecuten y por conseguir su sesion o control sobre su navegador. El vector de ataque XSS o Cross Site Scripting, es una de las vulnerabilidades más extendidas en las paginas web, según OWASP es la tercera en importancia en su TOP 10.
Session Hijacking, forma parte de la perdida de Autenticación y gestión de sesiones, esta reconocida como la segunda vulnerabilidad web más peligrosa según la Open Web Application Security Project (OWASP) despues de Injection. Esta vulnerabilidad permite a un atacante acceder a una aplicación como si fuese otro usuario real.
El protocolo HTTP es un protocolo sin estado, es decir cuando nos autenticamos en un sitio, en el proximo request que hacemos a la web, no viene ningún sitio del request que diga que estamos autenticados, por lo que tenemos que apañarnos con "algunas trampas". Cuando un usuario se identifica en un web, esta le envia un token, que es unico para el usuario, y asi cada vez que el usurio haga un request a la web, este token ira en el request para que la web sepa quien es el usuario.
Cuando la web no da errores con las excepciones de la base de datos, cuando no es posible ni inyectar codigo por union ni siquiera por un ataque ciego si/no, lo unico que queda por probar es ataque ciego por tiempo. El más dificil de todos.
Es el ataque de sql injection más complicado, ya que puede ser que no podamos hacer el ataque por error ni tampoco por union, y como si fuera un fantasma en una casa encantada, solo podamos preguntar preguntas cuya respuesta sea verdadero o falso. De este ataque hay dos tipos, si/no y por tiempo. En este articulo hablaremos del ataque si/no o boleano
Es la más visual de los ataques de sql injection, ya que consiste en añadir una sentencia sql maliciosa a la sentencia sql original haciendo que la web nos muestre más datos de los que tendria que mostrarnos.
Es el más comun y el más facil de explotar ya que es la propia aplicacion que nos va diciendo los errores que da la base de datos cuando vamos usando los ataques de sql injection. Con este error es muy facil conseguir cualquier cosa de la base de datos (estructura, tablas, nombres de campos e incluso datos).
Hay varios tipos de ataque de SQL Injection, algunos son bastante fáciles otros algo más complicados pero todos igual de peligrosos.
SQL Injection es la primera vulnerabilidad que buscara cualquier hacker en una pagina web. Es un ataque facil de hacer, y cuyo resultado puede ser catastrofico para una empresa.