[HACK] Por que es IIS tan inseguro? (y posible denegacion de servicio)

[David A. Pérez]

Hola,

Hace algo mas de un mes, intercambie unos correos con el equipo de
seguridad de Microsoft con referencia a ciertos comportamientos extraños
del IIS. La respuesta final de Microsoft fue:

"We've looked at what you have sent us, we don't believe this is a
vulnerability. However, in looking at what you've sent us and the
suggestions you've made, we see that we can make some improvements in how
this particular scenario is handled."

Os voy a exponer los detalles a ver que opinais vosotros.

Poco despues de la aparicion del desbordamiento de buffer en la libreria
"idq.dll" me puse a hacer algunas pruebas sobre un servidor IIS 5.0
actualizado con los ultimos parches. Comenze enviando largas cadenas de
texto la puerto 80 del estilo:

GET /A*n HTTP/1.0

Me dedique a enviar caracteres "A" n veces. Empece con n=1000 y fui
subiendo hasta 100.000, sin que en ninguna de las ocasiones se cerrara el
socket. IIS recibio los 100.000 caracteres y se quedo tan ancho, eso si,
mientras los recibia el proceso inetinfo.exe uso la CPU al 100%. Una
detalle curioso es que el sistema no requirio mas memoria para recibir la
cadena. Las mismas pruebas con un Apache cerraron el socket despues de
unos 500 caracteres.

A continuacion hice la siguiente prueba:

GET /A*n.htm HTTP/1.0

Para un valor de n=1000 IIS responde con un error 414 (URL to long). Es
curioso que podamos transmitir al socket una cadena tan larga como
queramos, pero que si solicitamos un archivo HTM nos responda con un 414.
Tambien resulta curioso que si cambiamos ".htm" por ".asp" (o ".htr", o
".htw", o cualquiera de las extensiones que esten mapeadas a una DLL), en
vez de un error 414 IIS nos devuelve un error 404 (Not found). Imagino que
este tipo de comportamiento es el que convierte IIS en un servidor HTTP
tan prolifico en desbordamientos de buffer.

Continuando con las pruebas, modifique la configuracion del IIS para
redirigir los errorres 404 a otra pagina. En este caso, cuando usamos la
cadena "A*n.htm" continuamos obteniendo un error 414, pero al usar la
cadena "A*n.asp", nos redirecciono usando el codigo 302 (Object moved) a
la pagina especificada en la configuracion. El problema en este caso es
que IIS responde lo siguiente:

Location: /?404;http://127.0.0.1/A*n.asp

Desde mi punto de vista, esto es un error, puesto que un navegador que
recibiera esa respuesta y no la truncara, se intentaria conectar de nuevo
y recibieria otra vez un error 302 entrando en un bucle del que podria ser
dificil salir si el navegador deja de responder.

Este tipo de comportamiento se puede observar en el IE 6.0, a pesar de que
en el IE 5.5 no se puede repoducir. La razon de que el IE 5.5 no entre en
el bucle es debido a que el IE 5.5 trunca la respuesta y la convierte en:

Location: 404;http://127.0.0.1/LongString.asp (Faltan los caracteres "/?"
antes del 404)

Basicamente tenemos dos errores, uno en IIS y otro en IE:

a) IIS deberia de cerrar el socket al recibir cierto numero de caracteres,
o en su defecto, devolver un error 414 si la URL es muy larga, en vez de
devolver un error 404 o 302 si la URL es una pagina mapeada a una DLL, o
en su defecto, truncar las respuestas "Location:"

b) IE 6.0 deberia de truncar las respuestas "Location:"

Este tipo de comportamiento me permitio efectuar ataques de denegacion de
servicio sobre el servidor IIS abriendo 20 conexiones al servidor enviando
100.000 carcateres en cada una de ellas. La CPU del servidor comienza a
usarse al 100% y le impide servir paginas estaticas o dinamicas a otros
clientes mientras no se cierren estas conexiones. Este tipo de prueba lo
hice en red local usando una conexion full duplex de 100 Mbps.

Ademas, cuando configure el servidor para redirigir los errores 404 a otra
pagina, consegui crear un ataque de denegacion de servicio distribuido.
Configure una pagina en un servidor que abria una segunda ventana
apuntando al servidor al que queria denegar el servicio. La pagina que los
clientes tenian que abrir era:

HTTP://SERVER/A*n.asp

Los clientes usaban IE 6.0 y n=1000. Todos los clientes IE 6.0 entraban en
el bucle y a partir de la 5 conexion el servidor se ralentizaba,
probablemente por la cantidad de informacion que tenia que guardar en los
archivos log.

Eso es todo, gracias por leer.

Salu2,

    kamborio
================
 David A. Pérez
 _                       _                   _
| | __  __ _  _ __ ___  | |__    ___   _ __ (_)  ___
| |/ / / _` || '_ ` _ \ | '_ \  / _ \ | '__|| | / _ \
|   < | (_| || | | | | || |_) || (_) || |   | || (_) |
|_|\_\ \__,_||_| |_| |_||_.__/  \___/ |_|   |_| \___/
      El perdón es la venganza de los buenos (anónimo)