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)