Protocolos Olvidados: NTP (Network Time Protocol)

Existen algunos protocolos olvidados en nuestras redes y sistemas. Son complicados de trabajar debido a la falta de conciencia que se tiene sobre los mismos y quizás son una piedra fundamental para la construcción de los servicios que se brindan.

En algunos casos confiamos en que son seguros o también pensamos que el foco de los atacantes va a estar siempre situado en las conocidas joyas de la corona, pero nunca nos detenemos en ese instante de decisión para determinar si tendrían que ser incluidos o no debido a su criticidad dentro de estas categorías. Quizás pasan desapercibidos porque confiamos en que son seguros, pero confianza no es lo mismo que conciencia.

Ser consciente de todos los servicios que nuestros equipos manejan es una tarea titánica, pero en algún momento deberíamos comenzar a explorarlos con mayor profundidad.

¿Por qué es tan importante el tiempo?

Imaginen esto: Necesitan tomar un autobús a una hora específica; caminan hasta la parada del autobús y lo esperan. Miran su reloj y ven que es la hora, pero el autobús aún no llega. En ese momento es el turno de buscar otra fuente de tiempo, como el teléfono, para tener una segunda opinión sobre la hora, en ese instante se descubre que la hora es incorrecta. Si tiene una cita o un compromiso importante, usted no estaría llegando a tiempo.

Ahora cuando se habla de sistemas y aplicaciones que requieren de otras aplicaciones para funcionar, se necesita una configuración de hora correcta.

Sin este sincronismo los procesos automáticos y los procesos que transcurren en tiempo real no funcionarán correctamente. Existen muchas entidades por lo general las entidades financieras, que trabajan con tareas en tiempo real, ya que cuando se trata de dinero la cosa se torna un poco más compleja de lo habitual; Por ejemplo: Si estuvieras trabajando para un banco, hay procesos que deben ejecutarse en un momento específico al final del día debido a que las entidades suelen comunicarse con otras entidades bancarias alrededor del mundo para actualizar cierto tipo de información. Si la ejecución automática no se realiza a tiempo, podría crear problemas legales con otras entidades bancarias y perder la confianza. En un banco, la confianza es lo más importante que se necesita.

¿Por qué el vector de ataque es el sincronismo?

Recordando un poco los principios de la seguridad, un atacante suele tener como objetivo los cuatro pilares que construyen nuestra necesidad de sentirnos seguros, CONFIDENCIALIDAD, DISPONIBILIDAD, INTEGRIDAD y TRAZABILIDAD. Allí destacamos puntos importantes en donde la hora es protagonista, ya que tenemos varios aspectos que son de interés para los atacantes y no tan así para la gente que tiene el objetivo de proteger los recursos de una compañía. El foco común de los analistas suele residir en la preocupación por mantener la CONFIDENCIALIDAD , entonces los profesionales enumeran sus Joyas de la Corona más preferidas, enfocándose en esa propiedad puntual, dejando a fuera temas importantes que pueden llegar a perjudicarnos en el corto plazo.

CONFIDENCIALIDAD


DISPONIBILIDAD, INTEGRIDAD y TRAZABILIDAD

Dentro de la ausencia de atención hacia la TRAZABILIDAD y la DISPONIBILIDAD por parte de los responsables de la seguridad podrían ocurrir determinadas ideas para tratar de entorpecer los funcionamientos con el fin de generar trabas a los procesos de una compañía exitosa. Es por eso que al atacar el sincronismo se pueden obtener beneficios claves a nivel atacante, tanto para cubrir sus huellas como para generar una maniobra de distracción dentro de las instalaciones potencialmente afectadas.

El protocolo que se encarga de esto en los sistemas de una empresa, es el protocolo NTP (Network Time Protocol), el mismo se utiliza para realizar una sincronización de los relojes en los distintos dispositivos interconectados en el ámbito de configuración de este servicio. Trabaja con UDP por el puerto 123 y es ampliamente utilizado en redes a escala mundial, tanto internas como públicas. Su importancia reside, como ya comentamos en los párrafos anteriores, en que la falta de sincronización horaria, por un tiempo prolongado en un sistema, afecta a la consistencia e integridad de la información, lo que conlleva graves repercusiones en ámbitos como es el financiero, productivo, legal y un largo etcétera.

En el gráfico anterior podemos observar como funciona el protocolo, tenemos una referencia externa satelital de sincronización, luego en la siguiente instancia hay servidores primarios que toman esta sincronización, para luego trasladarla a servidores secundarios de referencia que serán consumidos entre los potenciales clientes de esta información logrando así en última instancia, compartir esas referencias entre sí.
Dentro de las vulnerabilidades que podemos llegar a encontrar en este tipo de protocolos que trae consigo mucho intercambio, encontramos varios puntos de falla respecto de los mismos, como por ejemplo los siguientes;

• Las debilidades o fallas propias del protocolo
⦁ Deficiencias a la hora de construir el protocolo provoca que algunas funciones pensadas para un tipo de gestión terminan siendo perjudiciales para el propósito del protocolo en sí.

• Las interacciones del protocolo con otros sistemas y/o protocolos
⦁ Lograr cortar las interacciones para que las conexiones pierdan cierto tipo de sincronismo.

• La cronología ante una auditoria
⦁ Toda evidencia digital se basa en gran parte en los timestamp, sin los timestamp no se pueden combinar entre las evidencias, estamos ante un problema grave que quizás no tiene forma de resolverse, debido a que la evidencia ocurre en un intervalo de tiempo dado y no se puede regenerar. Ejemplo: Si alguien realiza tareas, que luego son evidencia digital, con un tiempo manipulado, el tiempo que va a prevalecer es ese. No vamos a poder reconstruir el tiempo real de la acción nunca.

• La integridad de la información
⦁ Permitirle a un atacante mentir sobre la hora en la cual estoy realizando una transacción para realizar un bypass en los mecanismos de protección de las aplicaciones. Ejemplo; Una aplicación que se base en la hora exacta para determinar la validez de una licencia o forzar la expiración de un certificado local.

¿Cuáles son los ataques más conocidos?

Dentro de los ataques más conocidos que encontramos haciendo referencia a los potenciales puntos de falla mencionados anteriormente, nos encontramos con algunas técnicas conocidas que podrían llegar a servirle a un atacante para generar esos síntomas sobre el uso de los servidores NTP.

⦁ NTP Amplification Attack

Principalmente, están asociados a vulnerabilidades que se corresponden con el punto 1 del párrafo anterior, en donde hacíamos referencia a fallas propias del protocolo.

Estas vulnerabilidades están relacionadas con ciertos comandos utilizados para la gestión del protocolo y la supervisión del mismo. Estamos hablando de dos comandos particulares que están destinados a realizar las siguientes funciones:

Moonlist : Devuelve una lista con los últimos 600 dispositivos que se hayan comunicado con el servidor. Se realiza una pequeña petición al servidor y se recibe una respuesta que puede alcanzar un tamaño 200 veces mayor a la consulta realizada.

Readvar: Un comando que al ejecutarlo devuelve variables, con su contenido , provocando una respuesta superior a la consulta realizada. En este caso 30 veces superior a la consulta originaria.

Los atacantes realizan estas peticiones en gran cantidad, falsificando la dirección de origen para que simulen ser el servidor que se quiere inutilizar. Dando como resultado la situación en la que el equipo víctima, sin solicitarlo, recibe respuestas NTP con una amplificación de 30 veces y/o 200 veces dependiendo de la función utilizada, provocando una inundación de respuestas NTP. Afectando así a la disponibilidad de los servicios que requieran conectividad a través de él.


Imagen extraída de https://www.cloudflare.com/es-es/learning/ddos/ntp-amplification-ddos-attack/

⦁ NTP Spoofing (A través de ARP y/o DNS)

Si bien no es una vulnerabilidad propia del servicio NTP, podríamos lograr con un clásico ataque man in the middle apuntando hacia nuestros servidores NTP. En este caso una combinación de técnicas puede permitirnos enviar una hora distinta hacia los equipos que están solicitando la hora al servidor NTP principal. Dentro de las maneras de catalogar una vulnerabilidad podría también ser catalogado como un mal uso o un abuso del protocolo en cuestión.

En este caso se podría hacer un ARP Spoofing, interceptar las tramas NTP y mal formarlo con un tiempo de sincronización incorrecto con el fin de alterar los Timestamp.

Así como la mayoría de los ataques se centran en protocolos más interesantes, no existen tantos métodos automatizados para realizar esto, se podría si hacer un script que realice los siguientes pasos;

• Realizar un ARP-Cache-Poisoning


• Posicionar la máquina nuestra entre el target y la puerta de enlace


• Escuchar las respuestas de NTP que envía la puerta de enlace hacia el target.
• Modificar los Timestamps y re-enviarlos.

Una utilidad muy importante para realizar esto es la librería Scapy de Python para manipulación de paquetes. Aunque antes de programarlo siempre es conveniente realizar alguna búsqueda en google para encontrar soluciones ya trabajadas por algún amable researcher como en el siguiente ejemplo;

https://github.com/crazyarashi/ntp-spoof/blob/master/ntpspoof.py

Ahora si queremos ejecutar la misma tarea con DNS poisoning, simplemente deberemos indicarle a través de nuestro DNS malicioso que el servidor NTP es un servidor manipulado por el atacante, en donde el mismo proveerá un tiempo incorrecto para la sincronización de la hora.

¿Cómo nos defendemos?

Si bien en el caso de las fallas de los protocolos podemos eliminar las funcionalidades inseguras a fines de realizar un respectivo Hardening del protocolo, la detección y el monitoreo debería ser una parte fundamental de toda instancia de remediación. Ya el simple hecho de tomar conciencia de la existencia del protocolo logrará que se comiencen a crear alertas acordes a un mal funcionamiento de nuestro servidor NTP.

En el caso de los ataques de amplificación;

• Desactivar el comando monlist y/o reader; todas las versiones del software NTP anteriores a la versión 4.2.7 son vulnerables por defecto. La actualización de un servidor NTP a la versión 4.2.7 o superior deshabilita el comando, lo que repara la vulnerabilidad. Si no es posible esta actualización, el administrador de un servidor podrá realizar los cambios necesarios siguiendo las instrucciones del US-CERT.


• Verificar la IP de origen; Solicitarle al proveedor ISP que implementen un filtrado de ingreso en donde se chequeen los paquetes se envían desde dentro de la red con una dirección de origen que hace parecer que se originó por fuera de la red o en su defecto implementar este filtrado en nuestro firewall de borde.


• Desplegar los servidores NTP detrás de los firewalls; Detectar y filtrar peticiones dirigidas por UDP al puerto del servidor NTP y disponer de una configuración anti spoofing. Esto último deberán consultar las especificaciones de sus firewalls en la página del fabricante correspondiente.


• Limitar la visibilidad del servidor NTP en internet; Referido a minimizar la exposición de nuestros servidores NTP hacia internet.


• Definir o escribir un protocolo de acción ante una denegación de servicio por NTP; Como actuar, que hacer, cuál es nuestra contingencia ante estos casos, son cuestiones que deberían estar establecidas para poder ejecutar una solución instantánea en el caso de que el tiempo sea comprometido en nuestras redes. Seguir un protocolo es indispensable, ya que podemos definir reglas de actuación para el equipo de gestión de incidentes.

En el caso de los ataques de spoofing;

• Tener nuestras medidas de seguridad a nivel LAN siempre activas ayuda a que podamos monitorear entre otras cosas tráfico malicioso que se envíe entre los dispositivos de nuestra RED, si bien bloquear ataques desde afuera hacia nuestra arquitectura suele ser tarea sencilla, si contamos con las correctas medidas preventivas en el límite de nuestra red, no debemos dejar de perder el foco de que nuestra red interna tiene que ser lo suficientemente robusta para poder detectar y prevenir estas anomalías potenciales asociadas a protocolos que suelen estar desatendidos.
• Generar Alertas analizando nuestra RED con DATAFLOW, como se muestra en nuestro post en donde se detallan como utilizar flujos de datos para monitorear.
• Segmentar la red correctamente para poder contener los ataques fuera de nuestras joyas de la corona (Servidores productivos, aplicaciones críticas, estaciones de trabajo con accesos críticos, etc.).

Conclusión

En base a todos los temas conversamos es casi indispensable conocer todos los protocolos esenciales para el funcionamiento de nuestros sistemas. Muchas veces se nos van a escapar cuestiones mínimas que tarde o temprano nos traen un dolor de cabeza enorme a la hora de querer arreglar un inconveniente en tiempo real. No solo son importantes las medidas a tomar sino también la planificación previa y el ensayo sobre cuestiones raras que pueden llegar a ser poco frecuentes para la percepción propia, pero no así para el punto de vista del atacante que se encuentra mutando y al acecho de forma constante. No dejemos que los atacantes nos agarren desprevenidos.

“Por lo general, quien llegue antes al terreno de batalla y espere al enemigo estará reposado; quien llegue más tarde y de inmediato entable combate estará extenuado”.

Sun Tzu - El Arte de la Guerra