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

[The Tahum]

Hola, kamborio. decías...

> 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.

Esto es debido principalmente a que en Microsoft programan los del
departamento de Marketing. Todos los productos de esta son vendidos como la
panacea en los negocios, y se pensó o debió pensar que el tratado de largas
direcciones HTTP es sinónimo de robustez y poderío. En principio si se
tratan las direcciones de forma correcta no se debería colapsar la CPU, lo
que en sí representa una basta negligencia.


> 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.

Debido a que el comportamiento de IIS está estréchamente ligado al tipo de
archivos que se usan en sesiones HTTP, como los asp, dll, etc. Este tipo de
dependencia o de excesiva compatibilidad ha desembocado más de una vez en
problemas... sobretodo en los archivos de tipo asp. De por sí esto no puede
considerarse una vulnerabilidad pero ciertamente es curioso, y si se
investiga quizá se logre algo. El problemas de los overruns y IIS ha estado
anclado a isapi y su inutilidad para manipular inputs...


> 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.

Distribuido no, según dices solo interviene el servidor web como 'cliente'
del cliente en la sesión http. Serviría como anonimizador pero hasta ahí, a
no ser que en esa máquina coloques un 'script' que interprete ese tipo de
direcciones y actue como difusor con otras máquinas con IIS igualmente
configuradas, de modo que sí se entraría en un ataque 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.

Ojo, esto sería otro log. Si puedes configurar 10 clientes para que lancen
de forma secuencial peticiones HTTP al servidor con cadenas extremadamente
largas, bien no lo colgarás, pero al cabo de unos pocos días es posible que
guarde megas y megas de logs al día, y si la máquina no se encuentra
debídamente atendida...

>
> Eso es todo, gracias por leer.

A ti, por exponernos esta vulnerabilidad.

Un saludo,
 Tahum.

---
Tahum - Tahum at phreaker.net / Tahum at acmemail.net
Programador y administrador de redes.