Ncrack output

[ithilgore <ithilgore.ryu.l () gmail com>]

Hello nmap-dev.

I have already began building Ncrack's output engine and I am at the point where
I need to decide about the output format. Ncrack is going to support
normal(plain), greppable and XML modes of output. For the time being, I am going
to focus on plain and greppable.

PLAIN:

This output should be easily read by humans and could be similar to that of
Nmap's. For now, I was thinking about one of the following formats:

a)

Login pairs found on 10.0.0.10:
PORT      SERVICE    VERSION     LOGIN
21/tcp    ftp        proftpd     root/toor guest/test bob/asdf123
23/tcp    telnet     cisco       root/root
25/tcp    smtp       ?           NONE
80/tcp    http       Apache      admin/admin

Login pairs found on 10.0.0.30:
PORT      SERVICE    VERSION     LOGIN
21/tcp    ftp        FileZilla   guest/guest


Ncrack always initiates full connections and thus can grab the banner of the
service in which case it acts as a simplistic mini version-detection tool
without impacting performance. Thus the VERSION field of the table might be a
feature that can prove useful.

The STATE field isn't shown because we are assuming we are going to crack only
ports that are open. However, since the user is able to specify hosts in
wildmask/netmask format, which means that some of them might have ports that are
either filtered or closed, it *might* be useful to have the STATE field (maybe
only in verbose output) as well, explaining the reason why we couldn't find any
login pairs (filtered/timed out or closed/RST).

Now the problem with the above format is obvious: if the login pairs are more
than 3-4 (which might be infrequent but could happen) or the names are lengthy
ones, then the LOGIN field will become unproportionally wide compared to the
rest of the fields. In that case, we could span the LOGIN field in 2 or more
lines like this:

Login pairs found on 10.0.0.10:
PORT      SERVICE    VERSION     LOGIN
21/tcp    ftp        proftpd     root/toor guest/test bob/asdf123 temp/temp
                                 alice/ENC1337 eve/sniff9999
23/tcp    telnet     cisco       root/root
25/tcp    smtp       ?           NONE
80/tcp    http       Apache      admin/admin

I also would prefer another way of separating a username with its password,
because the password might contain the '/' character. A whitespace might be
handy there, or we could just enclose each " " and have each pair in a separate
line like this:

PORT      SERVICE    VERSION     LOGIN
21/tcp    ftp        proftpd     "root" "toor"
                                 "guest" "test"
                                 "bob" "asdf123"
                                 "temp" "temp"

Alternatively, we could make a separate field for the username and passwords:

Login pairs found on 10.0.0.10:
PORT      SERVICE    VERSION     USERNAME   PASSWORD
21/tcp    ftp        proftpd     root       toor
                                 guest      test
                                 bob        asdf123
                                 temp       temp
                                 alice      ENC1337
                                 eve        sniff9999
23/tcp    telnet     cisco       root       root
25/tcp    smtp       ?           NONE       NONE
80/tcp    http       Apache      admin      admin


b) An alternative way would be something like this (again resembling Nmap):

PORT     SERVICE  VERSION

80/tcp   http     Apache httpd

|  login pairs: root/toor guest/test bob/asdf123 temp/temp
|_              alice/ENC1337 eve/sniff9999
23/tcp   telnet   cisco
|_ login pairs: root/root

But I find it ugly and impractical, since we are probably only going to have
login pairs and nothing else, which more or less nullifies the benefit of having
the '|' format to differentiate between various attributes corresponding to that
service (like it happens with Nmap for http - html-title, robots.txt etc - for
example).

c) Make your suggestions here!


GREPPABLE:

I am not sure about this yet, though I am open to suggestions.

XML:

This will probably need more brainstorming and won't implement it for the time
being. Feel free to propose anything you have in mind, though.


Cheers,
ithilgore





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