Is NTP vulnerable to DNS poisoning or spoofing attacks?

Question

Scenario:

1. Attacker somehow compromises the DNS lookup for the NTP server used by the victim (a web application)
2. Victim sends DNS request for e.g. ntp.pool.org, which is responded to by attacker to direct the victim to another computer under their control
3. Attacker issues incorrect timing information via NTP
4. Attacker performs attack on victim that depends on victim's knowledge of the current time being incorrect

Is this possible? If so, what should be done to mitigate against it? Are there any other similar attacks?

An interesting thought that occurs to me: if the resulting time change is small, this may be hard to distinguish from a correct NTP response.

Answer 1

I realize that this was asked some days ago; and this answer may languish at the bottom here. However, there are some simple 'system administrator' tips that need mentioning.

Yes, DNS hijacking and Man-In-The-Middle attacks do work against NTP as it is commonly deployed today. NTP is often / most often used across the Internet, without encryption (SSL), and without authentication.

And many companies under-invest in accurate time keeping. Accurate time keeping is required for many authentication protocols such as Kerberos, but it goes further than that, precise time is essential for fx post-attack forensics.

That said, in practice NTP isn't that common an attack vector. If you disagree, then please post links. :-)

• In OP's case, the attacker subverts the DNS entry for a well-known NTP source such as pool.ntp.org. That's a valid concern. However an old and widespread best practice is to use many (5, 7, or 9) upstream NTP servers to guard against "falsetickers". With three upstream NTP servers the client can identify and ignore one falseticker; with 5 upstreams up to two falsetickers can be mitigated; etc.

• A good sysadmin will also have considered BGP route diversity; network latency; and the stratum of upstream servers when selecting his upstream NTP servers. There are many NTP servers out there, both widely publicized services such as pool.ntp.org and lesser known local ISP NTPs, local university services, etc. This again provides some 'strength in numbers'.

An interesting thought that occurs to me: if the resulting time change is small, this may be hard to distinguish from a correct NTP response.

Assuming a) you are following best practice and have multiple upstream NTP servers, and b) the majority of your upstream NTP servers have not been hijacked, then this isn't so hard really. OpenNTPd is known to use a simple falseticker detection (slide 20+). AFAIK OpenNTPd does the following:

1. Calculate the median value of all NTP responses.
2. Find outliers, the NTP servers which deviate greatly from the median. Disregard these.
3. Using only the remaining NTP server responses, calculate the average, and use this value as the final result.

The reference NTPd is said have a more complex / more complete falseticker detection than OpenNTPd.

Answer 2

My answer is directed at the NTP protocol not a specific implementation of the protocol.

Is this possible?

Yes, however NTP (the protocol, not the implementation) has supported authentication since version 2 (1989). Authentication is a optional feature of the NTP protocol and I am not sure how widely it is used. NTP has five modes of operation. I think the modes implied in the question are mode three (client), and mode four (server). In this configuration a client sends requests for synchronization, and a server replies to the client with a synchronization response. Depending on the network between the client and the server, even with authentication it is possible for a attacker to interfere with the clients time synchronization. However, it will be difficult for a attacker to modify the clients sense of time significantly (more than several minutes).

If so, what should be done to mitigate against it?

Edit:

I had originally said that minor time shifting vulnerability would not be worth mitigating. D.W. disagreed noting Kerberos requires minute resolution time synchronization. Since I do believe that this type of attack could distort the client's sense of time by minutes, I am changing my answer.

It is worthwhile to note here that Active Directory relies on an implementaion of Kerberos, so if you use Active Directory for authentication this is relevent to you.

Lets model the problem as a four system network: A time server, an authentication server, an authentication client, and an attacker. For this scenario lets assume that the attack can not directly compromise the security of any node, but that she/he can read, modify, or block any network traffic.

The authentication server requests time data from the time server.

The attacker can intercept the request from the authentication server and retransmit the request to the time server after some delay.

When the time server responds, the attacker can intercepts the response and retransmit it to the authentication server after some delay.

The authentication client may get its time from either the authentication server or the time server or both. In this scenario it doesn't matter, because the attacker can perform the same delaying of messages between the authentication client and the time server and or between the authentication client and the authentication server. So, an attacker can effectively delay a time synchronization message for either the authenitcaion client, the authentication server or both.

Note: Kerberos is a complicated protocol the examples are not representative or real Kerberos transactions.

For kerberos, when a client makes a ticket request or service request, the client puts a timestamp in the request. The server recieving the request compares the time in the request to it's time. If the difference between the two times is more than a configurable value (default is 5 minutes) then the request is rejected. An attacker could create a time difference more than 5 minutes (most people use the default) by delaying time data to the authentication client, the authentication server, or both. However, given that the attacker can manipulate the data on the network, she/he could simplay delay the request from the authentication client to the authentication server.

An attack I was originaly thinking about is making a current credential with a validity period invalid. Assuming that the time data is unauthenticated, an attacker could impersonate the time server and cause a clients time value to move far into the future. If the time value moved beyond the credential's valid period, the credential becomes invalid. Conversely, if an attacker gains hold of an expired credential, and then causes the client's time value to move into the certificates validity period, giving the attacker a valid credential.

In an scenario where time data is authenticated, if an attacker intercepts time server data, and retransmit at a slower rate to a time client, the attacker will build a backlog of time data. At some point the attacker could accelerate the replay of time data causing the time client to sense a rapid shift forward. However in this scenario, the attacker could never move the clients time value forward of the actual time.

Mitigattions for NTP

• use NTP authentication (common secret key or Autokey) (nealmcb gets credit)
• use a local time source for some or all of your systems (both D.W. and nealmcb make this suggestion)
• use challenge response protocols (i.e. "don't use authentication protocols that rely upon knowing the correct time" D.W., additionally suggested by nealmcb)
• some type of time auditing where you check systems time values (better with a trusted time source)

Mitigations for Kerberos

• reduce the clock skew value (Maximum tolerance for computer clock synchronization)
• cache used authenticators (accept authenticators only once)
• use the network address in the service ticket
• add a cryptographic hash to the requests
• reduce ticket lifetime

for Windows Server 2003 Maximum tolerance for computer clock synchronization

Are there any other similar attacks?

Attacks based on the clients time value?

Yes, the first one that leaps to mind is to make an expired credential or certificate valid by turning back the clock.

Client server interference based attacks?

Yep, an attacker could do denial of service by forging NAKs to client or server. Exhausting all the DHCP leases on a network is an example of this.

Server impersonation attacks?

Yea, there is a neat one involving SIP phones not properly authenticating the server

Answer 3

NTP configuration is complicated by many factors, and existing NTP authentication mechanisms add a lot of additional complexity. Today, I suspect that the overwhelming majority of hosts that use NTP do not employ any authentication, and are thus, as you suggest, vulnerable to manipulation of their time, potentially by an arbitrary offset from the actual time. In addition, even when authentication is employed in NTP, a denial-of-service attack can prevent clients from getting in sync. So when possible, don't use authentication protocols that rely upon knowing the correct time - see D.W.'s answer for more.

Note that in some sense many authentication mechanisms rely on time (e.g. expiration dates for keys). On the other hand, you're likely to notice other things that will go wrong if the time is off by a lot. So depending on your threat environment, you may not want to sweat this a lot. If you do, you can configure authentication, or use GPS.

For organizations using Microsoft Active Directory (based on Kerberos), see Microsoft NTP Time Synchronization Spoof Weakness

See e.g. The Autokey Security Architecture, Protocol and Algorithms for a discussion of the unusually stringent requirements for NTP security:

the operation of the authentication mechanism and the time synchronization mechanism are inextricably intertwined. Reliable time synchronization requires cryptographic keys which are valid only over designated time intervals; but, time intervals can be enforced only when participating servers and clients are reliably synchronized to UTC. In addition, the NTP subnet is hierarchical by nature, so time and trust flow from the primary servers at the root through secondary servers to the clients at the leaves.

Answer 4

Yes, you are right. This is indeed a vulnerability. The NTP protocol, as typically deployed, is inherently vulnerable to active attacks, such as man-in-the-middle attacks, or DNS spoofing attacks. Security protocols that themselves require on a correct time (such as Kerberos) are thus themselves vulnerable in this threat model.

The most basic mitigation is: don't use security protocols that rely upon knowing the correct time. For instance, avoid Kerberos and other protocols that use timestamps for replay protection. Better to use challenge-response and random nonces.

A different mitigation is to use a trusted time source. A GPS peripheral is one way to get a trusted time source, though it will cost you ~ $100 per workstation, so it's far from cheap.