Tag Archives: nmap

nmap vulnerability scanning | HowTo

17 Dec

Port and vulnerability scanners are common tools used by good as bad guys. Performing a port scanning is one of the first operations required to find potential vulnerabilities on a target system. That’s why vulnerability scanners have built-in port scanners. Writing a port scanner is really easy with a few lines of Perl:

#!/usr/bin/perl
use IO::Socket;
while ($ARGV[1] < 65536) {
  print STDOUT "$ARGV[0]:".($ARGV[1] - 1) . " open\n" if \
(IO::Socket::INET->new(PeerAddr=>"$ARGV[0]:" .$ARGV[1]++, Proto=>'tcp', Timeout=>1));
}

(Source: okc2600.com)

However, “real” port scanners offer much more options like evading techniques to work “below the radar” or fingerprinting. Nmap is the best tools for this purpose.

Synergies already exist between different scanning products. A good example is the integration of Nessus with Nmap. Nmap can save the scan results in XML format. The produced XML content can be re-used by Nessus to scan for vulnerabilities. By using this method, the power of Nessus is combined with the one of Nmap. For more information, read this article.

Performing a vulnerability scan  is highly resources consuming. Why not add a simple vulnerability scan feature to Nmap? This primary goal is to save time and be less intrusive. Nmap has a built-in script interpreter called NSE (“Nmap Scripting Engine“) which allows developers to write extensions for Nmap. It comes by default with a lot of scripts. If you’re interested, I posted an introduction article on NSE a few months ago.

Marc Ruef developed a NSE script which adds a basic vulnerability scanner feature to your Nmap. Technically, the script does NOT perform a vulnerability scan by itself. With the powerful fingerprinting feature of Nmap (using the “-sV” flag), the running applications and versions can be detected. Those information are used as lookup keys in a DB export of OSVDB, the Open Source Vulnerability Data Base. The matching entries are displayed in the script output. The script installation is extremely simple, just copy the files in your existing scripts repository (something like “$NMAP_INSTALL_PATH/share/nmap/scripts/“). Invoke it like any standard script:

# nmap -PN -sS -sV --script=vulscan -p80 www.company.tld

Starting Nmap 5.30BETA1 ( http://nmap.org ) at 2010-06-03 11:11 CEST
Nmap scan report for www.company.tld (10.0.0.1)
Host is up (0.00074s latency).
rDNS record for 10.0.0.1: www.company.tld
PORT   STATE SERVICE VERSION
80/tcp open  http    Apache httpd 2.2.11 ((Ubuntu) PHP/5.2.6-3ubuntu4.5 with Suhosin-Patch)
| vulscan: [48] Apache HTTP Server on Debian /usr/doc Directory Information Disclosure
| [143] Apache HTTP Server printenv.pl Multiple Method CGI XSS
| [222] Apache HTTP Server test-cgi Arbitrary File Access

[Stuff Deleted]

| [63895] Apache HTTP Server mod_headers Unspecified Security Issue
| [64023] Apache Tomcat WWW-Authenticate Header Local Host Information Disclosure
| [64020] Apache ActiveMQ Jetty ResourceHandler Crafted Request JSP File Source Disclosure
| [64307] Apache Tomcat Web Application Manager/Host Manager CSRF
| [64517] Apache Open For Business Project (OFBiz) View Profile Section partyId Parameter XSS
| [64518] Apache Open For Business Project (OFBiz) Show Portal Page Section start Parameter XSS
| [64519] Apache Open For Business Project (OFBiz) Control Servlet URI XSS
| [64520] Apache Open For Business Project (OFBiz) ecommerce/control/ViewBlogArticle contentId Parameter XSS
| [64521] Apache Open For Business Project (OFBiz) Web Tools Section entityName Parameter XSS
|_[64522] Apache Open For Business Project (OFBiz) ecommerce/control/contactus Multiple Parameter XSS

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

My first impression was disappointing: The scan reported too much vulnerabilities (>500 hits!). Unusable in a real environment. But, after reading the script (remember: RTFM!), Marc was aware of this problem (caused by a naming convention issue between Nmap & OSVDB). He added a correlation feature to reduce those false positives. To activate this option, just pass the following parameter:

# nmap -PN -sS -sV --script=vulscan --script-args vulscancorrelation=1 -p80 www.company.tld

Hopefully, this second test generated much less hits (26) but, side effect, required more time to complete.

This is a very nice feature for Nmap. By using this script, you can quickly have an overview of the potential vulnerabilities on a target host. And, if necessary, use a more classic tool to focus on specific cases. Don’t forget that false positives or false negatives and results must always be analyzed by a competent person.

To keep the vulnerability scanner accurate, the vulnerability DB must be kept up to date. To achieve this, you can automate the update using the CSV export available on osvdb.org (updated daily). First you have to register. Once done, you will be able to download the CSV updates via a permalink generated with your API key.  The upgrade can be fully automated via a simple daily cron and a script:

NMAPHOME=/usr/local/nmap
FILES="object_correlations.txt object_links.txt object_products.txt vulnerabilities.txt"
cd /tmp
wget -o /dev/null http://osvdb.org/file/get_latest_csv/xxxxx/osvdb-csv.latest.tar.gz
for FILE in $FILES
do
	tar xzf osvdb-csv.latest.tar.gz ./osvdb/$FILE
	mv osvdb/$FILE $NMAPHOME/share/nmap/scripts/vulscan
done
rm -rf osvdb
rm osvdb-csv.latest.tar.gz
exit 0

Marc released the version 0.6 is his script and has already a nice todolist (integration with other vulnerability databases). Great job!

Advertisements

nmap scan via TOR | hidemyip

9 Mar
Description

This tutorial shows how to configure the tools to do a Nmap portscan through the Tor network. This technique can be used in the shape of a pentest but it can also be used by attackers. Please be careful of the type of nmap scans you do as some options send your ip. You can add an entry to iptables to drop all outbound traffic to the destination for a particular scan. See further on for a how to.

Pre-requisites

First ensure you have installed necessary tools:

Configuration

In the following example, we do a Nmap portscan with tortunnel via proxychains. The reason why we need tortunnel is that it enables to scan faster. Indeed, by default, Tor uses a minimum of 3 hops. Thanks to tortunnel, we directly use a final exit node, which makes the scan much faster.

First install tor and configure it and install proxychains:

$ sudo apt-get install tor tor-geoipdb proxychains 
$ sudo service tor status 
tor is running $ sudo vi /etc/tor/torrc
# add the line below to allow local ip range to use tor proxy # SocksPolicy accept 10.1.1.0/24

Also install tortunnel:

$ sudo apt-get install libboost-system1.40-dev libssl-dev
$ cd /data/src/
$ wget http://www.thoughtcrime.org/software/tortunnel/tortunnel-0.2.tar.gz
$ tar xvzf tortunnel-0.2.tar.gz
$ cd tortunnel-0.2/
$ ./configure
$ make
$ sudo make install

Then configure proxychains to work with tortunnel. Edit the configuration file:

$ sudo vim /etc/proxychains.conf

And modify it as follows:

[ProxyList]
# add proxy here ...
# meanwile
# defaults set to "tor"
#socks4         127.0.0.1 9050
socks5 127.0.0.1 9050
Find an exit node and start torproxy

We then have to find an exit node that is stable, fast and valid. Most tor exit nodes do not support nmap scanning. You could use this :

$ curl http://128.31.0.34:9031/tor/status/all | grep --before-context=1 'Exit Fast Running V2Dir Valid' | awk '{ print $7 }' | sed '/^$/d'

to return a list of exit nodes that support nmap scanning.

Then start torproxy with the found exit node using the -n switch and bind to local port 9900 :

$ torproxy -n 178.73.***.** -p 9900
torproxy 0.3 by Moxie Marlinspike.
Retrieving directory listing...
Connecting to exit node: 178.73.*.*:9001
SSL Connection to node complete.  Setting up circuit.
Connected to Exit Node.  SOCKS proxy ready on 9900.
Start scan
Ssh-img013.png
Warning -> Beware of the parameters you use for the scan since some of them will disclose your IP address. More information below.

For our scan, we use Nmap with following arguments:

  • -Pn: to skip the host discovery (since it sends ICMP address, it would disclose our IP address)
  • -sT: full Connect() scan to ensure that all packets use the Tor network.

To ensure that our IP address won’t be disclosed to the target, you can add following rule to your firewall:

$ sudo iptables -A OUTPUT --dest <target> -j DROP

Now, run Nmap ad follows:

$ proxychains nmap -Pn -sT -p 80,443,21,22,23 80.14.163.161
ProxyChains-3.1 (http://proxychains.sf.net)

Starting Nmap 5.36TEST4 ( http://nmap.org ) at 2011-02-09 22:40 CET
|S-chain|-<>-127.0.0.1:5060-<><>-80.14.163.161:23-<--timeout
|S-chain|-<>-127.0.0.1:5060-<><>-80.14.163.161:22-<--timeout
|S-chain|-<>-127.0.0.1:5060-<><>-80.14.163.161:443-<--timeout
|S-chain|-<>-127.0.0.1:5060-<><>-80.14.163.161:80-<><>-OK
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
RTTVAR has grown to over 2.3 seconds, decreasing to 2.0
|S-chain|-<>-127.0.0.1:5060-<><>-80.14.163.161:21-<--timeout
Nmap scan report for LMontsouris-156-25-20-161.w80-14.abo.wanadoo.fr (80.14.163.161)
Host is up (13s latency).
PORT    STATE  SERVICE
21/tcp  closed ftp
22/tcp  closed ssh
23/tcp  closed telnet
80/tcp  open   http
443/tcp closed https

Nmap done: 1 IP address (1 host up) scanned in 60.86 seconds
Nmap results and tcpdump traces

Nmap results – without tor

$ nmap -Pn -sT 74.50.**.***

Starting Nmap 5.36TEST4 ( http://nmap.org ) at 2011-02-11 05:21 CET
Nmap scan report for 74.50.**.***
Host is up (0.16s latency).
Not shown: 992 closed ports
PORT      STATE    SERVICE
22/tcp    open     ssh
80/tcp    open     http
135/tcp   filtered msrpc
139/tcp   filtered netbios-ssn
443/tcp   open     https
445/tcp   filtered microsoft-ds
10000/tcp open     snet-sensor-mgmt
20000/tcp open     dnp

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

tcpdump traces – without tor
Our IP address is disclosed, as shown on the following extract:

$ tcpdump -nS -c 10 -r scan-without-tor.cap "host 80.14.163.161"
reading from file scan-without-tor.cap, link-type EN10MB (Ethernet)
05:21:58.052164 IP 80.14.163.161.51027 > 74.50.**.***.21: Flags [S], seq 3307142116, win 5840, options [mss 1416,sackOK,TS val 148568 ecr 0,nop,wscale 6], length 0
05:21:58.052249 IP 74.50.**.***.21 > 80.14.163.161.51027: Flags [R.], seq 0, ack 3307142117, win 0, length 0
05:21:58.053041 IP 80.14.163.161.46436 > 74.50.**.***.3389: Flags [S], seq 3300984040, win 5840, options [mss 1416,sackOK,TS val 148568 ecr 0,nop,wscale 6], length 0
05:21:58.053058 IP 74.50.**.***.3389 > 80.14.163.161.46436: Flags [R.], seq 0, ack 3300984041, win 0, length 0
05:21:58.054538 IP 80.14.163.161.46034 > 74.50.**.***.80: Flags [S], seq 3299162143, win 5840, options [mss 1416,sackOK,TS val 148568 ecr 0,nop,wscale 6], length 0
05:21:58.054567 IP 74.50.**.***.80 > 80.14.163.161.46034: Flags [S.], seq 2576119236, ack 3299162144, win 5792, options [mss 1460,sackOK,TS val 2639903416 ecr 148568,nop,wscale 5], length 0
05:21:58.055538 IP 80.14.163.161.60357 > 74.50.**.***.8080: Flags [S], seq 3303516262, win 5840, options [mss 1416,sackOK,TS val 148568 ecr 0,nop,wscale 6], length 0
05:21:58.055552 IP 74.50.**.***.8080 > 80.14.163.161.60357: Flags [R.], seq 0, ack 3303516263, win 0, length 0
05:21:58.057287 IP 80.14.163.161.43407 > 74.50.**.***.22: Flags [S], seq 3301543264, win 5840, options [mss 1416,sackOK,TS val 148568 ecr 0,nop,wscale 6], length 0
05:21:58.057303 IP 74.50.**.***.22 > 80.14.163.161.43407: Flags [S.], seq 2572644408, ack 3301543265, win 5792, options [mss 1460,sackOK,TS val 2639903416 ecr 148568,nop,wscale 5], length 0

Nmap results – with tor

$ proxychains nmap -Pn -sT 74.50.**.***
(...TRUNCATED...)
Nmap scan report for 74.50.**.***
Host is up (0.35s latency).
Not shown: 995 closed ports
PORT      STATE SERVICE
22/tcp    open  ssh
80/tcp    open  http
443/tcp   open  https
10000/tcp open  snet-sensor-mgmt
20000/tcp open  dnp

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

tcpdump traces – with tor
Our IP address is not disclosed, as shown on the following extract:

$ tcpdump -nS -c 10 -r scan-with-tor.cap "host 80.14.163.161"
reading from file scan-with-tor.cap, link-type EN10MB (Ethernet)
Conclusions

The results of the scans have shown that Tor enables to realize a Nmap portscan while not disclosing our IP address. Nevertheless, some limitations:

  • Our scan must use the full Connect() handshake
  • It is much slower than a normal scan (420 seconds with Tor against 23 seconds without using Tor), although we only used one exit node.
  • The anonymity of the second scan remains relative. Indeed, since we only use one node, this latest could be able to disclose our identity.

Shoutout to http://www.aldeid.com/ for this post