Archive

Posts Tagged ‘ataques web directos’

XSScrapy para procesos de crawling e identificación de vulnerabilidades

marzo 12, 2015 Deja un comentario

Scrapy es un framework que cuenta con varias utilidades para crear spiders y crawlers, se ha vuelto bastante popular y en cada nueva versión es mucho más estable y robusto. Hace algún tiempo comentaba en un vídeo de la serie de Hacking con Python los elementos que a mi parecer eran los más interesantes de Scrapy y cómo se puede utilizar desde cualquier script en Python. Dado que este tipo de actividades casi siempre suelen ir de la mano con procesos de minería y extracción de datos, a lo mejor no resulta tan llamativo para un pentester/hacker (o si), pero cuando hablamos de ejecutar un proceso de crawling no solo para extraer información, sino para detectar vulnerabilidades en aplicaciones web, seguro que más de uno comienza a ver que se pueden hacer cosas muy interesantes.
Si has visto como funciona un spider y la cantidad de elementos involucrados en un proceso de crawling, casi seguro que alguna vez te habrás preguntado ¿Y cómo puedo utilizar esto para ejecutar tareas de pentesting? Creo que es una pregunta bastante lógica, ya que además de visitar enlaces y analizar la estructura de un sitio web, también estás jugando con cabeceras HTTP, parámetros en el cuerpo de la petición o directamente en la URL, formularios, diferentes tipos de “content-types” y un largo etc. Son muchas las posibilidades que tienes a tu disposición.
Ahora bien, imaginar por un segundo que esto lo aplicamos no solamente a aplicaciones web en Internet, sino también a servicios ocultos del tipo HTTP en la red de TOR. A mi personalmente me ha parecido una idea de lo más interesante y ahora mismo me encuentro desarrollándola para la próxima versión Tortazo, algo de lo que pienso hablaros en un próximo articulo.

Si quieres utilizar Scrapy directamente y realizar pruebas de pentesting contra todos los enlaces encontrados y procesados por un Spider, no hay demasiados impedimentos para hacerlo, sin embargo existe una herramienta que ya lo hace por ti, dicha herramienta es XSScrapy.

  1. Instalación y uso de XSScrapy

XSScrapy es una aplicación fácil de instalar y de usar, como ya os imaginaréis se basa en Scrapy y permite encontrar vulnerabilidades del estilo XSS (tanto reflejado como almacenado) y también vulnerabilidades del tipo SQLi. El proyecto se encuentra alojado en el siguiente repositorio de GitHub https://github.com/DanMcInerney/xsscrapy y para instalarlo basta con utilizar el comando “pip” junto con el fichero de dependencias.

>git clone https://github.com/DanMcInerney/xsscrapy.git && cd xsscrapy

>pip install -r requirements.txt

A continuación se puede comenzar a probar la aplicación, que sobresale por su simplicidad.

>./xsscrapy.py -h

usage: xsscrapy.py [-h] [-u URL] [-l LOGIN] [-p PASSWORD] [-c CONNECTIONS]

[-r RATELIMIT] [–basic]

optional arguments:

-h, –help show this help message and exit

-u URL, –url URL URL to scan; -u http://example.com

-l LOGIN, –login LOGIN

Login name; -l danmcinerney

-p PASSWORD, –password PASSWORD

Password; -p pa$$w0rd

-c CONNECTIONS, –connections CONNECTIONS

Set the max number of simultaneous connections

allowed, default=30

-r RATELIMIT, –ratelimit RATELIMIT

Rate in requests per minute, default=0

–basic Use HTTP Basic Auth to login

Evidentemente la opción que resulta más interesante es en la que se puede definir la URL (-u/–url) del objetivo y a partir de allí, comenzar a ejecutar el procesamiento de enlaces y peticiones/respuestas HTTP. Otra opción interesante es la que permite establecer el número de conexiones simultaneas máximo contra el sitio web en cuestión (-c/–connections) algo que resulta muy practico para evitar que un WAF detecte el ataque y bloquee las peticiones desde la IP donde se realizan. Además, en el caso de que el sitio web requiera autenticación (digest o basic) es posible indicar un usuario y una contraseña con los interruptores -l y -p.
Ahora que tenemos una imagen general del funcionamiento del programa, podemos comenzar a utilizarlo con una aplicación web vulnerable. Existen aplicaciones web para realizar pruebas de penetración de todos los gustos y colores, algunas de ellas ya las he mencionado y explicado en varias ocasiones en este sitio, tales como DOJO InsecureWebApp, Hacme Casino, DVWA (Damn Vulnerable Web Application), WebGoat, etc. En esta ocasión vamos a utilizar Django-Moth, una aplicación web vulnerable escrita en Django que puedes descargar libremente desde aquí: https://github.com/andresriancho/django-moth pero si lo prefieres puedes utilizar cualquier otra, a efectos prácticos da un poco igual.

Después de descargar el proyecto del repositorio GitHub, se puede iniciar la aplicación Django de la siguiente forma:

>python manage runserver 8080

Performing system checks…

System check identified no issues (0 silenced).

February 18, 2015 – 17:05:08

Django version 1.7.1, using settings ‘djmoth.settings’

Starting development server at http://127.0.0.1:8080/

Quit the server with CONTROL-C.

El puerto por defecto es el 8000, pero como se puede apreciar se puede cambiar por cualquier otro. Recordar que se trata de una aplicación web con vulnerabilidades fáciles de explotar, evitar utilizarla en Internet y mucho menos, utilizar un puerto como el 80 que requiere privilegios de root.

Todas las vulnerabilidades de Django Moth se encuentran separadas por secciones, pero aun así, el crawler de XSScrapy, a la fecha de redactar este articulo, no permite establecer reglas para indicar en qué momento debe detenerse el ataque y cuales son los enlaces que se permite visitar. Tal falta de control es un problema a la larga, ya que muchas páginas tienen enlaces a otros dominios y es fácil que el proceso recursivo termine llevando al crawler a sitios que no deberían analizarse, así que hay que estar atentos a las trazas que arroja el programa en todo momento. Ahora se puede ejecutar algo como lo siguiente:

./xsscrapy.py -u http://localhost:8080/audit/os_commanding/blind_osc.py?cmd=ls

Se podrán ver varias trazas y los elementos que la herramienta va analizando en cada iteración. En el caso de interrumpir el proceso manualmente o que termine debido a que ya se han recorrido todos los enlaces, se genera automáticamente un fichero con nombre: “xsscrapy-vulns.txt” el cual contiene todos los resultados encontrados. Incluye cosas como las vulnerabilidades encontradas, puntos de inyección, parámetros utilizados, la petición y respuesta del servidor, etc.

Una herramienta interesante con mucho potencial y aunque a mi juicio se puede explotar mucho más el framework de Scrapy, puede resultar muy instructiva para aprender detalles avanzados del framework, eso si, solamente si estas dispuesto a ver el código y entender cómo funciona, algo que desde luego te recomendaría ya que tiene detalles técnicos muy valiosos y que te ayudarán a aprender ciertos “trucos” a la hora de crear tus propias herramientas.

Un saludo y Happy Hack!
Adastra.

Vulnerabilidades comunes en HTML5 – Configuraciones inseguras con CORS – Parte 1

octubre 8, 2014 4 comentarios

HTML5 en una especificación muy conocida que permite a los desarrolladores crear aplicaciones del tipo RIA (Rich Internet Applications) y aunque incluye características que se encuentran soportadas en prácticamente todos los navegadores modernos, algunas de dichas características pueden representar problemas de seguridad muy serios que en versiones previas de HTML5 no se presentaban. HTML5 ahora es una combinación de varios elementos que permiten mejorar la navegabilidad y la experiencia de usuario gracias al uso de componentes como XMLHttpRequest2 (XHR-Level2), Web Sockets, Cross Origin Resource Sharing (CORS), localstorage, webSQL y otras mejoras relacionadas con el renderizado de componentes HTML en el navegador web. Muchas de estas nuevas características recaen directamente sobre el navegador del cliente y habilitan un espectro de ataque mucho más amplio que con versiones antiguas de la especificación, algo que los atacantes en Internet ahora buscan y explotan diariamente.
Algunos de los escenarios de ataque más comunes en navegadores y aplicaciones que soportan HTML5 y que no se encuentran debidamente aseguradas se listan a continuación.

CORS y ataques CSRF

SOP (Same Origin Policy) es una política que ha sido bastante efectiva a la hora de impedir que un dominio concreto pueda acceder a recursos de un dominio distinto. Por este motivo, gracias a SOP un dominio determinado no puede acceder directamente a los recursos (tales como cookies, árbol DOM, comunicaciones, etc) de un dominio distinto del suyo. En la especificación de HTML5, se ha implementado una característica interesante llamada CORS (Cross Origin Resource Sharing), la cual relaja un poco la política SOP y permite que los recursos de un dominio concreto se puedan compartir con otros dominios. Para hacer uso de esta característica, solamente es necesario utilizar algunas cabeceras HTTP que un navegador con soporte a CORS, entenderá y utilizará adecuadamente. El problema con este mecanismo, es que si no se configura adecuadamente, podría permitirle a un atacante acceder a recursos sensibles de un dominio concreto (como cookies de sesión) y llevar a cabo un ataque típico del tipo CSRF. Las cabeceras HTTP que le dan sentido CORS y que permiten una potencial brecha de seguridad son las siguientes:
Petición
Origin, Access-Control-Request-Method, Access-Control-Request-Headers
Respuesta
Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Allow-Expose-Headers, Access-Control-Allow-Max-Age, Access-Control-Allow-Allow-Methods, Access-Control-Allow-Allow-Headers

Estas cabeceras son específicas para el funcionamiento de CORS y en el caso de que se encuentren incluidas en las respuestas devueltas por un servidor web, indica que CORS es soportado y que posiblemente, un atacante puede acceder a recursos compartidos a los que normalmente no debería tener autorización.

Ejemplo:
Suponiendo que la víctima tiene abierto en su navegador varias pestañas con sitios web en los que se encuentra navegando. Uno de dichos sitios tiene CORS habilitado y las respuestas a las peticiones incluyen la cabecera “Access-Control-Allow-Origin” con el valor “*” y otro de dichos sitios web es controlado por un atacante en Internet.
El atacante enviará un script malicioso al navegador de la víctima que se encargará de utilizar el objeto XMLHttpRequest para ejecutar una petición POST hacia el dominio que tiene CORS habilitado, es un dominio *distinto* del dominio del atacante y dicha petición será silenciosa y pasará inadvertida para el usuario, ya que su navegabilidad no se verá afectada y los componentes HTML que se encuentra visualizando no han tenido ningún tipo de cambio.
Con las condiciones descritas anteriormente, el atacante podrá acceder a datos sensibles del usuario que se encuentra autenticado en la aplicación web vulnerable, accediendo de esta forma a recursos tan importantes como la cookie de sesión del sitio web en el que el usuario se ha identificado, dando lugar a una fuga de información y posteriormente a un ataque de suplantación de identidad utilizando la información de acceso (cookie de sesión) del usuario identificado. En efecto, estamos hablando de un ataque clásico del tipo CSRF.
La siguiente imagen enseña un sitio web con CORS habilitado y como se puede apreciar, la cabecera “Access-Control-Allow-Origin” tiene el valor “*”

Sin nombre

Si el usuario se encuentra logueado y navega a un sitio web controlado por un atacante, el cual contiene un script como el que se enseña a continuación, el atacante podrá acceder a información sensible que le permitirá suplantar la identidad del usuario.

	<script language= “javascript” type= “text/javascript">
	function corsrequest() {
		var http;
		http = XMLHttpRequest();
		http.open(“POST”, “http://vulncors-site.com/”, true);
		http.setRequestHeader(“Content-Type”, “text/plain”);
		http.withCredentials= “true”;
		http.onreadystatechange = function() {
		if (http.readyState == 4) {
			var response = http.responseText
			document.getElementById(“responseFromVictim”).innerHTML = response;
		}
	}
	http.send(null)
	}
	</script>

Como se puede apreciar, el atacante realizará una petición “POST” al sitio web vulnerable con el fin de recuperar información sobre el usuario identificado en el sistema, para tal fin incluye el atributo “withCredentials” con el valor “true” para que el servidor web replique en la respuesta el contenido de la cookie de sesión del usuario. Hasta este punto, el atacante tiene todos los elementos necesarios para suplantar la identidad del usuario sin mayores dificultades, produciendo una vulnerabilidad del tipo CSRF.

CORS y CORJacking
Continuando con la explicación sobre las posibles brechas de seguridad que pueden incluirse con CORS, otro tipo de vulnerabilidad que se presenta en las aplicaciones web RIA con HTML5 es la conocida como CORJacking, la cual consiste en la capacidad que tiene un atacante de modificar dinámicamente la estructura DOM de un sitio web con CORS habilitado y mal configurado. De esta forma, el atacante podrá modificar algunos atributos de los elementos cargados en el árbol DOM del sitio web con CORS habilitado e incorrectamente configurado, para controlar la interacción del usuario con los contenidos del sitio web vulnerable.

Ejemplo:
Suponiendo que una aplicación web con CORS habilitado y mal configurado tiene un elemento dinámico como por ejemplo un fichero Flash, SilverLight o un fichero de vídeo o audio. Un atacante puede suplantar dicho contenido navegando por la estructura DOM y modificar la ubicación de dicho recurso por otra ruta que apunte a un recurso cuidadosamente creado por el atacante. Si el contenido dinámico servido por el atacante, tiene la misma apariencia visual que el contenido original de la aplicación web, el usuario no notará la diferencia y creerá que interactúa con el elemento original. Más grave aun, cuando se trata de contenidos Flash o similares que intervienen en operaciones de negocio de la aplicación, como por ejemplo un componente en Flash para recibir las credenciales de acceso de los usuarios.

Etiquetas, atributos y eventos HTML5 inseguros

Algunos etiquetas de las especificaciones anteriores de HTML contienen atributos y eventos muy interesantes que permiten que un usuario pueda interactuar de una forma mucho más amigable con dichos elementos, sin embargo, muchos de los nuevos atributos y etiquetas en HTML5 permiten la ejecución de código JavaScript, algo de lo que se podría aprovechar un atacante para producir vulnerabilidades XSS o CSRF.

Ejemplo:
Hay varios atributos y etiquetas nuevas en HTML5 que permiten la ejecución de código JavaScript de forma nativa. Una de las más comunes, es la etiqueta “video” y su atributo “onerror” que se activará automáticamente cuando el recurso que debe cargar la etiqueta “video” no puede cargarse.

<video source onerror="javascript:alert(‘XSS’)">

El atributo “autofocus” que en HTML5 se encuentra disponible en todos los elementos HTML de entrada, también puede representar un problema cuando no se valida adecuadamente el valor del atributo “onfocus” en el momento en el que se recarga la página.

<input autofocus onfocus= alert(‘XSS’)>
<select autofocus onfocus= alert(‘XSS’)>
<textarea autofocus onfocus= alert(‘XSS’)>
<keygen autofocus onfocus= alert(‘XSS’)>
<keygen autofocus onfocus= write(‘XSS’)>
 

Otro atributo potencialmente peligroso es “formaction” de la etiqueta “form”, el cual también admite la ejecución de código JavaScript.

<input autofocus onfocus= alert(‘XSS’)>
<select autofocus onfocus= alert(‘XSS’)>
<textarea autofocus onfocus= alert(‘XSS’)>
<keygen autofocus onfocus= alert(‘XSS’)>
<keygen autofocus onfocus= write(‘XSS’)>
 

Existen varias etiquetas y atributos que son consideradas peligrosas si no se aplican las validaciones de datos adecuadas, para ver una lista mucho más completa, se recomienda visitar el sitio HTML5 Security Cheatsheet: https://html5sec.org/

En una próxima entrada, más sobre riesgos y vulnerabilidades cuando en el uso de las nuevas características implementadas en HTML5

Un saludo y Happy Hack!

WEB HACKING – Atacando DOJO InsecureWebApp – Arachni contra Insecure WebApp – Parte XXXI

julio 17, 2013 Deja un comentario

Como se ha visto en el articulo anterior, algunos de los plugins de W3AF son bastante útiles para conseguir de forma rápida, información sobre una aplicación web y la infraestructura del servidor. En el articulo anterior, solamente se han incluido algunos plugins de descubrimiento de W3AF, en esta publicación, vamos a utilizar algunos de los plugins de auditoria y haremos una corta introducción a Arachni, el cual, como en el caso de W3AF, es una herramienta muy completa para la ejecución de pruebas de penetración contra aplicaciones web y aunque ya viene incluida en Dojo, es interesante realizar una instalación manual de la herramienta con la última versión disponible.

Leer más…

WEB HACKING – Atacando DOJO InsecureWebApp – Enumeración – Parte XXX

junio 13, 2013 Deja un comentario

Otra aplicación web vulnerable existente en DOJO es InsecureWebApp, dicha aplicación se encuentra escrita en JSP y contiene una buena cantidad de ejemplos de funciones vulnerables que pueden ser explotadas fácilmente. En los siguientes posts hablaré sobre dichas vulnerabilidades y como es posible explotarlas. El primer paso, como se ha mencionado en muchas ocasiones, es el de recolectar tanta información como sea posible sobre la aplicación web. No solamente son importantes los detalles técnicos, también es muy importante conocer detalles funcionales sobre la aplicación en cuestión, saber para que está hecha y en general cuales son sus características.

Leer más…

WEB HACKING – Atacando DOJO Hackme Casino – Sesiones inseguras en Ruby On Rails – Parte XXIX

mayo 16, 2013 Deja un comentario

Cuando se utiliza una plataforma como Ruby OnRails, es conveniente tener presente que hay ciertas “buenas practicas” que se deben seguir para desarrollar de forma segura, muchas de esas practicas, como prácticamente todo en el mundo de la seguridad informática, son simplemente de sentido común, otras resultan un poco más complicadas de entender y de cumplir. Sin embargo, en el caso de las sesiones que se pueden manejar en Ruby OnRails, es importante para un desarrollador, entender, cumplir y comprobar que se siguen las pautas adecuadas para tener la información segura y el sistema funcionando como corresponde. La razón por la que es importante prestarle atención a las sesiones en Ruby OnRails, radica en que existen varios métodos de almacenamiento que pueden ser implementados y que si no somos lo suficientemente prudentes, nos podemos encontrar con que la información que tenemos almacenada en dichas sesiones puede ser fácilmente comprometida por un atacante, que es justo lo que ocurre con HackMe Casino. Antes de entrar en la parte practica de está publicación, intentaré explicar un poco, como es el funcionamiento de las Sesiones en Ruby OnRails (que es más flexible que en otros lenguajes de programación tradicionales como JSP o PHP)

Leer más…

WEB HACKING – Atacando DOJO Hacme Casino – Controladores inseguros en Ruby OnRails – Parte XXVIII

HacMe Casino es una aplicación deliberadamente vulnerable que se encuentra escrita utilizando el framework Ruby On Rails, hasta este punto se han mencionado algunas vulnerabilidades que se suelen encontrar en muchas aplicaciones web, independiente de la plataforma utilizada, tales como SQL Injections, XSS Stored/Reflected, CSRF, Session Fixation, etc. Sin embargo, para un atacante siempre resulta útil conocer como funciona la plataforma que es utilizada para servir el sitio web, tanto el lenguaje de programación como el servidor, como se ha mencionado en reiteradas ocasiones, la información es la clave, entre más información se cuente sobre un objetivo, es mucho más probable realizar ataques exitosos.

Leer más…

WEB HACKING – Atacando DOJO Hacme Casino – Otras Vulnerabilidades Parte XXVII

Las dos vulnerabilidades que se han explicado anteriormente sobre HacMe Casino, permitían que cualquiera pudiera acceder y manipular de forma arbitraria, la información de otros usuarios en el sistema. En está ocasión se examinarán otras vulnerabilidades existentes en la aplicación para poder analizar su impacto.

Leer más…

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 1.543 seguidores

A %d blogueros les gusta esto: