Which NTP Servers do You Need to Patch?
(Also see our earlier diary about this vulnerability)
While people generally know where their "real" NTP servers are, all to often they don't know that they've got a raft of "accidental" NTP servers - boxes that have NTP enabled without the system maintainers knowing about it. Common servers on the network like routers or switches (often when these are NTP clients, they are also NTP servers), PBX's and VOIP gateways, mail servers, certificate authorities and so on.
In these days of auto-updates, you would think that most NTP servers would be patched against the vulnerabilities found by the Google team and described in story written up by Johannes earlier this evening.
However, it only took until the second host checked to find a very out of date server. Unfortunately, it's the main NTP server of a large Canadian ISP (Oops). What I also found along the way was that many servers only report "4" as a version, and that from the -sV switch, not from ntp-info. So depending on your internal servers and how they are configured, it may be time for us to start using authenticated scans using tools like Nessus to get service versions for our NTP servers. Hopefully that's the practice for other services already.
Note that the IP addresses in these scans are obfuscated
C:\> nmap -sU -pU:123 -sV ntp.someisp.ca --script=ntp-info.nse
Starting Nmap 6.47 ( http://nmap.org ) at 2014-12-19 21:44 Eastern Standard Time
Nmap scan report for ntp.someisp.ca (x.x.x.x)
Host is up (0.0045s latency).
rDNS record for x.x.x.x: khronos.tor.someisp.ca
PORT STATE SERVICE VERSION
123/udp open ntp NTP v4
| ntp-info:
| receive time stamp: 2014-12-20T02:47:52
| version: ntpd 4.1.1c-rc1@1.836 Thu Feb 13 12:17:19 EST 2003 (1)
| processor: i686
| system: Linux2.4.20-8smp
| leap: 0
| stratum: 3
| precision: -17
| rootdelay: 11.079
| rootdispersion: 33.570
| peer: 32471
| refid: x.x.x.x
| reftime: 0xd83f5fad.b46b9c30
| poll: 10
| clock: 0xd83f61d5.3a71ef30
| state: 4
| offset: -0.329
| frequency: 46.365
| jitter: 3.468
|_ stability: 0.004
Service detection performed. Please report any incorrect results at http://nmap.
org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 180.08 seconds
This server on the other hand, doesn't report the version in the ntp-info output. "-sV" reports version 4, but that's all we get.
C:\ >nmap -sU -pU:123 -sV time.someotherserver.com --script=ntp-info.nse
Starting Nmap 6.47 ( http://nmap.org ) at 2014-12-19 22:17 Eastern Standard Time
Nmap scan report for time.someotherserver.com (y.y.y.y)
Host is up (0.010s latency).
PORT STATE SERVICE VERSION
123/udp open ntp NTP v4
| ntp-info:
|_ receive time stamp: 2014-12-20T03:19:39
Service detection performed. Please report any incorrect results at http://nmap.
org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 143.24 seconds
But really, after this year of vulnerabilties that we've seen in basic system services, it's about time that folks took the "SANS Top 20" to heart - the SANS Critical Controls that you really should be looking at if it's your goal to secure your network - https://www.sans.org/critical-security-controls . The top 5 in the list sum up your first line of defense against stuff like this. Know what's on your network, know what's running on that, have a formal program of patches and updates, and scan regularly for new hosts, new services and new vulnerabilities. If it's your thought that a single scan for this one vulnerability is the most important thing on your plate (or scanning for heartbleed or shellshock was earlier this year), then you have already lost - it's time to review the SANS Critical Controls and revamp your IT and Security Operations.
Quick Addendum/Update (Johannes):
CentOS and other Linux distros did release updates. However, the version string may not change. Check the "Build Date". For example, on CentOS 6:
Before patch: ntpd 4.2.6p5@1.2349-o Sat Nov 23 18:21:48 UTC 2013 (1)
After patch: ntpd 4.2.6p5@1.2349-o Sat Dec 20 02:53:39 UTC 2014 (1)
===============
Rob VandenBrink
Metafore
Critical #NTP Vulnerability in ntpd prior to 4.2.8
The Google security team discovered several vulnerabilities in current NTP implementations, one of which can lead to arbitrary code execution [1][2]. NTP servers prior to version 4.2.8 are affected.
There are some rumors about active exploitation of at least some of the vulnerabilities Google discovered.
Make sure to patch all publicly reachable NTP implementations as fast as possible.
Mitigating Circumstances:
Try to block inbound connections to ntp servers who do not have to be publicly reachable. However, be aware that simple statefull firewalls may not track UDP connections correctly and will allow access to internal NTP servers from any external IP if the NTP server recently established an outbound connection.
ntpd typically does not have to run as root. Most Unix/Linux versions will configure NTP using a lower privileged users.
According to the advisory at ntp.org, you can also:
Disable Autokey Authentication by removing, or commenting out, all configuration directives beginning with the crypto keyword in your ntp.conf file.
A few Ubuntu and CentOS systems I tested, as well as OS X systems, do not seem to use autokey.
[1] http://www.kb.cert.org/vuls/id/852879
[2] http://support.ntp.org/bin/view/Main/SecurityNotice
CVE | Impact | Details |
CVE-2014-9293 | authentication | ntp will create a weak key if none is provided in the configuration file. |
CVE-2014-9294 | authentication | ntp-keygen uses a weak seed to create random keys |
CVE-2014-9295 | remote code execution | A remote attacker can send a carefully crafted packet that can overflow a stack buffer and potentially allow malicious code to be executed with the privilege level of the ntpd process. |
CVE-2014-9296 | missing error message | In the NTP code, a section of code is missing a return, and the resulting error indicates processing did not stop. |
Comments