mailing list archives
Re: Ncrack output
From: Fyodor <fyodor () insecure org>
Date: Fri, 26 Jun 2009 21:57:06 -0700
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
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
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.
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.
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.
Sent through the nmap-dev mailing list
Archived at http://SecLists.Org