Strange Network Traffic using -sP flag in nmap 3.81

[moo yana <james.mailing () gmail com>]

I think I may have discovered a bug nmap 3.81 - wasn't sure whether
nmap-hackers or nmap-dev was a better place for this, so I've opted for
here. When issuing a scan specifying either a single port or multiple ports
with the '-p' flag, there's a connection made and then quickly reset to the
destination host on port 80.

By way of example, the following command:

james@anubis ~ $ nmap -p 25 -sV insecure.org <http://insecure.org>

Starting nmap 3.81 ( http://www.insecure.org/nmap/ ) at 2005-10-16 11:22 BST
Interesting ports on www.insecure.org <http://www.insecure.org> (
205.217.153.53 <http://205.217.153.53>):
PORT STATE SERVICE VERSION
25/tcp closed smtp

Nmap finished: 1 IP address (1 host up) scanned in 1.114 seconds

Produced the following traffic, dumped from the same box using snort
(started as 'snort -pvd host insecure.org <http://insecure.org>'). I've
tried various permutations of the CLI command, and I've dumped traffic off
an upstream box (network gateway) using snort in exactly the same way, and I
get exactly the same result.

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

10/16-11:22:19.741534 10.1.1.100:38109 <http://10.1.1.100:38109> ->
205.217.153.53:80 <http://205.217.153.53:80>
TCP TTL:64 TOS:0x0 ID:39723 IpLen:20 DgmLen:44 DF
******S* Seq: 0x85AD994F Ack: 0x0 Win: 0x16D0 TcpLen: 24
TCP Options (1) => MSS: 1460

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

10/16-11:22:19.906596 205.217.153.53:80 <http://205.217.153.53:80> ->
10.1.1.100:38109 <http://10.1.1.100:38109>
TCP TTL:46 TOS:0x0 ID:0 IpLen:20 DgmLen:44 DF
***A**S* Seq: 0xABB1F721 Ack: 0x85AD9950 Win: 0x16D0 TcpLen: 24
TCP Options (1) => MSS: 1460

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

10/16-11:22:19.906674 10.1.1.100:38109 <http://10.1.1.100:38109> ->
205.217.153.53:80 <http://205.217.153.53:80>
TCP TTL:64 TOS:0x0 ID:39725 IpLen:20 DgmLen:40 DF
***A**** Seq: 0x85AD9950 Ack: 0xABB1F722 Win: 0x16D0 TcpLen: 20

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

10/16-11:22:19.907066 10.1.1.100:38109 <http://10.1.1.100:38109> ->
205.217.153.53:80 <http://205.217.153.53:80>
TCP TTL:64 TOS:0x0 ID:39727 IpLen:20 DgmLen:40 DF
***A*R** Seq: 0x85AD9950 Ack: 0xABB1F722 Win: 0x16D0 TcpLen: 20

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

10/16-11:22:20.612880 10.1.1.100:52572 <http://10.1.1.100:52572> ->
205.217.153.53:25 <http://205.217.153.53:25>
TCP TTL:64 TOS:0x0 ID:55537 IpLen:20 DgmLen:44 DF
******S* Seq: 0x8634DD24 Ack: 0x0 Win: 0x16D0 TcpLen: 24
TCP Options (1) => MSS: 1460

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

10/16-11:22:20.781874 205.217.153.53:25 <http://205.217.153.53:25> ->
10.1.1.100:52572 <http://10.1.1.100:52572>
TCP TTL:46 TOS:0x0 ID:1170 IpLen:20 DgmLen:40 DF
***A*R** Seq: 0x0 Ack: 0x8634DD25 Win: 0x0 TcpLen: 20

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

As you can quite clearly see, a connection is established on port 80, a
handshake is made, and the connection's then reset by the initiating party.

I've scoured the man page and I had a brief google (although it's a bit of a
nebulous one to search for) but I haven't found anything, so I don't think
I'm repeating anything already said or making any silly assumptions,
although apologies if I am!

I was just playing around with nmap because I wanted to watch how it
fingerprinted smtp (having just been appalled at how astoundingly messily
and noisily amap does this) using snort, but I'd imagine that if I'd (or
anyone else had) been using this for some sort of penetration test or other
activity requiring subtlety (can't imagine what such activities would be),
random connections initiated to the target host on port 80 might not
necessarily be desirable behaviour, so this is quite a scary little bug if
it is indeed a bug!

For what it's worth, this is running on an up to date (last upgraded this
morning) version of ubuntu (breezy) linux - I've had someone else check this
out with the previous release and the same result occurs, but unfortunately
I don't have any other hosts around (linux or otherwise) to test this out on
to see whether or not it's ubuntu-specific.

regards,

- James (njan) Eaton-Lee


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