When Network Clocks Attack

In October 2013, Cisco TRAC discussed Network Time Protocol (NTP) as a possible vector for amplified distributed denial of service (DDoS) attacks. Litnet CERT has since revealed that their NTP servers were used in a denial of service (DoS) attack. Symantec also published information regarding an NTP amplification-based DDoS attack that occurred in December 2013. On December 7, 2013, a hackforums.net user posted an NTP amplification DDoS script to Pastebin. The NTP DDoS script is heavily obfuscated Perl, though the plain text at the top credits the “leaking” of the script to an individual who goes by the handle Starfall. Brian Krebs also mentioned someone going by the name Starfall as a paying user of booter.tw. They may be the same person.

Decoding the obfuscated Perl yields some interesting insights. For example, this code near the top of the script has nothing to do with the NTP DDoS functionality:

The code above downloads a program called spoof.pl from IP 84.33.192.46, then runs and erases that program while writing the text “j00 g0t 0wn3d s0n” into a hidden file. Unfortunately, we were unable to obtain a copy of the spoof.pl script, but the ominous “j00 g0t 0wn3d s0n” text indicates the purpose of the program was likely to compromise the machine of anyone who was running the obfuscated NTP DDoS script. Is there no honor among hackers?

The remaining portion of the de-obfuscated Perl script contains an array of 220 vulnerable NTP servers that are used for amplification-based DDoS. After searching on pieces of the script’s de-obfuscated source, we found other versions of the NTP DDoS script which lacked the “j00 g0t 0wn3d s0n” code, but instead were bundled with code for an IRC client that connects to a server and listens for DDoS commands. In one primitive version of the IRC-based NTP DDoS script that predates the December 7 Pastebin entry, the IRC server setting is “666.0×01-security.com”. In a more recent version of the IRC-based NTP DDoS script containing 336 vulnerable NTP devices, the server setting is IP 193.0.202.101. According to passive DNS, the “666.0×01-security.com” domain has been previously hosted on both IP 84.33.192.46 (the home of spoof.pl in the code above), and IP 193.0.202.101 (currently live at this address). If the user Starfall was indeed responsible for the creation of the obfuscated version of the Perl NTP DDoS script as we believe, then that same individual also appears to be controlling the domain 0x01-security.com for their own nefarious purposes and is also very interested in DDoS attacks.

Fortunately for network defenders, most of the time the evidence necessary for spotting/confirming malicious domains exists in plain view inside Passive DNS. For example, for most of its useful life the bare domain 0x01-security.com has possessed a CNAME record which points to google.com. This means that any email directed at this domain will be handled by google.com Mail Exchangers (MXs). According to TRAC’s own testing, Google’s mail servers have never heard of anyone at the domain 0x01-security.com. Surely, any legitimate domain would want to receive its email, and a “misconfiguration” such as this lasting for months is suspicious. Additionally, most legitimate domains would have no need to point the DNS A records for their host to 127.0.0.1 (a.k.a. localhost). However, that is exactly what the 666.0×01-security.com host did for a period on December 30, 2013.

So, what can we take away from all this?

The NTP amplification-based DDoS attacks predicted by TRAC back in October have become a reality. Script kiddies are currently distributing attack tools that utilize an increasing number of vulnerable NTP servers. To be sure, you do not become an unwitting participant in a DoS attack; network administrators are encouraged to upgrade their public facing NTP servers to NTP version 4.2.7 which eliminates support for the monlist command. If upgrading is not an option, then using the noquery option in the NTP configuration will prevent monlist queries. To find out if your NTP server is vulnerable, TRAC highly recommends visiting the team over at openntpproject.org.