Weird target specifications

[David Fifield <david () bamsoftware com>]

Hello,

I am working on this TODO item:

o Ncat --allow/--deny bug: "--allow and --deny only support host
  specification by IP address, and give no warning when you use
  another form such as a host name." Should probably use same syntax
  as --exclude. We also want to at least do verification at the
  beginning to make sure all the entries are legitimately formed.  We
  probably want to do things like DNS resolution at the beginning
  too. Otherwise we might have a DNS failure when we actually get a
  connection and perhaps have to reject the connection wrongly, or
  risk a false negative.

This is a fairly serious problem in my opinion. The way Ncat's
allow/deny handling works now is that it loads the specifications into a
list, as strings with no interpretation. When a new connection comes in,
the address is converted to a string and compared textually with the
entries in the list, following a few simple patterns
(http://nmap.org/ncat/guide/ncat-access.html). If you use an unsupported
pattern, you get no warning, and that pattern will never match any
address. This has security implications if you say "--deny hostname"
expecting it to work, or make a typo like "--deny 192.168.00".

I made a branch,
        svn co --username guest --password "" svn://svn.insecure.org/nmap-exp/david/ncat-allowdeny
to fix these defects. There is code there now that supports a syntax
mostly compatible with what Nmap's --exclude option supports, including
host name lookups and wildcards. While testing it for compatibility I
found some undocumented syntax understood by Nmap. Here are examples.

Specification           Interpreted as
1.2.3.4/+24             1.2.3.4/24
1.2.3.4/24abc           1.2.3.4/24
1.2.3.4//24             1.2.3.4/0
1.2.3.4/-0              1.2.3.4/0
1.2.3*.4                1.2.3.4
1.2.*3.4                1.2.*.4
1.2.**.4                1.2.*.4
1.2.3.-5                1.2.3.0-5
1.2.3.5-                1.2.3.5-255
1.2.3.-                 1.2.3.0
1.2.3,-5.0              1.2.3.0 1.2.0-5.0
1-5*.2.3.4              1-5.2.3.4
1-5-10000.2.3.4         1-5.2.3.4
001.002.003.004         1.2.3.4
+1.2.3.4                1.2.3.4
,1.,2.,3.,4             0,1.0,2.0,3.0,4
1.2.3.                  1.2.3.0
-.-.-.-                 0.0.0.0
....                    0.0.0.0

Test them out by running "nmap -n -sL -- <specification>". All of these,
except for 001.002.003.004, are currently syntax errors in the Ncat
code. Are any of these intentional, supported syntax that Ncat needs to
be compatible with? The only ones I think you can make a case for are
1.2.3.-5 and 1.2.3.5-, but if those are supported then 1.2.3.- should
mean 1.2.3.0-255.

David Fifield

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