Network Time Protocol Oracle Forensics tips by Paul Wright

The NTP protocol (http://www.faqs.org/rfcs/rfc1305.html) works over UDP port 123 and is currently at version 4 which has been stable since the early 1990s. NTP uses a networked time signal that originally comes from a stratum 1 server which should be a very accurate time source reference. Time then filters down from stratum 1 to lower stratum 2, then 3, 4 up to a potential limit of stratum 16 which is rarely used. The system can be reciprocal and works on an algorithm that allows an average time to be calculated from different sources but essentially relies on a trust relationship between the receiver of the time signal and the sender.

Problems with NTP

1. Firewall administration's understandable reticence to open UDP port 123 on the perimeter to a public NTP server on the Internet.

2. Network administration's understandable reticence to trust the network time of an external time source.

3. The possibility that the source of the time signal could be spoofed, particularly as communication is over UDP, resulting in an incorrect time being utilized.

4. The possibility that UDP port 123 could be subjected to a DoS attack, therefore preventing time synchronization.

5. The possibility of a remote exploit that could give external access to the internal NTP server.

6. NTP version 3 and SNTP have no built in security. Version 4 can optionally be secured but the balance is that encrypting traffic and or verifying checksums is going to slow down the transfer of packets therefore making the system inaccurate. Windows clients use NTP V3. Most NTP systems are not secured.

If an external attacker can spoof a signal from the time server that the company uses then they could send an incorrect time signal. The usual mechanism for NTP server identification is via hostname through the DNS system. The reason for this is that the supplier of time may change their IP address. So the first step for an attacker would be to identify the NTP server for the organization. This can be done using the ntptrace command as below which shows a stratum 1 server.

root@localhost:~$ ntptrace ntp.cis.xxxxx.ac.uk ntp.cis.xxxxx.ac.uk: stratum 2, offset 0.001117, synch distance 0.018009 ntp2-rz.rrze.xxxxxxx.de: stratum 1, offset 0.000000, synch distance 0.000000, refid 'GPS

However most NTP servers no longer allow this functionality, which can be confirmed by going through a list of public time servers and trying the ntptrace command. This is important in a commercial situation where the established practice has been to synchronize to three stratum 2 NTP servers and take the average. If they are all running from the same stratum 1 server source upstream then there is no "strength in variety" and the average of downstream servers will be meaningless. Hence the need for some kind of human communication between the NTP server provider and the receiver to ascertain the upstream source is different from the others. Either that or synchronize directly to three stratum 1 servers. One problem with this is that in the UK at time of writing there are only two official, publicly accessible stratum 1 servers available according to http://ntp.isc.org/bin/view/Servers/StratumOneTimeServers.

There are, however, many unofficially recognized stratum 1 servers which leads us to the main Achilles heel of the system. Anyone is able create a top level Stratum 1 server using tools such as XNTP, available from http://www.five-ten-sg.com/. XNTP runs on Windows very easily as shown below via the ntptrace command on a stratum 1 server created by the author in a few minutes.

C:\Documents and Settings\Administrator.SERVER.000>ntptrace 127.0.0.1 localhost: stratum 1, offset 0.000000, synch distance 10.86559, refid 'LOCL

The low barrier to setting up a stratum 1 NTP server has caused problems for organizations wishing to have time synchronization. First of all it is relatively easy to setup a spoofing NTP server and since the protocol is UDP, no three way handshake is required to confirm the sending IP address. Crafting a packet that sends the incorrect time to an SNTP client is trivial. GUI based packet crafters such as NetDude http://netdude.sourceforge.net/ by Christian Kreibich and spoofed packet sending tools like TCPReplay http://sourceforge.net/projects/tcpreplay/ allow for easy creation of an NTP packet that has an incorrect time and spoofs the source IP address of a real and trusted NTP server.

This problem is exacerbated by the fact that Windows clients use Simple Network Protocol or SNTP based on the older NTP version 3 which only has the option of symmetric key cryptography and so faces the practical problem of secure key distribution. Windows time service may be a possible future target for attackers but at this time it is worth outlining the reasons why an attacker may wish to alter the time of a computer or networked system.

 

This is an excerpt from the book "Oracle Forensics: Oracle Security Best Practices", by Paul M. Wright, the father of Oracle Forensics.