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.
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.
David García
