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.
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.¬†¬†
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: 22.214.171.124:123, 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:
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
| ¬† Target is synchronised with 126.96.36.199
| ¬† Alternative Target Interfaces:
| ¬† ¬† ¬† 172.16.1.64¬† ¬† ¬†
| ¬† Public Servers (4)
| ¬† ¬† ¬† 188.8.131.52 184.108.40.206¬† 220.127.116.11 ¬† 18.104.22.168¬† ¬†
| ¬† Other Associations (166)
| ¬† ¬† ¬† 22.214.171.124 seen 7615 times. last tx was unicast v2 mode 7
| ¬† ¬† ¬† 126.96.36.199 seen 2084 times. last tx was unicast v2 mode 7
| ¬† ¬† ¬† 188.8.131.52 seen 406 times. last tx was unicast v2 mode 7
| ¬† ¬† ¬† 184.108.40.206 seen 11079 times. last tx was unicast v2 mode 7
| ¬† ¬† ¬† 220.127.116.11 seen 15356 times. last tx was unicast v2 mode 7
| ¬† ¬† ¬† 18.104.22.168 seen 90397 times. last tx was unicast v2 mode 7
| ¬† ¬† ¬† 22.214.171.124 seen 58970 times. last tx was unicast v2 mode 7
| ¬† ¬† ¬† 126.96.36.199 seen 952 times. last tx was unicast v2 mode 7
| ¬† ¬† ¬† 188.8.131.52 seen 2123 times. last tx was unicast v2 mode 7
| ¬† ¬† ¬† 184.108.40.206 seen 178 times. last tx was unicast v2 mode 7
| ¬† ¬† ¬† 220.127.116.11 seen 923 times. last tx was unicast v2 mode 7
| ¬† ¬† ¬† 18.104.22.168 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)
Aug 17th 2014
|Thread locked Subscribe||
Aug 17th 2014
7 years ago
It doesn't help that NTP is using UDP, and can be easily spoofed. Honestly, I think UDP should be abolished for internet-based connections, and only allowed for internal LANs.
Aug 17th 2014
7 years ago
Quoting Anonymous:It doesn't help that NTP is using UDP, and can be easily spoofed. Honestly, I think UDP should be abolished for internet-based connections, and only allowed for internal LANs.
And after UDP, you're going to abolish ICMP ? and anything not TCP ?
The problem here does NOT lie with the UDP protocol but with the unwillingness of the ISPs to properly and completely implement anti-spoofing.
If customers cannot send out packets that have a source IP addresses different from those routed to them by the ISP, there's no more spoofing. Any and every protocol will be equally ok.
I'll leave a bit of an opening for an inability next to the unwillingness, but they can dictate requirements on their vendors, so it's rather moot.
So, how can we twist their hand ? Demand they fully implement BCP38 in any tender you write. Test that they do implement it properly in order to remain your supplier, ... unless the market demands it it'll never become their problem, so that they finally fix this.
Do it before you're the next victim ...
Aug 17th 2014
7 years ago