Over the past few months the Internet has seen increased DDoS (distributed denial of service attack) activity which started with DNS amplification attacks and then moved onto NTP amplification attacks. For now the DDoS attacks have stopped, however it’s only a matter of time before the next DDoS attack method is discovered. It’s an ongoing effort for administrators to keep servers patched to prevent these type of exploits. The last one I found myself dealing with was the NTP monlist amplification attack, which used several customers NTP (Network Time Protocol) servers that were available to the public internet. One vulnerable NTP server was generating ~500 mpbs of outbound traffic before we shut its access down.
A DDoS is a distributed denial of service attack in which several computers are configured to flood data to a target. The target’s internet connection can become over saturated disrupting the target’s Internet connection. This in affect can take down any Internet server for the length of the attack. There are several types of DDoS attacks, one of them being a NTP amplification DDoS attack. The latest NTP DDoS attack method allows remote users to trick an Internet facing server running NTP to flood data to a target without having access to the NTP server. These attacks can be kicked off easily and are very hard to trace to the original source of the attack.
By using the NTP monlist command to query an exploitable NTP server’s last 600 associations, an attacker can send a small amount of data to the exploitable NTP server and get back a response back that is several times larger than the original request. When the NTP monlist command is used as intended, it will cause no harm, however when the source IP address is spoofed it can be used for denial of service attacks. If an attacker spoofs the source IP in there NTP monlist request, the response is sent to spoofed IP address. Using a script to repeat the NTP monlist command to an exploitable server, the attacker can generate a very large amount of traffic and target it where they want. Kicking off this type of DDoS requires a small amount of Internet bandwidth and could generate a flood of data hundreds of times larger than the original monlist request. If an attacker is able to identify an exploitable NTP server that has access to a lot of bandwidth, that would be a prime candidate of a large NTP amplification attack. An attacker could use several servers around the internet to query the NTP monlist against an exploitable NTP server with access to a large amount of bandwidth.
Basic NTP Amplification Attack flow
- Attacker at IP 60.70.80.90 sends .5 mbps worth of NTP monlist requests, spoofs source IP as IP 123.123.123.1 to exploitable NTP Server.
- The exploitable NTP Server responds with 15 mbps of response data to Target at IP 123.123.123.1 not the attacker who is at 60.70.80.90
- The Targets ingress bandwidth is 10 mbps, they are not unable to use their internet connection due to over saturation from the NTP monlist flood running at 15 mbps
- Attacker is only using half of their available upload to completely take the target offline.
- This example would be a ntp amplification attack of 30 times the original data sent
- Repeat this process with several different client and NTP servers and you now have a NTP amplification DDoS attack.
I set up a lab example of an NTP server running with monlist enabled and used ntpdc to issue the monlist command. The request was 234 Bytes and the response generated back was 2676 Bytes, in this example it would be possible to amplify 11 times the original size of the request sent to the server. My test server had 33 NTP associations, while the max that the monlist will respond with is 600. With 600 associations, a much larger response with the same 234 Byte request is possible. Below is a screen shot of a wire shark packet capture that shows the monlist request and response data.
The response from the monlist request was 6 UDP packets, 5 that were 482 Bytes and the last one was 266 Bytes. If you add up the number of total bytes in those 6 packets the total is 2676 Bytes.
If an attacker spoofs the source address in the NTP monlist request, the returned data is sent to a different server. If the attacker continues to make this request with a spoofed IP address, the NTP server will keep sending the response to the victims’ computer. This amplification attack was recorded as CVE-2013-5211 in the middle of January 2014. A lot of these attacks could have been prevented if all internet providers implemented BCP38. BCP38 is also known as RFC 2827 was actually written up almost 14 years ago. It’s a best current Practice that recommends filtering traffic that should never been seen from a user. This would for example drop any traffic with a spoofed source IP address that is not in the valid range provided to the user. DataYard implements this using a combination Cisco ACLs and Cisco Unicast Reverse Path Forwarding.
How to see if your Server is vulnerable?
- There is an open project that was started to help identify vulnerable NTP servers, you could have your public address range scanned as long as it’s smaller than a /22 (1024 Block size).
- http://openntpproject.org/
- You can use ntpdc in linux and issue the monlist command to see if you get a response.
- NMAP has a useful script that can be used to see if a server is responding to the monlist ntp request as well.
nmap -sU -p U:123 -n -Pn –script ntp-monlist 192.168.1.0/24
| Target is synchronised with xx.yy.61.67
| Public Servers (1)
| xx.yy.61.67
| Public Clients (1)
| xx.yy.177.51
| Other Associations (13)
| xx.yy.100.2 (You?) seen 5 times. last tx was unicast v2 mode 7
| 127.0.0.1 seen 78664 times. last tx was unicast v0 mode 0
| xx.yy.177.108 seen 4 times. last tx was unicast v2 mode 7
| xx.yy.129.66 seen 1 time. last tx was unicast v2 mode 7
| xx.yy.203.115 seen 7 times. last tx was unicast v2 mode 7
| xx.yy.95.174 seen 1 time. last tx was unicast v2 mode 7
| xx.yy.253.2 seen 3 times. last tx was unicast v2 mode 7
| xx.yy.54.31 seen 1 time. last tx was unicast v2 mode 7
| xx.yy.177.66 seen 3 times. last tx was unicast v2 mode 7
| xx.yy.81.113 seen 1 time. last tx was unicast v2 mode 7
| xx.yy.54.103 seen 2 times. last tx was unicast v2 mode 7
| xx.yy.244.49 seen 1 time. last tx was unicast v2 mode 7
| xx.yy.230.75 seen 1 time. last tx was unicast v2 mode 7
Please Patch your NTP server!
There are still many unpatched NTP servers out on the internet that can be used in future DDoS. If your NTP server is responding to the ntp monlist command, you should upgrade to a later version of ntp. If you not able to upgrade your ntpd process there are several examples online that show how to lock down or even complete disable the monlist command.
