New Vulnerabilities Identified in Network Time Protocol Daemon (NTPD)

Wednesday, April 29, 2015

Anthony M. Freed


The Network Time Foundation’s NTP Project has released updates addressing multiple vulnerabilities discovered in NTPD, where exploitation by an attacker could result in a man-in-the-middle attack or cause a denial of service condition.

NTP, the open source protocol that is used to synchronize system time over a network, is known to be widely used within Industrial Control Systems deployments, some of which are engaged in a variety of critical infrastructure operations.The NTPD reference implementation was found to accept unauthenticated packets with symmetric key cryptography, and does not protect symmetric associations against denial of service attacks.

As a result, an unauthenticated attacker with network access could inject packets or prevent peer synchronization among symmetrically authenticated hosts, according to US-CERT.

The first vulnerability mitigated by the new release (CVE-2015-1798) involves NTP4 installations utilizing symmetric key authentication (versions ntp-4.2.5p99 to ntp-4.2.8p1), wherein packets with no message authentication code (MAC) are accepted as though they have a valid MAC, which could allow an attacker to leverage the validation error to send packets that will be accepted by the client.

“When NTPD is configured to use a symmetric key with an NTP server/peer, it checks if the NTP message authentication code (MAC) in received packets is valid, but not if there actually is any MAC included. Packets without MAC are accepted as if they had a valid MAC. This allows a MITM attacker to send false packets that are accepted by the client/peer without having to know the symmetric key,” wrote Miroslav Lichvar, who disclosed the vulnerabilities.

“It seems this bug was introduced in 4.2.5p99 and is in all later stable versions up to 4.2.8p1. Authentication using autokey doesn’t have this problem as there is a check that requires the key ID to be larger than NTP_MAXKEY, which fails for packets without MAC.”

The second vulnerability addressed in the release (CVE-2015-1799) mitigates a flaw in NTP installations utilizing symmetric key authentication (xntp3.3wy to version ntp-4.2.8p1), resulting in a denial of service condition when two peering hosts receive packets where the originate and transmit timestamps do not match, allowing an attacker to periodically send packets to both hosts to prevent synchronization.

“According to the document the NTP authentication is supposed to protect symmetric associations against this attack, but that doesn’t seem to be the case. The state variables are updated even when authentication fails and the peers are sending packets with originate timestamps that don’t match the transmit timestamps on the receiving side,” Lichvar said.

“This seems to be a very old problem, it’s in the oldest ntp version I could find (xntp3.3wy). It’s also in the NTPv3 (RFC 1305) and NTPv4 (RFC 5905) specifications, so other NTP implementations with support for symmetric associations and authentication may be vulnerable too.”

The NTP Project has released version ntp-4.2.8p2 to address these issues.

Last December, the ICS-CERT issued an advisory regarding critical vulnerabilities discovered in NTP which could allow attackers with limited skills to remotely gain root access to systems, and active exploits for the flaws have been detected in the wild.

The vulnerability was detailed by Google Security Team researchers Neel Mehta and Stephen Roettger, who also documented several other flaws which included buffer overflows, as well as weak default keys and weak random number generator seeds, which were patched in version 4.2.8 released on the 18th of December.

Explanations of the vulnerabilities are provided here:

  • CWE-332: Insufficient Entropy in PRNG – CVE-2014-9293
  • CWE-338: Use of Cryptographically Weak Pseudo-Random Number Generator (PRNG) – CVE-2014-9294
  • CWE-121: Stack Buffer Overflow – CVE-2014-9295
  • CWE-389: Error Conditions, Return Values, Status Codes – CVE-2014-9296

This was cross-posted from the Dark Matters blog. 

Firewalls IDS/IDP Network Access Control Network->General SCADA
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.