Re: Ncrack output

[Fyodor <fyodor () insecure org>]

On Sat, Jun 27, 2009 at 02:03:06AM +0300, ithilgore wrote:
> I have already began building Ncrack's output engine and I am at the point where
> I need to decide about the output format.

Hi Ithilgore.  That's exciting news!  Thanks for sending your
proposal.  I haven't thought about it as long as you have, but here
are my initial thoughts.

> 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.

Nmap has those three modes, but Nmap's grepable mode has been
deprecated for many years.  It does not even support newer features,
such as NSE.  So I'm not sure it is worth supporting both a plain and
grepable format in ncrack.  I see three options:

1) Offer separate plain and grepable options

2) Offer just plain option, and people will have to grab all the
   details with slightly smarter parsing of the plain output, or using
   the upcoming XML output.

3) Offer just the plain option, but include the most pertinant details
   (target IP, port, and one or more user/pass credentials) on the same
   line so that it can easily be grepped.

I don't know which of these options is best, but I'd suggest focusing
on the normal output and then only adding grepable if it is truly
needed.

> 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

This is familiar to users since it resembles Nmap output, but I think
ncrack can be simplified.  Nmap's has a very host-centric view of a
network and its output is rather complex because it can discover such
a wide variety of possible information.  Ncrack's scope is
substantially smaller--it is trying to find authentication credentials
for each service it is run against.

> c) Make your suggestions here!

I think the Ncrack output should be service (host:port) specific
rather than a host-view like above.  One idea is to give a line for
the service info followed by credentials:

Discovered credentials for ftp service on 10.0.0.10 (host.foo.com) tcp/21:
 10.0.0.10 21/tcp ftp: root/toor
 10.0.0.10 21/tcp ftp: guest/test
 10.0.0.10 21/tcp ftp: bob/asdf123

In this way you get everything you need to login on each credential
line (so it is grepable), while still having an extra line for extra
information (such as rdns in the case above, or version detection
information if it was to be there).  And more lines could be added
above the credential entries if and when they prove necessary.

Again, I haven't spent much time brainstorming this.  It's just my
initial thought and could surely use further refinement.

> 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.

Well, maintaining a version detection DB is a huge amount of work, so
I'm not fond of maintaining two of them.  I'd probably only support
this if it gets the information by passing the banner to the regexp's
we already have in nmap-service probes (e.g. the Null probes).  This
actually may not be too hard.  Ncrack could also retrieve version
detection information from Nmap output when input is given in that
format.

> 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).

In verbose mode we could print a warning whenever that happens (we
give up on a port after discoverying that it is closed/filtered).

> 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:

Yeah, escaping is an important concern.  Fortunately, for XML output,
the standards already exist.

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

I think the key to grepable output is giving everything you need to
log into a service (target ip port, protocol, credentials) on the same
line.  The format above does that.

> 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.

Given that ncrack's mission is far simpler than Nmap's, I think the
XML format can be quite simple.

Cheers,
-F

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