Presentación de time.cloudflare.com

Cloudflare siempre ha sido líder en la implementación de versiones seguras de protocolos de internet inseguros y los pone a disposición de manera gratuita para cualquier usuario. En 2014, lanzamos uno de los primeros servicios HTTPS seguros y gratuitos del mundo (Universal SSL) para continuar con nuestro plan existente HTTP gratuito. Cuando lanzamos la resolución DNS 1.1.1.1 DNS, también admitimos las nuevas versiones seguras de DNS (DNS a través de HTTPS y DNS a través de TLS). Hoy, como parte de la Criptosemana 2019, estamos haciendo lo mismo para el protocolo de tiempo de redes (NTP), el protocolo dominante para obtener la hora a través de internet.

Este anuncio es personal para mí. He pasado los últimos cuatro años tratando de identificar y solucionar vulnerabilidades en los protocolos de tiempo. Hoy estoy orgulloso de colaborar con la presentación de un servicio que habría hecho que mi vida fuera mucho más difícil desde 2015 hasta 2019: time.cloudflare.com, un servicio de tiempo libre que admite tanto NTP como el protocolo emergente de seguridad horaria en la red (NTS) para proteger NTP. Ahora, cualquiera puede obtener la hora de forma segura desde todos nuestros centros de datos en 180 ciudades de todo el mundo.

Hoy puede utilizar time.cloudflare.com como fuente horaria para todos sus dispositivos con NTP, mientras que los clientes de NTS aún se encuentran en una etapa de desarrollo. NTPsec incluye soporte experimental para NTS. Si desea obtener actualizaciones sobre el estado de desarrollo de clientes NTS, envíenos un correo electrónico con la solicitud para unirse a [email protected]. Para usar NTS para proteger la sincronización de la hora, póngase en contacto con sus proveedores y obtenga información sobre la compatibilidad con NTS.

En 2015, cuando recién me había graduado y estaba interesada en la seguridad de internet, encontré este protocolo de internet, en gran parte esotérico, que se llama Protocolo de tiempo de redes (NTP). El NTP se diseñó para sincronizar la hora entre los sistemas informáticos que se comunican a través de rutas de red poco fiables y de latencia variable. En realidad, estaba estudiando la seguridad del enrutamiento de internet, en particular los ataques contra la infraestructura de clave pública de recursos (RPKI), y me enfrentaba a un callejón sin salida debido a un problema de invalidación de la memoria caché. Como último intento desesperado, decidí retroceder de forma manual la hora de mi computadora, y el ataque funcionó.

Había descubierto la importancia de la hora para la seguridad informática. La mayor parte de la criptografía utiliza marcas de tiempo para limitar los períodos de validez del certificado y de la firma. Al conectarse a un sitio web, el conocimiento de la hora correcta garantiza que el certificado que se ve es actual y que no está comprometido por un atacante. Al examinar los registros, la sincronización de la hora garantiza que los eventos en diferentes equipos se puedan correlacionar con precisión. Los certificados y la infraestructura de registro pueden vulnerarse con una diferencia de tiempo de minutos, horas o meses. Otras aplicaciones como el almacenamiento en caché y Bitcoin son sensibles incluso a diferencias muy pequeñas de tiempo en el orden de los segundos.

La autenticación de dos factores mediante números consecutivos también se hace en función de relojes precisos. Esto genera la necesidad de que los relojes de las computadoras tengan acceso a una hora razonablemente precisa que se ofrece de forma segura. NTP es el protocolo que más se utiliza para la sincronización del tiempo en internet. Si un atacante puede aprovechar las vulnerabilidades en el NTP para manipular la hora en los relojes de los equipos, puede socavar las garantías de seguridad proporcionadas por estos sistemas.

Motivado por la gravedad del problema, decidí profundizar en el tema del NTP y su seguridad. Como la necesidad de sincronizar la hora a través de las redes era un problema visible desde un principio, el NTP es un protocolo muy viejo. La primera versión estandarizada del NTP es de 1985, mientras que la última versión 4 del NTP se finalizó en 2010 (consultar RFC5905).

En su modalidad más común, el NTP permite que un cliente envíe un paquete de consulta a un servidor NTP que después responde con su hora de reloj. El cliente entonces hace un cálculo de la diferencia entre su reloj y el reloj remoto, e intenta compensar la demora de la red con esto. El cliente del NTP consulta múltiples servidores e implementa los algoritmos para seleccionar la mejor estimación, y rechaza las respuestas que son claramente incorrectas.

Sorprendentemente, la investigación sobre el NTP y su seguridad no era muy activa en ese momento. Antes de esto, a fines de 2013 y principios de 2014, los ataques de denegación de servicio distribuido (DDoS) de alto perfil se llevaron a cabo amplificando el tráfico desde los servidores NTP. Los atacantes capaces de redireccionar la dirección IP de una víctima canalizaron grandes cantidades de tráfico que sobrecargaron a los dominios objetivo. Esto llamó la atención de algunos investigadores. Sin embargo, estos ataques no sacaron provecho de los defectos en el diseño del protocolo clave. Los atacantes simplemente utilizaron el NTP como un multiplicador de ancho de banda lento. Cloudflare escribió bastantes publicaciones sobre estos ataques, y puede leer sobre el tema aquí, aquí y aquí.

Encontré varios defectos en el diseño del protocolo NTP básico y en la implementación. Los atacantes de red pueden aprovechar estos defectos para lanzar ataques mucho más devastadores al cambiar la hora o negar el servicio a los clientes NTP. Lo que es aún más preocupante es que estos atacantes no necesitan ser un intermediario (MITM), donde un atacante puede modificar el tráfico entre el cliente y el servidor, para organizar estos ataques. Una serie de documentos recientes escritos por uno de nosotros mostró que un atacante fuera de ruta que se encuentre en cualquier lugar de la red puede cambiar la hora o denegar el servicio a los clientes NTP. Una de las maneras de hacer esto es mediante el exceso de fragmentación del IP.

La fragmentación es una característica de la capa IP donde un paquete grande se divide en varios fragmentos más pequeños de modo que puedan pasar a través de las redes que no admiten los paquetes grandes. Básicamente, cualquier elemento de red aleatorio en la ruta entre el cliente y el servidor puede enviar un paquete especial con la “fragmentación ICMP necesaria” al servidor solicitando la fragmentación del paquete en X bytes. Como se supone que el servidor no conoce las direcciones IP de todos los elementos de red en su ruta, este paquete se puede enviar desde cualquier IP de origen.

Ataque de fragmentación contra NTP

En nuestro ataque, el atacante aprovecha esta característica para hacer que el servidor NTP fragmente su paquete de respuesta NTP para el cliente NTP de la víctima. Luego, el atacante falsifica fragmentos de respuesta superpuestos, cuidadosamente diseñados, desde fuera de la ruta que contienen los valores de marca de tiempo del atacante. Al aprovechar aún más las políticas de reensamblaje para fragmentos superpuestos, el atacante engaña al cliente para que ensamble un paquete con fragmentos legítimos y las inserciones del atacante. Esto evade las comprobaciones de autenticidad que se basan en los valores de las partes originales del paquete.

Cuando se creó el NTP en 1985, había dos objetivos de diseño principales para el servicio proporcionado por el NTP. En primer lugar, querían que fuera lo suficientemente sólido como para poder manejar los errores de red y las fallas en los equipos. Entonces se diseñó como un servicio donde el cliente puede recopilar muestras de sincronización de varios pares a través de múltiples rutas de comunicación y luego promediarlas para lograr una medición más precisa.

El segundo objetivo era la distribución de la carga. Si bien a cada cliente le gustaría comunicarse con servidores de tiempo que están conectados directamente a dispositivos de cronometraje de alta precisión como relojes atómicos, GPS, etc, y así contar con una hora más precisa, la capacidad de esos dispositivos es limitada. Por lo tanto, para reducir la carga de protocolo en la red, el servicio se diseñó de manera jerárquica. En la parte superior de la jerarquía hay servidores conectados a proveedores de hora que no son NTP, que distribuyen la hora a otros servidores, que a su vez distribuyen la hora a más servidores. La mayoría de los equipos se conectan a estos servidores de segundo o tercer nivel.

Jerarquía de estratos de NTP

La especificación original (RFC 958) también indica los “no objetivos” del protocolo, a saber, la autenticación del mismo nivel y la integridad de los datos. La seguridad no se consideraba un problema crítico en la internet relativamente pequeña y confiable de los primeros tiempos, y los protocolos y las aplicaciones que dependen de la hora para la seguridad no existían en ese entonces. La seguridad en el NTP fue un objetivo que sobrevino en segundo lugar para mejorar el protocolo y la implementación.

Con el crecimiento de internet, cada vez más protocolos básicos de Internet se han asegurado a través de la criptografía para protegerse contra el abuso: TLS, DNSSEC, RPKI son pasos para garantizar la seguridad de todas las comunicaciones en internet. Estos protocolos utilizan la “hora” para brindar garantías de seguridad. Como la seguridad de internet depende de la seguridad del NTP, es aún más importante asegurar el NTP.

Esta investigación mostró claramente la necesidad de asegurar el NTP. Como consecuencia, hubo más trabajo en el ente normativo de los protocolos de internet, el Grupo de Trabajo de Ingeniería de Internet (IETF), en referencia a la autenticación criptográfica del NTP. En ese momento, si bien NTPv4 admitía la autenticación criptográfica simétrica y asimétrica, rara vez se utilizaba en la práctica debido a las limitaciones de ambos métodos.

El método simétrico de NTPv4 para proteger la sincronización carece de escalabilidad, ya que la clave simétrica debe compartirse previamente y configurarse en forma manual: imagine si cada cliente del mundo necesitara una clave secreta especial de los servidores de los que desea obtener la hora, las organizaciones que administran esos servidores tendría que hacer una tarea enorme para gestionar las claves. Esto hace que la solución sea bastante engorrosa para los servidores públicos que deben aceptar consultas de clientes arbitrarios. Para contextualizar, NIST opera importantes servidores públicos de horario y distribuye claves simétricas solo a los usuarios que se registran, una vez al año, a través del correo de los Estados Unidos o fax. La Oficina Naval de los Estados Unidos hace algo similar.

El primer intento para resolver el problema de la distribución de claves fue el protocolo Autokey, que se describe en RFC 5906. Muchos servidores NTP públicos no admiten Autokey (por ejemplo, los servidores de horario NIST y USNO, y muchos servidores en pool.ntp.org). El protocolo es ineficaz, ya que cualquier atacante de la red puede obtener fácilmente la clave secreta compartida entre el cliente y el servidor. Los mecanismos de autenticación no son estándar y son bastante idiosincrásicos.

El futuro de internet es una internet segura, lo que significa una internet autenticada y cifrada. Pero hasta ahora, a pesar de su continuo desarrollo, el NTP sigue siendo bastante inseguro. Mientras tanto, cada vez más servicios dependen de este.

Cronología del desarrollo del NTP

Tras la publicación de nuestro documento, creció mucho el entusiasmo por la comunidad NTP en el ente normativo de los protocolos de internet, en el Grupo de Trabajo de Ingeniería de Internet (IETF) y fuera de ellos para mejorar la seguridad del NTP. Como solución a corto plazo, desarrollamos parches para solucionar varias vulnerabilidades que encontramos en el software de implementación de referencia ntpd. Y como solución a largo plazo, la comunidad se dio cuenta de la urgente necesidad de un protocolo de sincronización de horario seguro y autenticado en base a la criptografía de clave pública, lo que permite el cifrado y la autenticación sin necesidad de compartir material clave de antemano. Hoy tenemos un proyecto de Seguridad horaria en la red (NTS) en el IETF, gracias al trabajo de decenas de personas especializadas en el grupo de trabajo del NTP.

En resumen, el protocolo NTS se divide en dos fases. La primera fase es el intercambio de claves NTS que establece el material clave necesario entre el cliente NTP y el servidor. Esta fase utiliza el protocolo de enlace de la seguridad de la capa de transporte (TLS) y se basa en la misma infraestructura de clave pública que la web. Una vez que se intercambian las claves, el canal TLS se cierra y el protocolo ingresa en la segunda fase. En esta fase los resultados de ese protocolo de enlace TLS se utilizan para autenticar los paquetes de sincronización horaria del NTP a través de los campos de extensión. El lector interesado puede encontrar más información en el proyecto de internet.

Hoy, Cloudflare anuncia su servicio de tiempo gratuito disponible para todo el mundo en internet. Tratamos de resolver las limitaciones con los servicios de horario público actuales, en particular mediante el aumento de la disponibilidad, la solidez y la seguridad.

Utilizamos nuestra red global para ofrecer una ventaja en cuanto a latencia y precisión. Nuestras 180 ubicaciones en todo el mundo utilizan anycast para enrutar automáticamente sus paquetes a nuestro servidor más cercano. Todos nuestros servidores se sincronizan con los proveedores de servicios de hora del estrato 1, y luego ofrecen NTP al público en general, funcionan de manera similar a otros proveedores públicos NTP. La mayor fuente de imprecisión para los protocolos de sincronización horaria es la asimetría de la red, lo que genera una diferencia en los tiempos de viaje entre el cliente y el servidor, y de vuelta desde el servidor al cliente. Sin embargo, la proximidad de nuestros servidores con los usuarios significa que habrá menos inestabilidad, una medida de la variación de la latencia en la red, y una posible asimetría en las rutas de los paquetes. También esperamos que en regiones con escasez de servidores NTP nuestro servicio mejore significativamente la capacidad y la calidad del ecosistema NTP.

Los servidores de Cloudflare obtienen tiempo autenticado mediante el uso de una clave simétrica compartida con nuestros servidores que preceden la cadena del estrato 1. Estos servidores que preceden la cadena están distribuidos geográficamente y garantizan que nuestros servidores tengan un horario preciso en nuestros centros de datos. Pero este método para garantizar el horario no es escalable. Tuvimos que intercambiar correos electrónicos de manera individual con las organizaciones que administran los servidores de estrato 1 y negociar el permiso para usarlos. Si bien esta es una solución para nosotros, no es una solución para todos en internet.

Como proveedor de servicios de hora seguro, Cloudflare se complace en anunciar que somos uno de los primeros en ofrecer un servicio público de hora gratuito y seguro en base a la seguridad horaria en la red. Hemos implementado el último proyecto NTS IETF. A medida que este proyecto avanza a través del proceso de estándares de internet, nos comprometemos a mantener nuestro servicio actualizado.

La mayoría de las implementaciones de NTP actualmente funcionan en el soporte NTS, y esperamos que en los próximos meses haya una introducción más amplia, así como un avance del protocolo del proyecto actual a una petición de comentarios (RFC). Actualmente contamos con interoperabilidad con NTPsec que ha implementado el proyecto 18 de NTS. Esperamos que nuestro servicio incentive una adopción más rápida de esta importante mejora para la seguridad de internet. Como se trata de un nuevo servicio sin requisitos de compatibilidad con versiones anteriores, requerimos el uso de TLS v1.3 para promover la adopción de la versión más segura de TLS.

Si tiene un cliente NTS, direcciónelo a time.cloudflare.com:1234. De lo contrario, direccione a su cliente NTP a time.cloudflare.com. Más información sobre la configuración disponible en los documentos para desarrolladores developer docs.

Desde nuestro servicio Roughtime hastaUniversal SSL, Cloudflare ha ayudado a ampliar la disponibilidad y el uso de protocolos seguros. Ahora, con nuestro servicio público de horario gratis, ofrecemos una alternativa confiable y ampliamente disponible para otro protocolo heredado inseguro. Parte de nuestra misión es ayudar a que la internet sea más rápida, confiable y segura para todos.

Agradecemos a todos los ingenieros que trabajaron en este proyecto, entre ellos Watson Ladd, Gabbi Fisher y Dina Kozlov

Esta publicación es de Aanchal Malhotra, asistente de investigación de posgrado de la Universidad de Boston y expasante de Cloudflare en el equipo de criptografía.