Feb 01,2010

NMAP 5.21 – Is UDP Protocol Specific Scanning Important? Why Should I Care?, (Mon, Feb 1st)

Before we address the question, let’s discuss how UDP port scanning is typically done.
When a host receives a UDP packet, what is supposed to happen is that if the host isn’t listening on that port, it should reply with a ICMPPort Unreachable (ICMPType 3, Code 3). If it is listening on that port, the packet contents are fed to the listening application and processed. If the application does not understand the packet contents, it might reply with an error, but most likely will drop the packet and not reply at all.

If there is any kind of a firewall involved, either on the host itself or in the network path, then quite often no reply at all will be received for the sent packet.

So an open port and a port protected by a firewall will often look the same to a scanner. This can be a real problem when scanning UDP ports, as ports listening with a running service will look exactly like firewalled ports, which of course do not have a service available to the scanning station.

What UDP Protocol Awareness brings is a better payload. With protocol awareness, a scan of the UDPDNS port for instance (udp/53), might be a an actual dns request. A scan of an NTP (network time protocol) port could be an NTP timestamp or time request. The application receives a valid packet, and if there is a listening port, a valid response is sent back to the scanner, and the scanner can now know for certain that this port is open!

To illustrate – first, let’s scan an NTP (Network Time Protocol) server’s NTP port with an older version of Nmap (5.0). This behaviour is typical of most port sc

C: nmap -sU -p123 192.168.122.254

Starting Nmap 5.00 ( http://nmap.org ) at 2010-01-28 13:17 Eastern Standard Time

Interesting ports on 192.168.122.254:

PORT STATE SERVICE

123/udp open|filtered ntp

MAC Address: 00:17:0E:0C:B7:61 (Cisco Systems)

Nmap done: 1 IP address (1 host up) scanned in 1.91 seconds

As you can see, the port shows as open/filtered. From the packet trace below, you can see that an emtpy packet is sent to udp/123, no valid NTP data is contained, and the NTP server simply drops the packet. There really is an NTPserver running, but there’s no way to tell for sure using this method of scanning.

Now let’s run the same scan with Nmap 5.2, which has UDPprotocol awareness.

C:nmap -sU -p 123 192.168.122.254

Starting Nmap 5.20 ( http://nmap.org ) at 2010-01-21 22:15 Eastern Standard Time

Nmap scan report for 192.168.122.254

Host is up (0.0019s latency).

PORT STATE SERVICE

123/udp open ntp

MAC Address: 00:17:0E:0C:B7:61 (Cisco Systems)

Nmap done: 1 IP address (1 host up) scanned in 6.88 seconds

The difference is immediately apparent, the port now has a state of open, instead of open/filtered. Let’s take a look at the packet and see exactly why ..

As you can see, Nmap is sending an actual NTP client timestamp of the NTP server, and it gets an NTP server response back. This identifies both the fact that the host is actually listening on that port, as well as the fact that it’s an actual NTP service that’s listening.

Currently NMAP 5.21 supports protocol specific payloads for:

udp/7 echo

udp/53 domain

udp/111 rpcbind

udp/123 ntp

udp/137 netbios-ns

udp/161 SNMP

udp/177 xdmcp

udp/500 ISAKMP

udp/520 route

udp/1645 and udp/1812 RADIUS

udp/2049 NFS

udp/5353 zeroconf

udp/10080 amanda

This is an exciting development, allowing us to scan these particular ports with a LOT more accuracy than previously possible. Again, Fyodor and the NMAPcrew have replaced a number of other tools simply by adding some new features to NMAP – great job!

=============== Rob VandenBrink, Metafore =================

Related posts:

  1. What’s Up With All The Port Scanning Using TCP/6000 As A Source Port?, (Sat, Jan 9th)
  2. Teredo “stray packet” analysis, (Tue, Feb 16th)
  3. Google seeks DNS protocol extension
  4. Dealing With Unwanted SSH Bruteforcing, (Fri, Jan 1st)
  5. Underground Services Let Virus Writers Check Their Work
  6. TCP Port 12174 Request For Packets, (Sun, Feb 21st)
  7. Version 5.20 of the Nmap network scanner arrives
  8. Lost+Found: Nmap, WordPress, Clouds and Employees
  9. Network vulnerability assessments: Scan all, scan often
  10. Password theft via vulnerability in SSL/TLS protocol


via: SANS Internet Storm Center, InfoCON: green

Filed Under: SANS Internet Storm Center, Tags: ,

Leave a Reply