Information Security News
Before we get into this here is the standard disclaimer. Do not scan any devices that you do not have explicit permission to scan. If you do not own the devices I strongly recommend you get that permission in writing. Also, port scanning may cause instability or failure of some devices and/or applications. Just ask anyone who lost ILOs to heartbleed. So be careful!
As we have seen in past diaries about reflective DDOS attacks they are certainly the flavor of the day. US-CERT claims there are several UDP based protocols that are potential attack vectors. In my experience the most prevalent ones are DNS, NTP, SNMP, and CharGEN. Assuming you have permission; Is there an easy way to do good data gathering for these ports on your network? Yes, as a matter of a fact it can be done in one simple nmap command.
nmap âsU âA âPN ân âpU:19,53,123,161 âscript=ntp-monlist,dns-recursion,snmp-sysdescr <target>
Letâs break this down:
-sU âperform a UDP scan. Since all the services above are UDP I only need to scan for the UDP ports.
-A -perform operating system and application version detection. This will attempt to give you more information about what applications are running on the open ports. The -A option also includes operating system detection, but it is unlikely that operating system detection will work when scanning this few ports.
-PN âscan even if you canât contact the IP. By default nmap will not scan any device it canât contact. Unfortunately if a device is hidden behind a firewall nmap will not usually be able to detect the device and will omit it from the detailed scan. A downside of using âPN is that nmap will complete the detailed scan against the IP even if it doesnât exist or no ports are open. If you are scanning a large number of IPs the scan will take a long time.
-n âdonât do a DNS resolution. By default nmap performs a DNS resolution. Not doing that resolution will speed up the scan somewhat.
-pU:19,53,123,161 âscan UDP ports specified. In nmap ââpâ is used to indicate which ports to scan. The âUâ tells nmap that the ports that follow are UDP ports. Since this scan is only scanning UDP ports (âsU) the âUâ is redundant. However over the years I have gotten into the habit of explicitly specifying which type of ports I want to scan unless I want to add some TCP ports (-pT:) to the scan at a later time.
The ports specified in this scan are:
âscript=ntp-monlist,dns-recursion,snmp-sysdescr â the âscript= option enables the nmap scripting engine (NSE) and runs scripts when they make sense to run. In other words, the ntp-monlist script will only be run when the NTP port is found to be open. nmap has many scripts available which can be used to extend nmaps basic functionality.
The scripts specified on this scan are:
123/udp open ntp NTP v4
If the monlist command is enabled on the ntp server, the ntp-monlist script will give you more information:
123/udp open ntp NTP v4
| Target is synchronised with 220.127.116.11
| Alternative Target Interfaces:
| Public Servers (4)
| XXX.87.64.125 XXX.75.12.11 XXX.108.0.131
| Other Associations (596)
53/udp open domain Microsoft DNS 6.1.7600 (1DB04228)
|_ bind.version: Microsoft DNS 6.1.7600 (1DB04228)
|_dns-recursion: Recursion appears to be enabled
161/udp open snmp SNMPv1 server (public)
161/udp open|filtered snmp
161/udp open snmp SNMPv1 server (public)
| snmp-sysdescr: Apple AirPort - Apple Inc., 2006-2012. All rights Reserved.
|_ System uptime: 9 days, 20:15:36.56 (85053656 timeticks)
Want to take a guess at what these devices are?
As you can see nmap provides a simple and effective way of scanning for the common ports used in reflective DDOS attacks. This diary has barely scratched the surface of nmapâs capabilities.
I would be interested to know if any of you have ways to enhance or improve this scan.
-- Rick Wanner - rwanner at isc dot sans dot edu - http://namedeplume.blogspot.com/ - Twitter:namedeplume (Protected)(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Many ISPs manage user's modems, be it DSL or Cable. Even if the ISP doesn't own the modem, they typically push configuration or firmware updates to the modem to keep it up to date and connected to their network. Overall, this isn't a bad idea. Keeping the firmware and configuration up to date would be rather difficult to end users. However, as some users have experienced with Comcast, these changes are not always in the customer's best interest.
For example, if you do use a Comcast provided modem with Comcast's "Business Class" access, your modem will be assigned a set of static IP addresses, but in addition, you will also receive a DHCP assigned address. This address isn't really used for any of your traffic. But, the address is reachable, and the modem's configuration screen is accessible via http (port 80/tcp) if someone connects to the address. The default (and widely known) password doesn't appear to work to log in in this case, but any bugs present in the configuration may be exposed. It wouldn't be the first time that a web based admin interface includes an authentication bypass vulnerability.
Luckily, the "dynamic" IP address that exposes the admin screen does not appear to be derived from the static address assigned to you by Comcast. So an attacker would have to scan all of Comcast's address space and would have no simple way to figure out who owns which dynamic address.
If you want to be a bit more secure, you can try and change the password from the default. However, be aware: As soon as the firmware is updated again, your new password will no longer work, neither will the default password. You will need to call Comcast support to have them reset the password.
Secondly, Comcast apparently started to enable public WiFi hotspots on cable modems that support the feature. In addition to charging users a rental fee for the modem, Comcast went ahead and turned the modems into public hotspots that can be used by other Comcast customers who happen to be in the area.
To turn off the public WiFi feature, you will need to connect to the Comcast customer portal (http://customer.comcast.com) and need to remove the option. After logging in, find the "Users & Preferences" option at the top of the screen
Then, find the "Manage Wifi" link (very small font, just below your address)
It is also a good idea to not use the default LAN IP range (e.g. 192.168.100.0/24 or 192.168.1.0/24). Instead, pick your own "random" range within RFC1918 space.