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