Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top


  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., 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.

share|improve this question

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.

share|improve this answer
No, the NTP protocol (I don't know about specific implementations) has had server authentication since version 2. See Network Time Protocol, Version 2, Specification and Implementation, Appendix C. Authentication Issues – this.josh Jul 3 '11 at 8:19
That authentication is available is irrelevant until widely implemented. It's like saying IP got no security issues because IPsec is available. – Bruno Rohée Jul 3 '11 at 17:12
@bruno-rohee The answer only talks about the protocol, not the implementation. I agree that the implementation is more important than the protocol, but no implementation seems to be mentioned here. – this.josh Jul 5 '11 at 21:48
Just a bit of context: Kerberos is generally used on a LAN (there are some exceptions, of course.) It is very doable to provide the LAN with a reliable authoritative time server, and set up secure time distribution to the clients. The finer points of how would depend on the threat model, but fx Active Directory’s built-in time sync; or NTP with auth; or NTP tunneled through crypto. So NTP vulnerabilities are very real; but on the LAN they can be mitigated, also without a GPS at each workstation. The larger NTP concern is for services which run across a WAN / over the Internet. – Jesper Mortensen Jul 6 '11 at 22:42
@Jesper, your analysis seems to assume that every machine connected to the LAN is trustworthy, and only external machines are untrustworthy. While that is a reasonable first approximation, we have discovered that it is not really accurate; internal machines do get compromised all the time (hence the problems with relying solely on perimeter security). – D.W. Jul 7 '11 at 4:17

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?


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

share|improve this answer
"However, it will be difficult for a attacker to modify the clients sense of time significantly (more than several minutes)." Not so, though it may take time. E.g. if the client uses only one server, the server can, over time, build up an arbitrary time offset. There are various protections to prevent sudden large changes in time which make such an attack take longer. – nealmcb Jul 3 '11 at 17:00
@nealmcb Yes, difficult. Most systems have time displayed to the user, and use of NTP typically modifies the time displayed to the user. A significant change in time would become obvious to a user. Some systems rarely have users login, and those will not be protected by user observation. However, these system are often involved in networked periodic events (SNMP status checks) and automated administrative tasks (backups). I believe it likey that significant time discrepency would be notice during these activities. So maybe it is more a question of how long until a discrepency is detected. – this.josh Jul 4 '11 at 4:33
@this.josh: "unlikely to be worth protecting against" - I disagree. There are some security systems whose security is reliant upon having correct time. Kerberos is one example. If the local time is incorrect, replay attacks become possible. – D.W. Jul 5 '11 at 19:53
@this.josh: "A significant change in time would become obvious to a user" - I think that's overly optimistic. First of all, servers typically have no user who could possibly notice, so such attacks are very unlikely to be detected on a server. Second of all, on a client, users might not notice, especially if the attacker sets the time to an incorrect value, mounts the attack, and then restores the time to its correct value. I do not believe that it is prudent to rely upon attacks on NTP to be detected: they might be detected, but they equally well might not be. – D.W. Jul 5 '11 at 19:55
@D.W. edits made, removed opinion of protection worth, removed user detection. – this.josh Jul 6 '11 at 1:03

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.

share|improve this answer
Am I understanding correctly, that you're recommending against using Kerberos? Or are you referring only to precise time? – AviD Jul 4 '11 at 22:54
@avid As with the rest of my answer, I'd say (as always) that it depends on your threat model. The level of vulnerability of Kerberos to NTP attacks is worth more study, from what I can tell, and worth a question here.... – nealmcb Jul 5 '11 at 22:41
Just an additional comment: When reliable and tamper-proof timekeeping for a trusted LAN is required, then that's quite easy to get, at least for reasonable levels of 'tamper-proof'. Plug and play GPS, Galileo (EU GPS) and DCF77 equipment can be had for a couple of thousand dollars. In many/most cases, getting reliable time is probably cheaper than switching to another form of authentication protocol. – Jesper Mortensen Jul 6 '11 at 22:15

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. :-)

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.

share|improve this answer
Here is a specific example of spoofing an NTP request can be an attack vector:… – Konr Ness yesterday

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.