Figura 1: Vídeo de anuncio de servicios DDOS profesionales
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 2: 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.
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 por que:
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.
