Archivo

Posts Tagged ‘ataques web directos’

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

octubre 8, 2014 1 comentario

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…

WEB HACKING – Atacando DOJO Hacme Casino – Vulnerabilidad CSRF Parte XXVI

abril 30, 2013 1 comentario

En el articulo anterior, ya teníamos acceso a la aplicación utilizando una cuenta de usuario valida, gracias a una vulnerabilidad de SQL Injection que permitía realizar un “ByPass” del mecanismo de autenticación implementado (login/password). Se trata de una vulnerabilidad que, aunque cada vez suele ser más rara de encontrar, sirve para demostrar lo que es una Blind SQL Injection en todo su esplendor…

En esta ocasión, aprovechando que ya se cuenta con acceso a la aplicación, se procederá a analizar las algunas peticiones HTTP de la aplicación para intentar detectar cualquier otra “brecha” que nos permita hacer más “daño”. Para ello, como el lector seguramente ya comprenderá, basta con utilizar un proxy web como por ejemplo Burp Proxy, OWASP Zap o incluso algún que otro plugin de Firefox que sirve, básicamente para lo mismo, como por ejemplo Tamper Data o Live HTTP Headers.

Leer más…

Seguir

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

Únete a otros 1.119 seguidores

A %d blogueros les gusta esto: