Ataques de denegación de servicio usando servidores NTP

El pasado diciembre tuvieron lugar diversos ataques distribuidos de 

denegación de servicio sobre redes de servidores de juegos. Entre ellas,
Steam, Origin o Battle.com. Al parecer los ataques fueron atribuidos al
grupo DERP Trolling. Al margen de las causas políticas lo interesante es
qué usaron para generar el tráfico que provocó el corte o degradación
temporal del servicio.

Como sabemos, hay diversos tipos o técnicas de denegación de servicio.
Desde un simple paquete modificado para generar un desbordamiento en la
pila y desestabilizar el proceso, hasta la generación de un gran volumen
de tráfico desde múltiples direcciones que termine por agotar los
recursos de los servidores atacados. El ataque ha empleado una técnica
de generación de tráfico conocida pero sobre un actor diferente.

Desde hace tiempo uno de los ataques de denegación de servicio más
interesantes es la amplificación de respuestas DNS. Esta técnica
aprovecha varios factores para generar un tráfico no solicitado de una
manera “lícita”, es decir, no se aprovecha de la infección de máquinas
sino de la falta o descuido de configuración de los servidores DNS de
terceros.

Basta hacer un escaneo aleatorio sobre el puerto 53 para detectar
servidores DNS y una pequeña prueba para determinar que esos servidores
DNS responden o generan una consulta recursiva sobre dominios de
terceros. Una consulta sobre un dominio puede generar una respuesta
hasta 50 veces mayor que la petición. Es decir, inviertes 10 bytes en
una petición y el servidor podría devolverte hasta 500 bytes. Ya tienes
la generación de tráfico.

El protocolo DNS funciona sobre el protocolo de transporte UDP que como
sabemos no está orientado a conexión y por lo tanto prescinde de lo que
se denomina “handshake”. Es decir, no necesita confirmación del otro
extremo para iniciar una conversación con más detalles. Con UDP pides y
te sirven. Esto es importante ya si construimos una petición UDP pero
cambiamos el campo origen a otra IP que no sea la nuestra el servidor
responderá a esa otra IP.

Ya tenemos dos factores. Podemos generar tráfico gracias al ratio 1:50
petición/respuesta y también podemos falsear la dirección de origen
gracias a UDP. El siguiente factor es encontrar servidores DNS abiertos
o que permitan consultas recursivas sobre dominios de terceros. Con un
buen grupo de estos servidores y otro grupo que genere las peticiones se
tiene la tormenta perfecta para dirigir ese tráfico al objetivo.

¿Qué ha cambiado en este ataque?

Que no se han usado servidores DNS para amplificar las respuestas. En
vez de ello los atacantes han usado servidores NTP (Network Time
Protocol).

NTP es un protocolo usado principalmente para sincronizar los relojes
del sistema operativo. Podemos leer sobre el en las siguientes RFC:
http://www.ntp.org/rfc.html.

Los servidores NTP escuchan en el puerto 123 UDP y por cada petición,
por ejemplo, de 8 bytes pueden llegar a generar una respuesta hasta casi
60 veces mayor. Pero esta respuesta no es la habitual de un servidor NTP
sino que es una característica del protocolo que ahora ha sido parcheada
para evitar este tipo de ataques. Curiosamente en la lista de desarrollo
de NTP la debilidad ya aparecía en 2010. Por cierto, incluso tiene un
CVE asociado, el CVE-2013-5211 y está corregida en la versión 4.2.7 del
servidor NTP.

http://bugs.ntp.org/show_bug.cgi?id=1532

Es posible efectuar una petición al servidor NTP para obtener una lista
con información de peticiones a modo de registro, una lista denominada
Monitor data. Incluso existe un script para nmap que encuentra
servidores NTP con esta característica
(http://nmap.org/nsedoc/scripts/ntp-monlist.html). Gracias a esto es
posible amplificar la respuesta.

Aunque no es habitual, es posible encontrar organizaciones que usen
servidores NTP sobre Internet para sincronizar redes en diferentes
localizaciones. Si no es el caso sería recomendable filtrar el tráfico
entrante del puerto 123 UDP y por supuesto si se usan servidores NTP
actualizar a la versión corregida.

Sobre los servidores DNS abiertos la verdad merece una entrega aparte.
Es una constante en nuestras auditorías de seguridad, encontrar un DNS
(¡o varios!) de la organización publicado hacia Internet y que permite a
terceros su uso sobre cualquier dominio de manera recursiva. Incluso es
complicado hacer entender al administrador como eso puede ser usado en
contra de la organización para la que trabaja.

Hemos de entender que cuando una víctima recibe tráfico DNS el paquete
UDP lleva como origen la IP de nuestra organización, por lo que podemos
vernos en la tesitura de tener que responder ante un escenario donde
nuestro servidor DNS ha sido usado para un ataque DDoS.
 Fuente