The Network Time Foundation's Network Time Protocol Project has patched multiple denial-of-service vulnerabilities with the release of ntp-4.2.8p9. The last update to the open source protocol used to synchronize computers clocks was in June.
"NTP users are strongly urged to take immediate action to ensure that their NTP daemons are not susceptible to being used in DDoS (distributed denial-of-service) attacks," the project maintainers wrote in the security advisory.
NTP is a widely used protocol, and has been hijacked several times over the past two years in distributed denial of service attacks. Attackers harness the power of the servers running NTP and amplify the amount of traffic -- as much as 1,000 times the size of the initial query--being sent to victim systems. Research from network security company Arbor Networks estimated that 85 percent of volumetric DDoS attacks exceeding 100 Gbps in size were NTP reflection attacks.
Some of the vulnerabilities are easy to exploit, and there is a proof of concept already available for one of them. Attackers are increasingly exploiting the limitations of older protocols like NTP to generate large volumes of junk traffic used for large DDoS attacks, network company Akamai said in a previous State of the Internet report.
Issues fixed in ntp-4.2.8p9
The most serious vulnerability lets attackers crash Windows systems by sending "too big" packets (CVE-2016-9312). The update also includes fixes for two medium, two medium-low, and five low-severity vulnerabilities, all of which can be exploited to cause a denial-of-service. One of the medium-severity flaws (CVE-2016-7431) was related to a regression in the handling of some Zero Origin timestamp checks. One of the low-severity flaws (CVE-2016-7433) was related to a previously fixed bug where the jitter value was higher than expected and affected initial sync calculations.
Two vulnerabilities were related to the trap service in NTPD. While trap is not enabled by default, if the service is explicitly enabled, attackers can send specially crafted packets to cause a null pointer dereference (CVE-2016-9311) that will crash NTPD. The configuration modification vulnerability in the control mode (mode 6) functionality of NTPD (CVE-2016-9310) can be exploited by a remote, unauthenticated attacker.
"If, against long-standing BCP recommendations,
restrict default noquery is not specified, a specially crafted control mode packet can set NTPD traps, providing information disclosure and DDoS amplification, and unset NTPD traps, disabling legitimate monitoring," according to the advisory.
Two of the low-severity vulnerabilities exploited NTP's broadcast mode. Originally intended to be used only on trusted networks, attackers with access to the broadcast service can abuse the replay prevention functionality (CVE-2016-7427) and the poll interval enforcement functionality (CVE-2016-7428) to cause NTPD to reject broadcast mode packets from legitimate NTP broadcast servers.
If NTPD is configured to allow mrulist query requests, a server sending malicious mrulist queries will crash NTPD (CVE-2016-7434). The researcher who reported this vulnerability, Magnus Stubman, has publicly released the proof of concept, likely because the low-severity vulnerability, with a score of 3.8 on the Common Vulnerability Scoring System, is highly exploitable.
"The vulnerability allows unauthenticated users to crash NTPD with a single malformed UDP packet, which causes a null pointer dereference," Stubman wrote.
If the server response on a socket corresponds to a different interface than what was used for the request, NTPD updates the peer structure to use the newer interface. On hosts with multiple interfaces in separate networks and where the operating system isn't checking the packet's source IP address, attackers can send a packet with spoofed source addresses to trick NTPD to select the wrong interface (CVE-2016-7429). Repeating the attack even just once per second is enough to prevent NTPD from synchronizing with the time server.
Rate limiting prevents brute-force attacks on the origin timestamp, but if the server is misconfigured, it can be abused in a DDoS attack. Attackers can send packets with spoofed source addresses and keep the rate limiting activated, which would prevent NTPD from accepting valid responses from other sources (CVE-2016-7426).
Mitigations and recommendations
Along with updating to ntp-4.2.8p9, the project maintainers recommended implementing Ingress and Egress filtering through BCP-38 to "defeat denial-of-service attacks." Many DoS attacks rely on IP source address spoofing to hide the packet's point of origin, making it hard for defenders to know where the network traffic is coming from. BCP-38 filtering lets administrators block IP packets that have forged IP addresses. If the device is not allowed to send packets with source addresses other than its own, then that device can't be hijacked to spew junk traffic as part of a DDoS attack.
Other recommendations included:
- Monitoring NTPD instances and auto-restarting the daemon without the -g flag if it stops running
restrict default noqueryin the ntp.conf file to allow only mode 6 queries from trusted networks and hosts
- Using broadcast mode only on trusted networks
- Creating a firewall rull to block oversized NTP packets, especially on Windows
- Allowing mrulist query packets only from trusted hosts
- Configuring the firewall to control what interfaces can receive packets from which networks, especially if the operating system won't be performing source address checks
- Configuring rate limited with
restrict sourcein the ntp.conf file, instead of
restrict default limited
The US Department of Homeland Security's Computer Emergency Response Team at Carnegie Mellon University's Software Engineering Institute maintain a list of vendors implementing NTP. At the moment, the status of most vendors is listed as "Unknown."
Update or replace?
Whenever there is a security vulnerability in a widely used open source project, a segment of IT and security folks pounce on the report as proof people should abandon using the software and switch to something else. NTP is no different, as the 30-year-old protocol lacks security features and is vulnerable to abuse. There are many who think administrators should use secure alternatives, but most tend to be complex or not yet mature enough for widespread use.
The "don't update, replace," argument is impractical. Replacing crucial services without thinking through how the new tool would be supported causes more administrative headaches. It may be a simple enough task to uninstall NTPD, but if administrators don't know how to configure the new tool correctly, monitor the performance, and troubleshoot resulting issues, then the replacement tool doesn't do much to improve overall security. Any replacement should come after a thorough review of the alternatives, be tested thoroughly in a non-production environment, and have controls to monitor and secure the software. Don't replace; update instead.