Nmap Development 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 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
Current thread:
- Ncrack output ithilgore (Jun 26)
- Re: Ncrack output ithilgore (Jun 26)
- Re: Ncrack output Arturo 'Buanzo' Busleiman (Jun 26)
- Re: Ncrack output ithilgore (Jun 26)
- Re: Ncrack output Arturo 'Buanzo' Busleiman (Jun 26)
- Re: Ncrack output Fyodor (Jun 26)
- Re: Ncrack output Toni Ruottu (Jun 27)
- Re: Ncrack output ithilgore (Jun 26)