Inicio / Blog / Ataques de denegación de servicio vía NTP

Ataques de denegación de servicio vía NTP

Publicado el 19/02/2014, por Antonio López (INCIBE)
NTP

Desde finales del pasado año y comienzos de este nuevo 2014, han tenido lugar importantes ataques de denegación de servicio como los dirigidos contra las plataformas de juegos online “League of Legends” y “battle.net” , o el más reciente sucedido este mes de febrero contra la compañía francesa de hosting OVH que sufrió un ataque que superó los 350 Gbps. Estos ataques tienen su base en el protocolo NTP (Network Time Protocol), un protocolo de internet utilizado para la sincronización de tiempo. El pasado 13 de enero, el US-CERT del centro de seguridad nacional de Estados Unidos publicó una alerta sobre esta problemática.

Curiosamente y tal como describimos en el artículo ”DNS, open resolvers y denegación de servicio por amplificación DNS “, encontramos factores similares que brindan la oportunidad de construir potentes ataques . Una vez más, un protocolo basado en UDP, malas prácticas en configuraciones de servidor y, en este caso una funcionalidad del propio servicio NTP, proporcionan las bases del ataque. De forma análoga, partiendo de consultas de unos pocos bytes que se envían a multitud de servidores NTP, se generan respuestas de tamaño mucho mayor que la consulta (amplificación) y dirigidas contra un objetivo víctima (reflexión).Esta técnica, similar a la mencionada para DNS, es conocida como ataque de denegación de servicio por amplificación NTP.

Funcionamiento del ataque

En una comunicación basada en protocolo UDP y por motivos de rendimiento, los datos se envían y se reciben sin verificar la conexión con el origen o destino de la misma y se da por hecho la correcta entrega o recepción de datos. Gracias a esta carencia de verificación es posible modificar direcciones IP en un flujo de tráfico y mantener su validez. Esto da pie a una práctica conocida como “IP spoofing”, cuyo objetivo es suplantar el emisor de una comunicación. La técnica, aplicada en este caso concreto al protocolo NTP consta de los siguientes pasos:

  1. Falsificación de IP (IP spoofing). El atacante construye consultas NTP y antes de su envío, sustituye la IP de origen de los datagramas con la IP del objetivo. Así se consigue que todas las respuestas se dirijan a la víctima en lugar de regresar al propio origen atacante (Reflexión)

  2. Consulta NTP de monitorización a servidores vulnerables. Escogiendo una consulta específica para labores de monitorización del servidor, se provoca una respuesta de los servidores NTP de tamaño mucho mayor que la consulta en sí (Amplificación). Estas consultas, con la IP de origen manipulada para suplantar la IP del objetivo y dirigida al mayor número de servidores NTP posible conseguirá “reflejar” un gran volumen de tráfico hacia la víctima.

DoS por amplificación y reflexión respuestas NTP

DoS por amplificación y reflexión respuestas NTP

Vulnerabilidad

Además de la debilidad intrínseca de UDP, que posibilita el efecto de reflexión falsificando la IP origen del paquete, existe una funcionalidad de monitorización de NTP que proporciona el efecto de amplificación de la respuesta. Esta funcionalidad está presente en servidores NTP con versión anterior a 4.2.7p26. Así, al hacer una consulta a un servidor no actualizado con el comando de monitorización monlist se consigue que éste responda con la lista de las últimas máquinas con que las cuales ha interaccionado (hasta 600). Obviamente, esta respuesta puede ser bastante grande en relación a la propia consulta. Esta funcionalidad se ha considerado como una vulnerabilidad del protocolo y se le asocia el CVE-2013-5211.

Prueba de concepto

  1. Usando el script de nmap ntp-monlist, buscamos servidores vulnerables en un determinado segmento de red (Ilustración 1).
     

    Escaneo de un segmento de red con plugin nmap buscando servidores NTP vulnerables

    Ilustración 1. Escaneo de un segmento de red con plugin nmap buscando servidores NTP vulnerables

  2. Verificamos la versión del servidor detectado y comprobamos que contesta al comando (Ilustración 2)
     

    Se verifica la vulnerabilidad del servidor encontrado

    Ilustración 2. Se verifica la vulnerabilidad del servidor encontrado

  3. Usando wireshark, capturamos la conversación (Ilustración 3)donde se observa que se obtiene una repuesta con tamaño de más de 180 veces el tamaño de la consulta (Ilustración 4)
     

    Captura de la petición monlist. Consulta 234 bytes

    Ilustración 3. Captura de la petición monlist. Consulta 234 bytes

    Respuesta del servidor 44192 bytes. Tamaño 188 veces mayor que la consulta

    Ilustración 4. Respuesta del servidor 44192 bytes. Tamaño 188 veces mayor que la consulta

Contramedidas

Afortunadamente, existen soluciones para solventar este problema:

Actualización:

Actualizar la versión del servidor NTP a 4.2.7p26 o superior, lo que resuelve el problema al quedar inhabilitado el comando monlist.

Si la actualización no es posible:

Verificar si las respuestas a monlist están habilitadas:

ntpq -c rv
ntpdc -c sysinfo
ntpdc -n -c monlist
 

 

Si la respuesta es positiva, el servidor es vulnerable y  por su configuración es susceptible de amplificar respuestas. Para corregir el problema pueden seguirse las siguientes recomendaciones:

Desactivar las consultas de monitorización, o restringir su acceso, en la configuración ntp.conf:

  • Desactivar monitor:
    disable monitor

     

  • Como alternativa, si se pretende mantener la monitorización,  puede restringirse su uso a redes internas:
    restrict default noquery
    restrict localhost
    restrict 192.168.0.0 netmask 255.255.0.0
    restrict 192.168.1.27

Adicionalmente, pueden aplicarse las medidas especificadas en el documento de la IETF BCP38 “Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing

Conclusiones

De forma análoga al caso DNS, NTP un protocolo que se trasmite sobre UDP, se convierte en  una herramienta que posibilita crear ataques de denegación de servicio de forma relativamente sencilla, con poco esfuerzo y recursos. La potencia de esta modalidad de ataque se ve de nuevo favorecida en la mala praxis aplicada en  gran cantidad de servidores NTP accesibles, desactualizados o mal configurados.

Distribución mundial de servidores NTP con amplificación. Fuente: NSFOCUS

Ilustración 5. Distribución mundial de servidores NTP con amplificación. Fuente: NSFOCUS

Siguiendo la línea de la propuesta que nació para concienciar sobre el problema en el caso DNS, se ha creado la iniciativa openntpproject donde se puede comprobar si un servidor es vulnerable, o si en un determinado segmento de red se hallan servidores NTP igualmente vulnerables. Un buen momento para que administradores de sistemas o responsables de servicios NTP revisen la configuración de sus servidores, y evitar en la medida que les corresponde convertirse en "cómplices involuntarios" de ataques DoS