Re: [NSE][PATCH] OpenSSL bindings for NSE

["M M" <v4lkyrius () gmail com>]

On Fri, Nov 28, 2008 at 4:49 AM, Sven Klemm <sven () c3d2 de> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi v4lkyrius,
>
> > I first noticed this in auth.log when I got port scanned by a friend a
> > while back. My firewall rules have reflected this observation ever
> > since.
> > Defeats the purpose of nmap, does it not?
> >
> > For example:
> >
> >   pluto: # nmap -A -p 22 localhost
> >
> >   Starting Nmap 4.60 ( http://nmap.org ) at 2008-11-26 06:05 EST
> >   Warning: Hostname localhost resolves to 2 IPs. Using 127.0.0.1.
> >   Interesting ports on localhost (127.0.0.1):
> >   PORT   STATE SERVICE VERSION
> >   22/tcp open  ssh     OpenSSH 5.0 (protocol 2.0)
> >   Warning: OSScan results may be unreliable because we could not find
> > at least 1 open and 1 closed port
> >   Device type: general purpose
> >   Running: Linux 2.6.X
> >   OS details: Linux 2.6.17 - 2.6.24
> >   Uptime: 0.217 days (since Wed Nov 26 00:52:52 2008)
> >   Network Distance: 0 hops
> >
> >   OS and Service detection performed. Please report any incorrect
> > results at http://nmap.org/submit/ .
> >   Nmap done: 1 IP address (1 host up) scanned in 1.360 seconds
> >
> >   pluto:/var/log # tail messages | grep sshd
> >   Nov 26 06:05:29 pluto sshd[7947]: Did not receive identification
> > string from 127.0.0.1
> >   Nov 26 06:05:30 pluto sshd[7951]: Protocol major versions differ for
> > 127.0.0.1: SSH-2.0-OpenSSH_5.0 vs. SSH-1.5-NmapNSE_1.0
> >   pluto:/ # iptables -I INPUT -p tcp -m string --string "NmapNSE"
> > --algo bm -j DROP
> >   pluto:/ # iptables -I INPUT -p tcp -m string --string "NmapNSE"
> > --algo bm -j LOG --log-prefix "n00b nmap scan: "
> >   pluto:/ # nmap -A -p22 localhost
> >
> >   Starting Nmap 4.60 ( http://nmap.org ) at 2008-11-26 06:08 EST
> >   Warning: Hostname localhost resolves to 2 IPs. Using 127.0.0.1.
> >   ^C
> >   pluto:/var/log # grep n00b firewall | tail -1
> >   Nov 26 06:08:35 pluto kernel: n00b nmap scan: IN=lo OUT=
> > MAC=00:00:00:00:00:00:00:00:00:00:00:00:08:00 SRC=127.0.0.1
> > DST=127.0.0.1 LEN=72 TOS=0x00 PREC=0x00 TTL=64 ID=6129 DF PROTO=TCP
> > SPT=27995 DPT=22 WINDOW=257 RES=0x00 ACK PSH URGP=0
> >
> >
> > Frankly, I'm surprised no one has so much as mentioned this before (at
> > least publicly, according to Google). They say discretion is the
> > polite word for hypocrisy. ;-)
>
> the fact that nmap advertises itself has been discussed, here:
> http://seclists.org/nmap-dev/2008/q2/0505.html . There are a few place
> were nmap does this advertising, e.g. the NSE http, ssh1 and ssh2
> libraries do it.

Oops, my bad. I had only done a Google search for
"SSH-1.5-NmapNSE_1.0" before replying to this list. I'd like to
briefly re-open that discussion, if I may.

> Your solution to drop TCP connections based on arbitrary strings
> doesn't seem like a good idea to me.

Sorry, that rule was just used as an example. Of course, it can be fine-tuned:
# iptables -A INPUT -p tcp --dport ssh -m string --string
"SSH-1.5-NmapNSE_1.0" --algo bm -j LOG --log-prefix "nmap sshv1 scan:
"
# iptables -A INPUT -p tcp --dport ssh -m string --string
"SSH-1.5-NmapNSE_1.0" --algo bm -j REJECT

A script (much like DenyHosts) could then pick up "nmap sshv1 scan: "
in the logs and block that IP in hosts.deny.

> Cheers,
> Sven
>
> - --
> Sven Klemm
> http://cthulhu.c3d2.de/~sven/
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkkvvrcACgkQevlgTHEIT4alagCfZCu+O9HG4jsiPebHZvvi0XGy
> fOwAn2NOkPkFl7szY2GGxiAAJlQJ8Xzx
> =Sr1B
> -----END PGP SIGNATURE-----

I'll elaborate my concerns a little more. Using such an obvious SSH
banner (or similar, in other scripts) makes it incredibly easy to
thwart nmap's (plaintext) version scans. On the other hand, you've
already advertised yourself, and in that time the scanee has reacted
(e.g. hosts.deny, if he/she is nice). In the end, the whole scan and
any future access is compromised because of a single version script.

One solution mentioned was to have an array of common banners
(possibly with randomized version numbers), which the script would
cycle through randomly. However, after reading the previous
discussion, perhaps this isn't the best idea; perhaps Brandon's
--script-args solution is better.
My (band-aid) solution was to disable the scripts from being run by
default. Would it be possible to add a "stealth" category to the
categories field? And maybe a mechanism that allows for waiting till
the end of a scan to run non-"stealth" scripts. Just a thought.

My apologies for resurrecting old discussions. :P

Sincerely,
v4lkyrius

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org