Manipulating time through (S)NTP

Contents:

1. What is NTP?
2. Sending forged NTP packets
3. Intercepting NTP packets
4. Consequences of NTP spoofing
5. How to prevent these attacks?

What is NTP?

The Network Time Protocol (NTP for short) is an old internet protocol from the 80's that is to this day still used on almost all devices to synchronize the device's time with a timeserver. These timeservers synchronize their own time with either other timeservers, or with a direct source of time like GPS signals or an atomic clock.

Who uses (S)NTP?

Almost all devices use NTP to synchronize their system clocks. However, most devices use clients that do not implement the full NTP protocol. These device use so-called SNTP clients, which implement Simple Network Time Protocol, which only supports a subset of the features of the full NTP protocol.

For example, SNTP clients use only a single timeserver to request time, whereas proper NTP clients often combine results from multiple servers. Furthermore, SNTP clients do not use noise filtering, which means they take the time data from a single NTP request as is.

Many Linux distributions, including for example Ubuntu and Arch, come with the systemd-timesyncd SNTP client. Windows and Android use their own SNTP clients, synchronizing with time.windows.com and time.android.com respectively.

MacOS and iOS also have their own SNTP clients. Although we did not investigate these clients in this project, we expect them to have similar problems as other SNTP clients.

How does (S)NTP work?

A device cannot simply ask for the timeserver for the current time to synchronize. Otherwise, some time will already have passed by the time it gets a response, which means it would always be slightly behind.

Instead, NTP uses four timestamps, t1 to t4, to synchronize the clock while taking the network delay into account. Here, we assume that the delay between when the request is sent (t1) and when the request is received by the server (t2) is equal to the delay between when the response is sent (t3) and when the response is received by the client (t4).

If for example the client's clock is slightly behind, then the time between timestamps t1 and t2 will seem larger than the time between timestamps t3 and t4. This difference shows how far the client's clock is ahead or behind the server's clock.

Of course, the network delay might not always be as symmetric as we assume. This is why proper NTP clients combine time data from multiple requests to multiple servers, and they apply noise filterting techniques to get more accurate results. However, SNTP clients will generally take the calculated time offset from a single request as is, as it is considered good enough for most devices.

There is, however, one big problem with these NTP packets: NTP packets are not authenticated!

Sending forged NTP packets

One way to attack NTP clients is to simply send forged NTP response packets to a device, hoping that the device will use the forged response instead of the response from the real NTP server. As NTP packets are not authenticated, the client cannot verify whether a packet came from the real NTP server or not.

NTP packets are sent over UDP, so there is no lasting connection after the response has been received. To have a client accept our forged response, a couple of conditions have to be met:

1. The forged response must arrive after an NTP request from the client, but before the real NTP server responds
2. The forged response must be sent to the correct port that is used by the NTP request
3. The forged response must have an origin-timestamp t1 that matches the NTP request

The first requirement can be met by continuously sending forged NTP responses to the client. If we are on the same network, the forged response should always arrive before the real response.

For the second requirement, we must guess the port over which the client sends the NTP request. The standard port for NTP is port 123, however, many (S)NTP clients use port randomization, which means they use a random port for each request.

For the third requirement, we must guess the origin-timestamp t1. If we synchronize to the same NTP server as the client, we should be able to be within a millisecond of the client. However, NTP timestamps are precise up to 0.232 nanoseconds, so the remaining sub-millisecond fractional value will need to be guessed.

Modern NTP clients often send a completely random 64-bit value in place of the timestamp t1, making it even harder to guess. Without timestamp and port randomization, we would have a decent chance to have our forged response be accepted by the client. Simply by sending many packets, we should be able to guess the sub-millisecond bits of the origin timestamp. However, with timestamp and/or port randomization this attack is much less likely to succeed.

By looking at NTP traffic, we saw that timesyncd does use port randomization, although it did not use timestamp randomization. Tweede golf's David Venhoek patched timesyncd in early 2024 to use timestamp randomization, although many devices currently have not updated to this patch yet. Before it used timestamp randomization, it used a nanosecond-precise timestamp for t1. Together with the randomly chosen ephemeral ports between 33295 and 60899, we have many possible combinations. So it seems infeasible to attack timesyncd by simply sending many NTP packets.

Similarly, Android also uses port randomization for NTP. However, it appeared that there were two different SNTP clients sending requests on the Android device, one of which did randomize the timestamp, while the other did not.

On Windows 10, it seems neither port randomization nor timestamp randomization is used, which means Windows is likely vulnerable to NTP flooding attacks.

Intercepting NTP packets

Instead of trying to guess the port and the origin timestamp, forging NTP packets becomes much easier if we are able to intercept the request from the client or the response from the server. In a previous blog post, we saw how a router can be maliciously configured to redirect and modify NTP packets. However, by using ARP spoofing we can do this without having access to the router.

ARP spoofing allows us to redirect traffic to or from the client to our own device. The ARP protocol is used on local networks to determine to which device an IP address belongs. ARP spoofing abuses this functionality to convince the devices on the network that traffic for certain IP addresses should be redirected to our device instead.

As NTP packets are not authenticated, we can modify them without the client noticing. In 2016, Davide Bove published a script to modify NTP packets intercepted via ARP spoofing. We tested this script on a number of different devices to see how easy it is to alter the time on different operating systems and (S)NTP clients.

Linux (timesyncd)

With timesyncd, this attack is very easy to perform. The timesyncd NTP client synchronizes every 5 minutes or so, which means we do not have to wait long before the device's time will be affected by our attack. It accepts any time offset, which makes it possible to set the device's time years ahead or behind the current time.

Windows

On Windows, it only seemed to accept offsets up to 16 hours. If the offset is 16 hours or more, it will show "Time synchronization failed" when manually synchronizing the time via the "Date & Time" settings menu. Automatic time synchronization on Windows happens only infrequently, about once per day. This means that you have to run the ARP spoofing attack for much longer before you get to spoof an NTP packet.

Android

For Android, we ran into an issue when performing this attack. When using the script to ARP spoof the Android device, the phone would automatically disable the WiFi network because it has a "limited connection". This is caused by a connectivity check that tries to contact a Google server to see if the WiFi network is working correctly. However, because we are ARP spoofing the network traffic going to the device, the TLS connection for this connectivity check fails, causing the network to be disabled.

Instead, we need to ARP spoof in both directions to get the connectivity check on Android to succeed. If we do this, we are able to successfully change the system time by modifying NTP packets. Similarly to Windows, it only synchronizes time automatically on an infrequent basis, about once per day. However, it also synchronizes after the device (re-)boots, and it may resynchronize after switching WiFi networks.

Consequences of NTP spoofing

So far, we have seen how we can manipulate the time of many devices by abusing their default SNTP clients. But why would an attacker want to manipulate a device's system time? It could for example cause users to miss calendar notifications, but there are also more severe things that could go wrong when the system time is misconfigured.

We have categorized the potential consequences in four categories: timed events, access windows, cryptography and data synchronization.

Timed events

Other than calendar notifications, there are also various other timed events that could be delayed or executed early by modifying the system time. This includes for example automatic updates, backups, and other cron jobs. This could be especially bad if an update is meant to fix some other vulnerability, as postponing the update could cause a machine to be vulnerable for longer.

Access windows

When using online services, some functionality might only be available within a certain time window. For example, a ticket sale may open at a certain time, or a submission deadline may close at a certain time. Furthermore, access windows may be used as a security measure, where people are for example only allowed to access a machine during working hours. These access windows could be shifted by manipulating the system time, either preventing people from having access when they are supposed to, or giving the attacker access at a time when they are not supposed to have access.

Cryptography

Many cryptographic algorithms rely on timestamps to guarantee freshness and to prevent replay attacks. For example, time-based one-time passwords are only valid for a short time after they are generated. If the client's clock is misconfigured, then this will prevent them from using these one-time passwords to authenticate. If the server's clock is misconfigured, then this might even make it possible to perform replay attacks.

Similarly, cryptographic certificates have a set validity period. So, if a device's system time is too far off, it might not be able to accept TLS certificates, which means it cannot use HTTPS. The device may even accept older, expired certificates, which may rely on weaker cryptography or may have been compromised.

Some cryptosystems may use time-based keystreams. This means that if you can control the device's time, you can make the device replay the same keystream multiple times, thus exposing any encrypted secrets. It was this kind of weakness that was recently discovered in TETRA, the radio system used by many militaries and emergency responders. While TETRA does not use NTP for time synchronization, a similar spoofing attack as described in this blog post allowed Midnight Blue to mess with the device's time to replay a keysteam.

Data synchronization

Within distributed systems, data is often replicated across many servers. To keep all servers up to date, when a server makes a change, the change needs to be forwarded to the other servers. It is important that these updates happen in the correct order, as otherwise data might get corrupted or lost.

Furthermore, caches are often used to prevent clients from having to reload data for a certain amount of time. Manipulating the device's clock could cause caches to last for longer or to expire earlier than expected. This could for example make DNS cache poisoning easier, as the spoofed DNS results could remain in the cache for longer.

Lastly, servers keep track of events in logs. Messing with the server's time will cause events to be written to the logs with incorrect timestamps, making it more confusing for someone trying to investigate what is going on, especially when dealing with multiple servers.

How to prevent these attacks?

Various limits can be configured in NTP clients to prevent synchronizing to unexpected time deviations. For example, the maximum 16 hour offset we saw on Windows is a good first step. Furthermore, noise filters in proper NTP clients also make it more difficult to manipulate time.

However, to fully protect NTP from man-in-the-middle attacks, proper authentication should be used. Network Time Security (NTS) adds authentication to NTP by first doing a key-exchange, after which the NTP packets can be authenticated using encrypted cookies. The server will then include fresh new cookies with each response to allow the client to keep making requests.

As NTS is still fairly new, not many time servers support it at this point in time. For NTP pools, which distribute NTP traffic over multiple servers, there is still work that needs to be done to enable NTS. Hopefully, we can move towards a future where devices use a secure source of time that is not easily manipulated by the attacks described above.

Support a safer internet

If you’d like to support or discover more of the work we’re doing on secure time synchronization for a safe internet, please visit the Time synchronization initiative page on the Trifecta Tech Foundation website. The Trifecta Tech Foundation is the non-profit that is the long-term home of our time synchronization work, including ntpd-rs (Network Time Protocol) and Statime (Precision Time Protocol).