Part 2: Is your home network unwittingly contributing to NTP DDOS attacks?
This diary follows from Part 1, published on Sunday August 17, 2014.
How is it possible that with no port forwarding enabled through the firewall that Internet originated NTP requests were getting past the firewall to the misconfigured NTP server?
The reason why these packets are passing the firewall is because the manufacturer of the gateway router, in this case Pace, implemented full-cone NAT as an alternative to UPnP.
What is full-cone NAT?
The secret is in these settings in the gateway router:
If strict UDP Session Control were enabled the firewall would treat outbound UDP transactions as I described earlier. When a device on your network initiates an outbound connection to a server responses from that server are permitted back into your network. Since UDP is stateless most firewalls simulate state with a timeout. In other words if no traffic is seen between the device and the server for 600 seconds then don??t permit any response from the server until there is new outbound traffic. But anytime related traffic is seen on the correct port the timer is reset to 600 seconds, thus making it possible for this communication to be able to continue virtually forever as long as one or both devices continue to communicate. Visually that looks like:
However if UDP Session Control is disabled, as it is in this device, then this device implements full-cone NAT (RFC 3489). Full-cone NAT allows any external host to use the inbound window opened by the outbound traffic until the timer expires.
Remember anytime traffic is seen on the correct port the timer is reset to 600 seconds, thus making it possible for this communication to be able to continue virtually forever as long as one or both devices continue to communicate.
The really quick among you will have realized that this is not normally a big problem since the only port exposed is the original ephemeral source port and it is waiting for a NTP reply. It is not likely to be used as an NTP reflector. But the design of the NTP protocol can contribute to this problem.
Symmetric Mode NTP
There is a mode of NTP called symmetric NTP in which, instead of the originating device picking an ephemeral port for the outbound connection, both the source and the destination ports use 123. The traffic flow would look like:
Symmetric NTP opens up the misconfigured server to be an NTP reflector. Assuming there is an NTP server running on the originating machine on UDP port 123, if an attacker can find this open NTP port before the timeout window closes they can send in NTP queries which will pass the firewall and will be answered by the NTP server. If the source IP address is spoofed the replies will not go back to the attacker, but will go to a victim instead.
Of course UDP is stateless so the source IP can be spoofed and there is no way for the receiver of the NTP request to validate the source IP or source port permitting the attacker to direct the attack against any IP and port on the Internet. It is exceedingly difficult to trace these attacks back to the source so the misconfigured server behind the full-cone NAT will get the blame. As long as the attacker sends at least one packet every 600 seconds he can hold the session open virtually forever and use this device to wreak havoc on unsuspecting victims. We have seen indications of the attackers holding holding these communications open for months.
What are the lessons to be learned here:
- If all ISPs fully implemented anti-spoofing filters then the likelihood of this sort of attack is lowered substantially. In a nutshell anti-spoofing says that if the traffic is headed into my network and the source IP address is from my network then the source IP must be spoofed, so drop the packet. It also works in the converse. If a packet is leaving my network and the source IP address is not an IP address from my network then the source IP address must be spoofed, so drop the packet.
- It can't hurt to check your network for NTP servers. A single nmap command will quickly confirm if any are open on your network. nmap -sU -A -n -PN -pU:123 --script=ntp-monlist
. If you find one or more perhaps you can contact the vendor for possible resolution. - If you own a gateway router that implements full-cone NAT you may want to see if your gateway router implements the equivalent of the Pace ??Strict UDP Session Control?. This will prevent an attacker from access misconfigured UDP servers on your network.
-- Rick Wanner - rwanner at isc dot sans dot edu- http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)
Part 1: Is your home network unwittingly contributing to NTP DDOS attacks?
For the last year or so, I have been investigating UDP DDOS attacks. In this diary I would like to spotlight a somewhat surprising scenario where a manufacturer??s misconfiguration on a popular consumer device combined with a design decision in a home gateway router may make you an unwitting accomplice in amplified NTP reflection DDOS attacks.
This is part 1 of the story. I will publish the conclusion Tuesday August 19th.
Background
Today almost every house has consumer broadband services. Typical broadband installations will have a device, usually provided by your service provider, which acts as a modem, a router and a firewall (for the rest of the diary this device will be called a gateway router). In a nutshell the firewall in the gateway router permits network traffic initiated on your network out to the Internet, and permits responses to that traffic back into your network. Most importantly the firewall will block all traffic destined for your network which is not a response to traffic initiated from your network. This level of firewall capability meets the requirements of almost all broadband consumers on the Internet today.
For those of us power users who required more capability, gateway router manufacturers tended to support a port forwarding feature that would allow us to accommodate servers and other devices behind the firewall. This was great for us tech-savvy folk, but typically port forwarding was beyond the understanding of the average Internet user like my Dad (sorry Dad!) or my Grandma.
In the last few years consumer devices that plug into your home network and use more complicated networking, that does not fit the standard initiate-respond model, have become more common. The most common of those is gaming consoles, but other devices like home automation, storage devices and others can also be an issue. As stated above setting up port forwarding so these devices will function properly is beyond the average Internet users?? capability. Luckily the gateway router vendors have thought of that as well.
To simplify connecting these devices, gateway router vendors tend to implement one of two ways of supporting these devices. Most support Universal Plug and Play (UPnP) with a minority of vendors supporting Full-cone NAT.
Investigation
It begins with a complaint from a reputable source that a customer is participating in a reflective NTP DDOS attack utilizing monlist for amplification.
The complaint is against XXX.160.28.174, a dynamic address broadband customer. The analyst??s first thought is that this is a tech-savvy user has setup a NTP server and added port forwarding to their router. It should be easy to resolve. Contact the customer and tell him to patch his NTP server to the current version and everything will be great! Unfortunately, this is where things go sideways.
While network monitoring clearly shows this customer??s connection participating in a NTP DDOS attack:
Review of the firewall configuration showed that there are no ports forwarded on the firewall.
But the NAT logs in the firewall show a large number of outbound connections to various addresses originating from this device and most of them don??t appear to be to NTP servers.
172.16.1.64:123, f: 192.75.12.11:123, n: XXX.160.28.174:123
172.16.1.64:123, f: 199.182.221.110:123, n: XXX.160.28.174:123
172.16.1.64:123, f: 142.137.247.109:123, n: XXX.160.28.174:123
172.16.1.64:123, f: 129.128.5.211:123, n: XXX.160.28.174:123
172.16.1.64:123, f: 206.108.0.132:123, n: XXX.160.28.174:123
172.16.1.64:123, f: 94.185.82.194:443, n: XXX.160.28.174:123
172.16.1.64:123, f: 60.226.113.100:80, n: XXX.160.28.174:123
172.16.1.64:123, f: 204.83.20.117:24572, n: XXX.160.28.174:123
172.16.1.64:123, f: 204.83.20.117:38553, n: XXX.160.28.174:123
172.16.1.64:123, f: 204.83.20.117:24572, n: XXX.160.28.174:123
172.16.1.64:123, f: 204.83.20.117:47782, n: XXX.160.28.174:123
172.16.1.64:123, f: 204.83.20.117:53177, n: XXX.160.28.174:123
172.16.1.64:123, f: 204.83.20.117:43397, n: XXX.160.28.174:123
172.16.1.64:123, f: 204.83.20.117:15673, n: XXX.160.28.174:123
172.16.1.64:123, f: 204.83.20.117:17275, n: XXX.160.28.174:123
172.16.1.64:123, f: 204.83.20.117:63467, n: XXX.160.28.174:123
172.16.1.64:123, f: 204.83.20.117:56970, n: XXX.160.28.174:123
172.16.1.64:123, f: 204.83.20.117:64682, n: XXX.160.28.174:123
172.16.1.64:123, f: 204.83.20.117:26332, n: XXX.160.28.174:123
172.16.1.64:123, f: 101.166.182.210:80, n: XXX.160.28.174:123
According to the NAT table, the address behind the gateway router that is initiating the outbound UDP sessions is at 172.16.1.64. The device table shows it as:
Name: home-controller-300-000FFF13C150
Hardware Address: 00:0f:ff:13:c1:50
That MAC address is owned by a company called Control4 who makes popular home automation devices. It is clear that the Control4 device has a configuration problem. There is likely no reason for Control4 to be running an NTP server on a home automation device, and certainly that NTP server should not support the monlist command. Most likely this a result of the Linux/Unix difficulty that when you implement an NTP client on a *nix platform you almost always wind up with an NTP server getting enabled as well which you need to manually disable. Either way, I was in contact with Control4, and they were aware of the issue and have released a patch and any Control4 devices that call home to the mothership should be resolved. Unfortunately they have a significant number of devices that, for some reason, don't call home and can't be patched until they do. But this is not just a Control4 problem. In the course of my investigation I found Macintosh computers, FreeNAS devices, Dell Servers and Dlink Storage devices displaying the same behavior. But even if there is a misconfigured NTP server on these networks, if the firewall is working properly, then no uninitiated connections should be permitted into these, and these devices should not be capable of being used as a reflector.
An nmap scan shows that not only is it possible to connect through the firewall, but that there is clearly an NTP server answering queries and that permits the monlist command, maximizing the amplification.
123/udp open ntp NTP v4
| ntp-monlist:
| Target is synchronised with 206.108.0.133
| Alternative Target Interfaces:
| 172.16.1.64
| Public Servers (4)
| 142.137.247.109 174.142.10.100 198.27.76.239 206.108.0.133
| Other Associations (166)
| 24.220.174.96 seen 7615 times. last tx was unicast v2 mode 7
| 193.25.121.1 seen 2084 times. last tx was unicast v2 mode 7
| 66.26.0.192 seen 406 times. last tx was unicast v2 mode 7
| 109.200.131.2 seen 11079 times. last tx was unicast v2 mode 7
| 79.88.149.109 seen 15356 times. last tx was unicast v2 mode 7
| 66.176.8.42 seen 90397 times. last tx was unicast v2 mode 7
| 84.227.75.171 seen 58970 times. last tx was unicast v2 mode 7
| 82.35.229.219 seen 952 times. last tx was unicast v2 mode 7
| 96.20.156.186 seen 2123 times. last tx was unicast v2 mode 7
| 216.188.239.159 seen 178 times. last tx was unicast v2 mode 7
| 184.171.166.72 seen 923 times. last tx was unicast v2 mode 7
| 94.23.230.186 seen 96 times. last tx was unicast v2 mode 7
? total of 166 entries
This is where I will end the story for now. What do you think is happening? Conclusion Tuesday August 19th.
-- Rick Wanner - rwanner at isc dot sans dot edu- http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)
Comments