How much time have you spent thinking about NTP last week? If you’re like most IT/IT Security pros out there, the answer to that would be anywhere between 0 and 10 minutes. The reason is simple “What’s there to think about?” Often, NTP is one of those things that “just works” and nobody needs to know how or why. However, I am of the opinion that this is important, atleast a little bit. The reason is this; Over the last 20 penetration tests that our company has performed, NTP attacks featured in over 15 of these tests. Thats a 75% hit rate! And that’s pretty significant.
Protocol and Background
The Network Time Protocol (NTP) is an important network protocol that is used pretty much everywhere. It runs on your mobile device, laptop, servers, network devices, and not to miss the release of an important technological innovation, the smartwatch as well. The NTP (currently at v4) is a clock synchronization protocol. It uses a hierarchy of time servers (sources) to ensure that client system clocks are synchronized to the closest millisecond. It is uses Marzullo’s Algorithm to propagate time to clients accounting for network latency and so on. It runs on port 123 UDP.
NTP Synchronization
As you read this, you would probably realize that this is a pretty critical network protocol. It is required to maintain consistent time across all your company’s systems, network devices, servers, workstations. If the NTP doesn’t work properly, your logs go haywire, your software licensing gets really complicated and scheduling apps go for the proverbial toss. Most companies I know (especially the medium to large ones), run dedicated time servers to propagate across thousands of systems in their network.
However, little did most of these companies imagine that NTP can be used to bring down their critical systems through a process called “NTP Amplification”. This is the focus of this article.
What is NTP Amplification? Why’s it so bad?
NTP Amplification is akin to a Distributed Denial of Service Attack. Let me explain how it works. In your organization, you would typically run a network device or a server to synchronize internal clocks using NTP. Your server is running NTP on port 123 UDP. Systems request your NTP server for the time and the server responds with the latest time. However, in certain NTP servers, there is a command called “monlist”. This command provides the client with a list of the last 600 devices that have synchronised with the NTP server. You can probably see where I am going with this, but let me continue. In an NTP Amplification attack, lets assume that an attacker has IP 10.10.10.10 and the server is at 10.10.10.2. The attacker sends a request to the NTP server requesting the monlist (list of upto 600 systems which the NTP server has responded to recently). Now, the server receives the request and responds with a list of all systems (600) that it has responded to.
Let’s say a typical NTP response is 230 bytes, a busy NTP server with 600 recent responses would respond with a amplified response that would be 200 times the original response size. Repeated requests to the server are likely to crash the service/server and cause outage that could hinder multiple activities like scheduling, logs, etc. For instance, if a bank’s card management servers run scheduling apps to push and pull financial reconciliation data from systems, they would be severely impeded by an amplification attack. Financial companies, Gaming Companies, SaaS Applications and Educational Software and any other heavily time-dependent services would be badly affected by an NTP Amplification Attack.
NTP Amplification Attack
In addition, one of the major issues with the monlist command that facilitates Amplification is the possibility of Information Disclosure. If an attacker needs to enumerate hosts on a Network, the monlist output provides the attacker with a wealth of information on the hosts that are connecting to the NTP server. The attacker can identify hosts and pivot by identifying vulnerabilities across different hosts.
Another possible misconception would be that only *designated* NTP servers run the NTP protocol. That’s not true. Often, several apps install NTP listeners and servers on other systems and components. So, if you’re not sure about where you are running NTP, this attack could be across the network, unless you’re well prepared
What Next?
First, you need to be running extensive discovery scans to identify open NTP servers and services in your network. Later, you need to identify if they are vulnerable. If they are responding to the monlist command, chances are that the server is vulnerable. Then, you can configure the NTP servers to a more secure config or upgrade to a newer version of the service. Team Cymru has an awesome secure NTP template that you can use to secure your NTP server. Its available here.
