sábado, 24 de febrero de 2018

[Javascript] XSS; True. Y ahora, que ?

El mundo del Pentesting lo encuentro super apasionante, siempre un desafió nuevo. Siempre con las mismas energias desde del primer dia (y sumando). 
Claro también toca lidiar con la documentación 😭😭 . En donde se debe detallar de manera amigable los distintos hallazgos.

Cuando me toca documentar a los ultra famosos XSS, en las POCs, solía poner un clásico "alert()", con algún amigable mensaje.




Hasta que sume varias contras del tipo: "XSS; True. Y ahora, que ?", "si es cierto,sacaste un alert() y eso como me afecta" y muchas variantes que mas o menos apuntan a lo mismo.
y desde entonces a mis pocs reportadas les pongo mas color (colores para cada caso, xd)

Desde entonces experimento con las distintas alternativas que puede ofrecerle Javascript a un atacante. que poco a poco ire compartiendo.

Procurare presentarles distintos scripts para ser usandos tomando como base que ya hemos conseguido la explotación de un XSS (cualquiera de sus variantes ) que permita embeber javascript y ser "comido" por el browser.

Sabemos que el visitar un sitio web a través de nuestro navegador, implica enviar una petición al servidor que hostea el sitio, esa acción sera respondida con el código conformado por HTML y JavaScript, código que tomara e interpretara nuestro navegador.

Si nos enfocamos en javascript, estamos hablando de un lenguaje de codigo que sera interpretado(no compilado!) por el navegador(client-side). Si bien existe una version de Javascript del lado del servidor (Server-side: Node.js), escapa al alcance que le quiero dar a los próximos post


AMBITO DE JAVASCRIPT:

JavaScript fue diseñado de forma que se ejecutara en un entorno muy limitado que permitiera a los usuarios confiar en la ejecución de los scripts. De esta forma sus scripts no pueden comunicarse con recursos que no pertenezcan al mismo dominio desde el que se descargó el script.

Los scripts tampoco pueden cerrar ventanas que no hayan abierto esos mismos scripts. Las ventanas que se crean no pueden ser demasiado pequeñas ni demasiado grandes ni colocarse fuera de la vista del usuario (aunque los detalles concretos dependen de cada navegador). Además, los scripts no pueden acceder a los archivos del ordenador del usuario (ni en modo lectura ni en modo escritura) y tampoco pueden leer o modificar las preferencias del navegador.

Por último, si la ejecución de un script dura demasiado tiempo (por ejemplo por un error de programación -talvez un bucle infinito-) el navegador informa al usuario de que un script está consumiendo demasiados recursos y le da la posibilidad de detener su ejecución.

A pesar de todo, existen alternativas para poder saltarse algunas de las limitaciones anteriores. 


SAME-ORIGIN POLICY

Javascript trae consigo una limitación o mas bien una imposición por parte de los navegadores:

Al intercambio de peticiones entre distintos dominios se denomina "CROSSDOMAIN". Los navegadores actuales llevan un mecanismo de seguridad (Same-Origin Policy )que impide que desde javascript se puedan hacer este tipo de peticiones.

Esta política hace que el código que se carga en una pestaña de un navegador pueda acceder solo a datos de páginas del mismo dominio, es decir, que un código JavaScript no podría nunca acceder a la cookie o ningún elemento que compongan la página servida desde otro dominio. Es por ello que para poder acceder a los datos de otra pestaña se utilizan, por ejemplo, los ataques de Cross-Site Scripting, ya que consiguen inyectar código en la pestaña del dominio víctima.


QUE ES UN "XSS"?

XSS o Cross-Site Scripting es una vulnerabilidad ya conocida desde hace ya mucho tiempo. Junto a las famosas SQLi(inyecciones de SQL) lideran el top de los fallos mas habituales, por lo que se les otorgo un lugar privilegiado dentro del TOP 10 de OWASP.

Son ataques que sacan ventajan de la poco (o nula) validacion de de datos que son ingresados al sitio. Pensemos en posibles entradas de datos; foros, chats, libros de visita, foros, el espacio que muestra los usuarios conectados,etc..., las posibilidades son muchas (proporcional a la imaginacion del atacante)

Esta técnica de ataque forzara a un sitio web a ejecutar el código suministrado por un atacante. 
Un uso interesate para la explotacion de XSS podria ser el robo de cookies de session, en donde nos valdremos de la propiedad "document.cookie".

Este tipo de vulnerabilidad puede ser explotada de dos maneras: de forma reflejada y de forma reflejado. A continuación, haré una breve explicación de cada una.


TIPOS DE XSS:

PERSISTENTE:
Un Cross-Site Script persistente involucra a aquellas inyecciones que quedaran almacenadas en el portal web, afectando a todas las personas que visiten la pagina.

REFLEJADO
Es el tipo de ataque XSS más habitual y consiste en editar los valores que se pasan mediante URL,
cambiando el tipo de dato pasado del usuario a la web, haciendo que ese código insertado se ejecute en dicho sitio.


Linda introducción, Y AHORA QUE ?

[+] Función JS que determine host vivos:
Se me ocurrió programar una sencilla función que identifique host vivos.




Ya sabemos que desde javascript, solo podemos hacer solicitudes HTTP a su propio dominio (a menos que se utilicen encabezados CORS .)
Automáticamente las respuestas seran siempre unos mensajes de errores en un hermoso rojo.

Y eso es bueno, por que esos mensajes de error nos dan toda la información que necesitamos 

HOST VIVO:


HOST VIVO, puerto (81) cerrado:


HOST  CAIDO



Bien, ya tenemos una función, que puede distinguir equipos vivos en la red (local) para usar como carga util en un XSS y enviar los resultados a algún sitio controlado por el atacante (nosotros? ).

// --------------------------------------
// El script lo subi a: https://github.com/ezelf/giveMeXss/blob/master/poc_1/jsNMap.js
// --------------------------------------

continuara...


Saludos,
@capital_alfa

No hay comentarios.:

Publicar un comentario