07 enero 2012

Slow Read: nuevo mecanismo DoS de servidores web


 
Las conexiones a Internet avanzan a una velocidad inusitada para poder dar un mejor servicio a los usuarios. Los ISPs, cada vez más, ofrecen anchos de banda descomunales a aquellos clientes que alojan sus páginas web. Lejos y atrás quedaron los tiempos en los que conseguir acceso (ya sea de forma lícita… o por las bravas) a una máquina con un gran ancho de banda, permitía tener el bastón de mando para "DoS-ear" servidores con conexiones a Internet más modestas.  

Por ello, actualmente, si no es mediante una botnet potente o una convocatoria Anonymous, hay que buscar alternativas a efectuar un DoS, que nada tengan que ver con colapsar las capacidades de ancho de banda del servidor. Así pues, tres de los últimos tipos de ataques DoS de servidores web, se basan precisamente en el envío de tráfico "muy lentamente", colapsando el número de sesiones máximas disponibles en el servidor.

Contando con predecesores como Slowloris y "Slow HTTP POST", Sergey Shekyan, desarrollador en Qualys, ha descubierto una nueva manera de colapsar servidores, y lo ha llamado "Slow Read".
 
Por resumir un poco el funcionamiento de los ataques DoS anteriores: 
  • En Slowloris, las peticiones al servidor se realizan enviando las cabeceras de la petición muy lentamente, no terminando nunca de ser enviadas. De esta manera, mientras el servidor no recibe todas las cabeceras, no considera como sesión web establecida, y no sabe si ha superado el número de conexiones máximas configuradas (por ejemplo, en Apache mediante la variable maxclients).
  • En Slow HTTP POST, se envían al servidor las peticiones POST con todas las cabeceras, incluyendo "Content-Length" que indica el tamaño del POST DATA a enviar. Así, el servidor queda esperando a que el cliente envíe tantos bytes, como indique la cabecera "Content-Length". El ataque en sí se basa en que, los datos del POST, los irá enviando muy despacio el cliente hacia el servidor, consumiendo una sesión abierta por cada POST, así como los recursos que reserva el servidor para recibir los datos que envía el cliente.
En el caso del nuevo ataque DoS, Slow Read, el procedimiento consiste en enviar una petición lícita a un servidor, sin embargo, el éxito radica en ralentizar lo máximo posible la recepción de los datos por parte del servidor hacia el cliente. Al ser TCP el protocolo web, es decir, orientado a la conexión y con control de errores, hasta que el servidor no recibe los correspondientes paquetes con Flag ACK indicando al servidor que prosiga enviando el resto de los datos, no se dará por finalizada la sesión, y por ende, los recursos no serán liberados en el servidor.

Mitigar este tipo de ataques resulta muy complicado, puesto que no se basan en patrones detectables por mecanismos como IPS o WAF debido al tipo de la petición. De hecho, el WAF libre mod_security, implementa mecanismos que permiten mitigar este y otros tipos de Denegaciones de Servicio, en base a limitar el número de conexiones por IP origen que se encuentren en estado SERVER_BUSY_WRITE, mediante la configuración de la directiva SecWriteStateLimit. Otra forma de mitigación de este tipo de ataques es mediante la inclusión de límites de tiempo existentes por cada conexión, a la hora de recibir cabeceras, así como en las transmisiones de datos en el envío o de recepción. Sin embargo, estas medidas son peligrosas puesto que cuando las conexiones se efectúan tras un proxy de forma lícita por muchos clientes, se pueden dar situaciones que provoquen un falso positivo denegando un montón de conexiones.
Para poder hacer pruebas, evidentemente con fines académicos y en ningún momento con intenciones destructivas, se ha publicado de forma libre la herramienta Slowhttptest, que implementa los tres tipos de ataque descritos en este artículo.

En el blog de Spider Labs, han publicado una excelente revisión de la herramienta Slowhttptest.

5 comments :

Juan Aguilera dijo...

Qué interesante. Lo que se llega a aprender con vosotros, de verdad. :)

PD: Muy explícita la imagen. ;)

Security dijo...

El colectivo de protesta Anonymous publica parte de la base de clientes de Terra como critica a la poca seguridad de Telefonica, incitando denunciar a la operadora:

------------------------
WIKILEAKS TELEFONICA
------------------------

http://pastebin.com/YALD5Mgg

Daniel Lopez dijo...

Gracias por el articulo, es bueno tenerlos a ustedes para que lo actualizen a uno en estos temas de la seguridad informatica

Ysm51 dijo...

Han probado el #fhttp?, es un framework de pentesteting desarrollado por xianur0, viene con un modulo para hacer test de estrés al protocolo http, un modulo muy potente, se basa en peticiones head, al parecer nadie lo ha logrado mitigar con exito, siempre les limita el hardware, seria interesante un review sobre esta tool. 


Enlace la wiki:
http://sourceforge.net/apps/mediawiki/fhttp/index.php?title=Main_Page


Saludos!

Borja Ferrer dijo...

Que bueno, es curioso, k despues de tanto estudiar redes a muchos nos sorprende la "sencillez" de la solucion. Siempre dí por supuesto que el servidor tendria un limite de tiempo para la informacion que recibe de cada cliente, igual que un cliente lo tiene de un servidor, nunca pense que se pudiera implementar un ataque en ese sentido, slow data flow... además de que los requisitos de recursos, una vez implementada la solucion, son "relativamente" poco exigentes. Que gran articulo, una grata sorpresa para un lunes ^^