Learning Nmap Security Network Port Scanner: SunRPC Grinding

This is the seventeenth post detailing my notes on Nmap Network Scanning.

This security website describes Sun’s RPC thus:

Sun’s RPC (Remote Procedure Call) forms the basis of many UNIX services, especially NFS (Network File System). However, RPC is extremely dangerous when left exposed to the Internet, which leads to frequent compromise of servers based upon Sun Solaris and Linux. RPC should never be exposed to the Internet.

And this website talks of the advantages and disadvantages of the RPC scan:

Advantages of the RPC Scan
The RPC scan provides detailed RPC application and version information. If the remote device is running an RPC-based application, nmap will reveal everything!

Even if an RPC application is running on an unexpected port, the RPC scan will find it. The RPC scan sends an RPC null to all open ports, so it’s impossible for an RPC application to hide in a little-used port!

Disadvantages of the RPC Scan
The RPC scan opens application sessions, so there will be transaction events in the application logs. Once the application is opened, the size of the conversation will vary. Some open ports will transfer data, but no RPC information. Other RPC applications will send a number of frames as nmap queries for the application name and version number.

Decoys don’t currently work in conjunction with an RPC scan, although it may be a future nmap enhancement.

When to use the RPC Scan
If RPC applications are of interest, the RPC scan will efficiently and effectively locate all RPC applications and identify the RPC application name and version. The RPC scan automatically runs during a version scan, combining valuable version information with detailed RPC data.

Interestingly, like many websites, the above source notes the RPC scan flag as -sR. If you try this Nmap gives this warning:

WARNING: -sR is now an alias for -sV and activates version detection as well as RPC scan.

So, RPC is enabled by default in version detection scans.

Anyway, the Nmap book cites a direct RPC scan using the flag: nmap -F -sSU target. This confuses me as the -A flag is set which includes version detection and as we already know the RPC scan is included as default.

So, I’m a little baffled, but here are some of my experiment scans:

nmap -F -A -sSU scanme.nmap.org

Starting Nmap 6.25 ( http://nmap.org ) at 2013-07-29 10:01 BST
Nmap scan report for scanme.nmap.org (74.207.244.221)
Host is up (0.14s latency).
Not shown: 193 closed ports
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 5.3p1 Debian 3ubuntu7 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 1024 8d:60:f1:7c:ca:b7:3d:0a:d6:67:54:9d:69:d9:b9:dd (DSA)
|_2048 79:f8:09:ac:d4:e2:32:42:10:49:d3:bd:20:82:85:ec (RSA)
80/tcp open http Apache httpd 2.2.14 ((Ubuntu))
|_http-title: Go ahead and ScanMe!
554/tcp open tcpwrapped
7070/tcp open tcpwrapped
68/udp open|filtered dhcpc
123/udp open ntp NTP v4
| ntp-info:
|_ receive time stamp: Mon Jul 29 10:04:32 2013
1701/udp open|filtered L2TP
Device type: general purpose|media device
Running (JUST GUESSING): Linux 2.6.X|3.X (89%)
OS CPE: cpe:/o:linux:linux_kernel:2.6.38 cpe:/o:linux:linux_kernel:3 cpe:/h:dish:vip_722k cpe:/o:linux:linux_kernel:2.6
Aggressive OS guesses: Linux 2.6.38 (89%), Linux 3.0 (88%), Linux 2.6.32 – 2.6.35 (87%), Linux 2.6.32 – 2.6.38 (87%), Linux 2.6.39 (86%), Linux 2.6.35 (86%), Linux 3.2 (85%), Dish Network VIP 722k DVR (Linux 2.6) (85%)
No exact OS matches for host (test conditions non-ideal).
Network Distance: 15 hops
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel

And:

nmap rpcinfo scanme.nmap.org

Starting Nmap 6.25 ( http://nmap.org ) at 2013-07-29 10:28 BST
Nmap scan report for scanme.nmap.org (74.207.244.221)
Host is up (0.19s latency).
Not shown: 995 closed ports
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
554/tcp open rtsp
7070/tcp open realserver
9929/tcp open nping-echo

Nmap done: 2 IP addresses (1 host up) scanned in 6.98 seconds