Andrew McGarry

Daniel Lopresti

Lehigh in Ireland 2014

August 9, 2014

Demonstrating a Security Flaw in Authenticated NTP

Abstract:

This report details a project whose central goal was to explore and demonstrate a security flaw in Authenticated Network Time Protocol. The particular exploit which this project focused on involves a Man-in-the-Middle (MitM) attack where the attacker masquerades as a legitimate NTP server after brute forcing a 32-bit cookie generated during the initial authentication process. Once the correct cookie has been guessed, the attacker can then conduct an Address Resolution Protocol (ARP) poisoning attack to direct NTP traffic destined for the legitimate NTP server to a target of his or her choice (usually the attacker’s own machine). This then allows the attacker to feed the NTP client false timing information, leading to a number of adverse effects which range from misrepresentation of the current time to system failure. Control systems, such as those which would be used to monitor power usage in a smart grid, can be made blind if enough measuring devices are deprived of a proper sense of time, potentially leading to catastrophic failures. To demonstrate this exploit, our group decided to set up a small virtual computer network and then conduct this attack on an Authenticated NTP session established between two of the machines.

Introduction:

During the 1980’s, as control and measurement applications became increasingly complex and computationally demanding, there grew a need for a technology capable of synchronizing time between disparate computing devices. Several solutions to this problem were developed, including GPS time synchronization, reference broadcast synchronization, and Network Time Protocol. Although GPS and reference broadcast synchronization are excellent sources of time, Network Time Protocol (NTP) is by far the most broadly applicable since it can operate over the wired and wireless internet protocol networks commonly incorporated into buildings. Radio waves do not propagate well through dense materials, making GPS and reference broadcast synchronization problematic in buildings and urban environments.

As a result of this shortcoming, NTP has been an extremely common means of synchronizing time across computer networks for more than a decade, and its applications continue to evolve. The recent push towards smart grid technology, for example, will see the introduction of NTP into a new domain: critical infrastructure. Smart grid technology promises to improve the efficiency and reliability of the United States power grid through the addition of internet-enabled sensors. Ensuring that the various sensors and control systems all keep the same time opens up a whole new range of capabilities for power grid engineers, and because many of these devices will be internet-enabled, using NTP to synchronize time across the grid is an attractive option.

It is not however, a safe option. NTP in its base form has no authentication scheme to verify clients or legitimate servers and has been used as the basis for several distributed denial of service

(DDoS) attacks over the years because of it. The addition of Autokey, an authentication mechanism, lead to the advent of Authenticated NTP. The fact that NTP can now be set up with an authentication mechanism makes it a better candidate for use in critical infrastructure, yet even this measure has not made NTP invulnerable to exploitation. Recent scholarship has uncovered several attack vectors, or means of exploitation, relating to Authenticated NTP. These discoveries have kicked off a wave of investigation into security improvements for Authenticated NTP with the ultimate goal of preparing it for use in critical infrastructure.

Project Goals:

The main goal of this project was to explore and demonstrate a security flaw associated with Authenticated NTP.

With regards to exploration, my partner and I set out to learn about Network Time Protocol, its importance and how it functions. In addition, we wished to learn how to utilize tools commonly used in computer science research while also introducing ourselves to computer networking and network security.

The demonstration portion of our project involved a two-stage approach. Stage 1 was to consist of a computer network featuring an NTP client/server relationship and the capability to monitor network traffic. In Stage 2, we would conduct a Man-in-the-Middle (MitM) attack within this network with the goal of spoofing an NTP client into accepting the attacker as a legitimate NTP server.

Network Time Protocol:

Network Time Protocol (NTP) is an application-layer protocol which allows computing devices to synchronize their clocks to reliable time sources over a network connection. NTP operates as a hierarchy of levels, known as stratum. The lowest level, Statum 0, refers to national time sources to which Stratum 1 servers are directly connected via satellite, radio, or telephone modem. Stratum 2 servers receive their timing information from Stratum 1 servers, Stratum 3 servers from Stratum 2 servers, and so on.

The goal of NTP is to synchronize all participating computing devices to within a few milliseconds of the Coordinated Universal Time (UTC) timescale, a timing standard observed by many national laboratories. It does not however, inherently account for regional time differences, so differences in time zones must be accounted for on a per-user basis. Leap seconds are accounted for and occur approximately every 18 months.

As for the architecture of the protocol, NTP relies on packet exchanges between clients and servers using its own set of on-wire protocols. A dual set of poll and peer processes governs when such packets are sent and what happens when they are received. The poll process sends NTP packets at a rate of one every 8 seconds to 36 hours in order to maximize accuracy and minimize network load. If the packet passes a sanity check, the peer process runs the on-wire protocol which relies on four timestamps.

The timestamps are:

T1 : The time of departure of the request packet from the client T2 : The time of arrival of the request packet at the serverT3 : The time of departure of the reply packet from the server

T4 : The time of arrival of the reply packet at the client

NTP calculates several values to assess the accuracy of the time it exports based on these timestamps: offset, delay, jitter, frequency error, and stability. Perhaps the most import of these four statistical values is the offset, which measures the asymmetry of the round trip time. If the offset is too high, NTP prevents the client from synchronizing with the target server.

In order to continue to receive timing information from an NTP server, an NTP client must first synchronize with the server. The synchronization process is a series of five request/receive exchanges. In each exchange, the client first queries the server for the current time by sending out a UDP/IP packet containing a timestamp denoting the time of departure (T1). As soon as the packet is received, the server marks down the time at which the packet was received in a timestamp (T2) and adds it to the packet. The server then adds an NTP timestamp containing the time at which the reply packet will be sent (T3) to the packet, and finally, the client then records the time at which the reply packet arrives (T4) in a final timestamp. Once the client has received and generated all four timestamps, it can then perform a sanity check on the exchange. If the test is passed, another exchange is allowed to occur. After five successful exchanges and sanity checks, synchronization is achieved and any further timestamps received from the NTP server are used to set the client’s clock.

Normal operation for NTP is very similar to the synchronization process. NTP uses UDP/IP packets exclusively for information transfer and has designated port 123 as the official NTP port. The client and server use the same request/receive format as detailed above, with both the client and server adding NTP timestamps to the packet until they are all finally collected by the client. After synchronization though, the offset value calculated using the timestamps is run through an algorithm and then used to adjust the system clock and frequency of the client. The only other important difference between synchronization and normal operation is that in normal operation, the frequency of exchanges decreases with each successful exchange until eventually, exchanges occur only once every 36 hours.

In order to make use of NTP, all that is required for clients is that they download the current NTP distribution. The distribution installs several programs, the most important of which are ntpd (NTP daemon), ntpq (NTP query), and ntpdate. ntpd is an operating system daemon which deals with the regular operation of NTP, namely synchronization and normal operation polling intervals. It is capable of setting the system clock and frequency after it has successfully synchronized with an NTP server. ntpq is a utility program used mainly to check the status of an NTP connection and diagnose connection issues. Finally, ntpdate is used to retrieve the date from an NTP server and set the system clock without having to go through the synchronization process. Only one query/reply exchange is run by ntpdate, and the result of the query is automatically used to set the system clock. ntpdate, like ntpq, is mainly used for debugging purposes.

Authenticated NTP:

Authenticated NTP was introduced in order to ensure the security of timing information across computer networks. Many control systems have very small tolerances when it comes to time synchronization, so even small discrepancies between the various devices’ times can cause catastrophic failure. Since the only form of security which the base form of NTP offers is protection from packet loss

and replays, Authenticated NTP was added as an addition to NTP in order to provide some measure of security.

The main advantage of using Authenticated NTP is the incorporation of an Autokey public key algorithm. The Autokey authentication scheme involves the use of digital certificates to verify a chain of verified NTP servers and a public key cryptography scheme. At the start of every Authenticated NTP session, clients request a series of digital certificates. The chain of certificates starts with a Trusted Host (TH), usually a Stratum 1 server. The TH’s certificate is self-signed, and so represents the start of the certificate chain. Any Stratum 2 servers connected to a TH in turn receive a certificate signed by the TH. Stratum 3 servers receive certificates signed by the Stratum 2 servers they are connected to, and so on. NTP clients receive a copy of each certificate in the chain leading back to the TH from which the timing information is derived.

Once the certificate chain has been resolved, NTP clients request a cookie from the server. Cookies are 32 bit sequences generated using a client’s public key and a server’s private key and are used to authenticate packets sent from the client. In addition to using its own private key to generate the cookie, servers use a sequence called the server seed in the formation of the cookie. The server seed is not shared with the public and so represents a secret known only to the server. This fact is important because it means the server seed is the only piece of information used to authenticate packets which cannot be gathered simply by monitoring network traffic between an NTP client and an NTP server.

The Autokey authentication process is detailed in the figure below:

As previously mentioned, the cookie is a 32 bit sequence generated using the client public key, the server private key, and the server seed. It has the following format:

Cookie = MSBs32 (H (Client-IP || Server-IP || 0 || Server Seed)), e.g.Cookie = EClient(MSBs32 (H (Client-IP || Server-IP || 0 || Server Seed)))

Remark: || = Concatenation, H = hash function (MD5 or SHA1)Remark: The server is stateless and has to recalculate cookie whenever a client contacts itRemark: The Server Seed is 32 bit long. It is shared for all client cookies and changed every 24 hrs.

During normal NTP operation, the cookie is incorporated into the NTP packet in order to authenticate the source:

NTP Packet = NTP-Payload || KeyId || MAC

Remark: the NTP payload is not encrypted and is easily readable

Message Authentication Code (MAC) = H (Autokey || NTP-Payload) KeyId is 128 bits long and picked by the client at the start of every NTP session.Autokey is 128 bit long and calculated as follows:Autokey = H (Sender-IP || Receiver-IP || KeyID || Cookie)

The Autokey authentication scheme is not invulnerable. One particular exploit which was discovered by computer science academics recently takes advantage of the fact that the cookie, which contains the only bit of information which can’t be collected by observing normal NTP traffic, is only 32 bits long. An attacker who attempts to brute force this sequence by bombarding the server with bogus requests can successfully guess the cookie in about 10 minutes. Demonstrating this particular exploit was the subject of our project so I will describe how such an attack is conducted.

In this attack, we assume that an NTP connection has been established between a client and a server, that the Autokey authentication sequence has already occurred, and that the client is already synchronized to the server. When a MitM enters the scene and begins to sniff the packets being exchanged between the client and server, three pieces of information are readily available to him. By just sniffing the UDP packets exchanged by the client and server, the MitM can determine the client’s IP address, the server’s IP address, and the key ID. Since the ultimate goal of the MitM is to convince the client that it is the legitimate NTP server so that it can feed the client false timing information, the only piece of information the MitM needs at this point in order to masquerade as the server is the cookie. The cookie is not easily readable by the MitM because it is run through a hash function to create the Autokey sequence and then through another hash function to create the MAC. Since hash functions are one-direction calculations, it would take a tremendous amount of effort to determine the cookie from the MAC.

However, the cookie is only 32 bits long. Knowing this, the MitM can use the information he’s already gathered through sniffing network traffic to forge NTP client requests for the current time. The MitM’s goal at this point is to keep sending forged client requests until he brute forces, or guesses

correctly through trial and error, the cookie sequence. It was estimated by my advisor that the process of brute forcing the cookie would only take about 10 minutes.

Once the attacker manages to determine the correct cookie sequence, the only thing left to do is to perform an ARP poisoning attack so that all requests aimed at the legitimate NTP server are instead directed at the attacker’s machine. There are many applications readily available on the web to perform ARP poisoning attacks, so this is not a particularly difficult feat. However, once the ARP poisoning attack is complete, the MitM is free to feed the NTP client whatever timing information he wants to and thereby wreck systems which rely on accurate time synchronization.

A diagram of this kind of attack is given below:

Stage 1:

During the initial planning stages of this project, our group decided that the project would be broken up into two distinct stages, Stage 1 and Stage 2. The objective of Stage 1 was to set up a testing environment in which we could later execute a MitM attack which demonstrated the security flaw in Authenticated NTP detailed previously.

I was responsible for planning out and completing Stage 1. My initial plan for Stage 1 involved establishing an NTP connection between two virtual machines and

then monitoring the NTP traffic passing between them using Wireshark, a packet sniffing program, installed on the host OS (see diagram at right).

My decision to use virtual machines for Stage 1 was influenced by three factors. First, I have had a great deal of experience setting up and using virtual machines in my previous internships, so I was confident in my ability to set Stage 1 up quickly. Second, I wanted to contain the project entirely within my laptop so that my partner and I could work on the project without having to worry about when the labs were open. Third, I knew from previous experience that virtual machines are very easy to manipulate and the ability to create snapshots of their current state would allow us to recover after errors far more quickly than if we had used separate computers for each of the elements in Stage 1.

To create the virtual machines and the virtual network which would bind Stage 1 together, I used a piece of software called VMWare. VMWare allows users to create virtual machines (VMs)from disk images and manage them with various tools and features. The most important management tool for our purposes was the snapshot tool, which allowed us to save the current state of the virtual machine and recover back to previous ones if an error arose. VMWare also provides the capability to set up virtual networks. Three default virtual networks are created by VMWare upon installation: a host-only network, a NAT network, and a bridged network. When a VM is created, the user can choose which virtual network to connect the VM to. VMWare will automatically create a virtual network adapter connecting the VM to the desired virtual network once the installation process is complete. VMWare also creates a virtual DHCP server for each of the three networks to assign IP addresses to all machines participating in each network.

In the VMWare documentation, it says that whenever a VM is connected to one of the three default virtual networks, the VM is automatically connected to the virtual switch assigned to that network. However, I figured out early on through researching VMWare that the virtual switch the documentation says it connects VMs to in reality operates like a virtual hub. This is because like a hub, this virtual switch automatically copies all incoming packets and sends a copy out to all of the machines connected to it. This is important to note since it plays a key role in the operation of Stage 1.

I chose to set up Stage 1 on the default NAT network since it was the only default network which would allow VM’s to have access to the external network and to the host OS. In the default bridged network, the host OS is not given a virtual network adapter, and so cannot be accessed by the VMs participating in the network. The host-only virtual network is also limited in that it cuts off VMs from the external network. Since NTP servers must receive timing information through a server chain leading back to a Stratum 1 server, the NTP server which I would set up had to have access to the external network. Bridged networking was rejected because I did not want to have to create more VM’s than necessary, so the default virtual NAT network was the only option left.

Once it was set up, Stage 1 would consist of two virtual machines and the host operating system. One of the virtual machines would run the NTP server application and receive timing information from an established NTP server at National University of Ireland Galway (NUIGalway) by accessing the external network through the NAT device. The second VM would be set up as an NTP client, and receive timing information from the other VM. Wireshark would then be installed on the host OS and would monitor all network traffic on the virtual network. The reason that Wireshark would be able to see all traffic on the virtual network is because the virtual hub at the center of the network

would copy every packet routed through it to the host OS, effectively allowing Wirehshark to “see” the traffic between the NTP client and the NTP server.

This setup would serve as a jumping off point for Stage 2 since, if Wireshark could indeed see all of the network traffic on the virtual network, then we could eventually replace Wireshark with a MitM-style attacker. The exploit described earlier only requires that the attacker be able to sniff the NTP packets travelling between the client and server and be able to inject packets into the network. If Wireshark could see the packets an attacker would want to sniff, then we could eventually replace Wireshark with the attacker.

Stage 2:

In Stage 2, our group would modify Stage 1 and demonstrate the Authenticated NTP exploit detailed in the “Authenticated NTP” section. Though we did not ultimately complete Stage 2, I researched how it could be achieved.

My plan was to download a piece of software called Scapy onto the host OS. Scapy is a program capable of packet sniffing as well as custom packet creation and injection. Users interact with Scapy through Python code, allowing the user to fine tune its functions. A python script could theoretically be written to perform all of the functions of the attacker, such as sniffing the NTP traffic between the client and server to pick up easily available information and crafting bogus requests in order to brute force the cookie. To perform the ARP poisoning attack following the determination of the cookie, another piece of open source software, Ettercap, could be used. Ettercap is a network security tool with a wide range of features for conducting MitM attacks on local area networks. One such feature allows users to quickly perform ARP poisoning attacks and thereby redirect network traffic destined for one machine to another.

Once the cookie was determined using Scapy and an ARP poisoning attack conducted using Ettercap, we could then use Scapy to feed the NTP false timing information. This would be achieved by crafting NTP packets using the public information determined earlier, the known Autokey hash functions, the cookie, and whatever NTP payload we chose. The client would then set its clock using the falsified timing information, marking the successful completion of the MitM attack.

Progress:

During the first week and a half of the project, Declan and I performed a great deal of research and I attempted to get Stage 1 up and running. Since Declan hadn’t been exposed to computer networking previously, I developed a list of topics in computer networking which he could investigate in order to help him understand our project. While he worked on that for the first week and a half, I took charge of planning how Stage 1 would work and planned out how I would set it up. I familiarized myself with VMWare, especially how the virtual networks it creates work, and did some preliminary research into how NTP works to inform my planning.

Once I had begun to set up Stage 1 however, I began to run into the bugs that would plague me for weeks afterwards. Many of these issues were resolved by learning how to add and modify rules in Fedora 19’s kernel firewall, known as iptables, and how to add exceptions to Windows Firewall. This research got me to the point where both of the Fedora 19 virtual machines I had set up were able to ping one another, and both of the VMs were able to ping the host OS.

The real trouble began when I attempted to set up an NTP server on one of the VMs. As previously mentioned, NTP has a hierarchical structure, meaning that all NTP servers are connected back to a Stratum 1 server through a chain of servers. My first attempts at synchronizing my server to an established NUIGalway NTP server did not succeed, forcing me to delve deeper into the NTP documentation. I spent a week learning how to diagnose NTP connections with the ntpq and ntpdate commands, but still could not figure out why I was unable to synchronize my server with the NUIG NTP server.

At this point, I called upon Michael Schukat for advice. He theorized that my NTP server was unable to receive replies from the NUIGalway NTP server because their NTP server existed outside the university firewall. The replies which the NUIGalway NTP server sent back to my server were being intercepted by the firewall. To fix this, Michael brought down a cellular router which would allow my laptop to connect to the internet over the local cellular network. This way, I could bypass the university firewall and contact the NUIG server directly.

The use of the cellular router allowed my server to successfully synchronize with the NUIG server after several days of trial and error. However, this was not a long-term solution since Michael had only purchased one gigabyte of data for the cellular router and I was fast approaching the limit during testing. Hugh Melvin stepped in at that point and set up an NTP server within the NUIG firewall with the hopes that I could synchronize with that over the NUIG campus wifi without worrying about the campus firewall.

Synchronization between my NTP server and Hugh’s NTP server did not occur over the next week of testing. Michael was away that week and Hugh Melvin had pressing matters to attend to so I was left to try to debug the issue myself. Several days of testing various NTP configuration file setups and trawling the internet for answers lead to an important discovery. Once I had begun to explore the various options which could be appended onto the ntpq and ntpdate commands, I discovered that I was able to retrieve the date from Hugh’s NTP by specifying that the request be sent over an unrestricted port. Any port number above 1024 is considered unrestricted and any port number below or including 1024 restricted. Since NTP normally sends requests from port 123, adding the –u option to the ntpdate command forced the request to be sent on an unrestricted port number, and for an unknown reason, that allowed me to retrieve the date. After consulting both Hugh Melvin and Professor Chuah about this, I was lead to believe that the issue lay somewhere in VMWare’s setup of the virtual network.

I studied the VMWare documentation and internet forums for several days but could not find an answer. I did however learn how the NAT device which allowed the VM’s to connect to the external network worked, and even learned how to add custom rules to the NAT device. When adding custom rules failed to produced results, I resigned to the fact that the VMWare documentation was not detailed enough for my purposes and that I would have to rethink how I was going to set up Stage 1.

My new plan for Stage 1 involved switching the roles of the VM’s and the host OS. Instead of trying to synchronize an NTP server on a VM to an NUIG NTP server, I decided instead to set up an NTP server on my host OS and then have one of the VM’s receive timing information from that. I had discovered that while the VM’s were having difficulty synchronizing to the NUIG NTP servers, my host OS was able to synchronize with Hugh’s server with no difficulty whatsoever. This finding in conjunction combined with the discovery of a piece of open source software which was supposed to fix time synchronization issues across NAT devices lead me to believe that this setup would work.

The role of the attacker would therefore be switched over to the second VM since it would be able to monitor all of the network traffic between the NTP client VM and the host OS just as easily as the host OS was able to monitor the traffic between the two VM’s. A diagram of this setup is included on the here:

After a two days of tweaking and troubleshooting, I managed to synchronize the NTP client VM with my host OS, and running Wireshark inside the second VM proved that it could indeed see the NTP traffic passing between the NTP client VM and the host OS. Stage 1 was now complete.

The setup of Stage 1 took until the 15th of July, leaving us with less than a week to work on Stage 2. With the remaining time, I researched what pieces of software would be necessary to complete Stage 2 and how to create custom network packets. I did not ultimately finish Stage 2, but I had a very firm idea by the end of how I would complete it.

As a final note on the work that I did this summer, I also took responsibility for planning out the final presentation which Declan and I gave to Michael Schukat and Hugh Melvin and wrote ten of the thirteen slides involved in the PowerPoint, including two explanatory diagrams.

Summary:

During the seven weeks spent working on this project, my partner and I put in a great deal of effort towards achieving our project objectives. Though we did not ultimately realize our goal of demonstrating a security flaw in Authenticated NTP, we made important gains in many areas. Both Declan and I learned a great deal about Network Time Protocol, computer networking, and various software tools during the course of the project. The long and arduous troubleshooting process I went through to complete Stage 1 left me with an in-depth understanding of how the NTP programs works, how VMWare’s virtual networks are set up, and how to diagnose network connection issues. In addition, I was also exposed to the inner workings of Authenticated NTP and planned out how our group would go about performing a MitM-style attack.

Thanks to all of the support we received from Michael Shukat, Hugh Melvin, and Professor Chuah, Declan and I were able to showcase a functional Stage 1 at the end of the summer and demonstrate a firm understanding of how the system worked. We have also left the project in such a way that it can be continued in the future by NUIGalway students. Future work on the project by such students will most likely include the completion of Stage 2, so though our time with the project has come to a close, the work that we have done will help to educate the computer science students which follow behind us.