Buscando ataques DOS

Una de las pruebas que más preocupa siempre en las auditorías de seguridad es la de los ataques de Denegación de Servicio (DoS). Esta preocupación suele ser porque si el sistema no aguanta, entonces afecta directamente al negocio. Los proveedores de Internet que están dando hosting de servicios profesionales ya tienen obligatoriamente que tener algún servicio serio de mitigación para este tipo de ataques. Como sabéis, uno de los correos que yo leo siempre sobre las cosas que me piden tiene que ver con una petición de este tipo.

Figura 1: Petición de DOS

Mi compañero en Eleven Paths, David Barroso (@lostinsecurity) ha hablado muchas veces de este tipo de ataques, utilizando diferentes medidas de ataque, y de los servicios de CloudFlare para mitigar estas situaciones. Para ilustrar la importancia que cobran hoy en día, siempre pone este vídeo de los servicios DDOS que se anuncian en Internet.

Figura 2: Vídeo de anuncio de servicios DDOS profesionales

Los servicios de una empresa, cuando sean cores, no pueden estar desprotegidos contra este tipo de ataques, y además de las pruebas de pentesting continuo deben realizarse también las pruebas de DDOS. Entre esas pruebas, no solo hay que ver si el sistema aguanta el volumen de tráfico masivo, que para eso ya hay sistemas y soluciones que ofrecen esa protección, sino que hay que buscar los límites de carga de las aplicaciones hospeadas que pueden tirar los servicios.

La idea es tan sencilla como que ciertas operaciones complejas de una aplicación web pueden requerir de mucho trabajo en cuanto a cómputo, memoria o almacenamiento en disco, y con una petición sostenida sin necesidad de que sea masiva, sea posible tumbar el sitio. 

En una instancia de una base de datos configurada sin límites, es decir, con valores unlimited en el tamaño de memoria, el número de threads o el crecimiento de los tablespaces y los datafiles, cae con un ataque de SQL Injection con un simple 'or '1'='1 tras generarse el volcado de una consulta compleja que use varios joins y resulte en varios millones de registros. Si es lanzada cuatro o cinco veces puede conseguir tumbar los límites físico del servidor donde esta siendo hospeda.

Yo sin querer he tumbado alguna instancia haciendo pruebas con las consultas pesadas, y en Marathon Tool fue necesario poner un intervalo de tiempo de descanso para no tumbar las instancias que empezaban a dejar de responder después de tener que merendarse unas consultas de varios milloncejos de registros en consultas con ocho o diez tablas en join. 

Figura 3: Pausas después de consultas en Marathon Tool

En estos ejemplos que estoy contando existen vulnerabilidades de SQL Injection, pero a veces el bug de denegación de servicio es el más que común cuadro de diálogo de búsqueda. En el caso de la página de búsqueda de sitios web hay algunas de ellas especialmente vulnerables a estos tipos de ataques porque:

1.- Permiten búsquedas que devuelven más datos de los que tienen sentido que se proporcionen a un usuario: Hasta los buscadores como Google o Bing ponen límites de resultados ofreciendo como mucho 1.000 por cada consulta - lo que nos obligó por ejemplo en FOCA a tener un tratamiento especial en los huge domains - . Una sitio web que permite consultas de búsqueda que devuelvan 444.000 resultados está cargando innecesariamente de trabajo al sitio web porque ningún usuario va a revisar todos esos resultados.

Figura 4: Buscador de web devulve 444.882 resultados en cada búsqueda

2.- Permiten lanzar consultas de grandes resultados con una única petición: Muchos sitios web permiten que la consulta se haga con una simple petición GET, lo que facilita sobre manera cualquier automatismo, e incluso el uso de los buscadores como arma de destrucción masiva, utilizando sistemas de amplificación de peticiones como los que mostramos allí. 

3.- No limitan el número de consultas por dirección IP y tiempo: Lo que ayuda a que el ataque sea sostenible el tiempo suficiente como para cargar el sitio web. 

Al final, las pruebas de DOS son más que necesarias en cualquier auditoría de seguridad, así que no debes dejarlas fuera de ellas, porque si no el sistema se puede caer en el momento menos deseado e incluso, alguna vez, por torpeza de los mismos usuarios.

Saludos Malignos!