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.

David García
dgarcia@hispasec.com
Twitter: @dgn1729

http://unaaldia.hispasec.com/2014/01/ataques-de-denegacion-de-servicio.html