Re: [NSE] How brute scripts and UN/PW scripts interact with creds

[Patrik Karlsson <patrik () cqure net>]

On Wed, Dec 28, 2011 at 1:01 PM, Brendan Byrd <sineswiper () gmail com> wrote:

> On Sun, Dec 25, 2011 at 4:33 PM, Patrik Karlsson <patrik () cqure net> wrote:
>
> > I'm guessing by long-term you mean that they are not stored once Nmap
> > finishes?
> > As for script interaction, the library was added not that long ago and
> > all scripts that make use of the brute library implicitly use it.
> > But there is some work left of migrating old brute scripts to the brute
> > framework and adding the cred library to those that could use it. As for
> > saveToFile function there was one added by Tom Sellers 2011/09/04, but it
> > doesn't appear in the nsedoc due to a formatting issue.
>
> Yeah, I started that route, but ended up with a creds-db.nse script.  It's
> a prerule/postrule script that loads/saves the existing creds DB data into
> a permanent file. I'll submit it as soon as I get this snmp-brute stuff
> completely fixed.

Make sure to check out the latest snmp-brute that was committed a few days
ago.


> There's also the matter of database size.  Is the Lua code fast enough to
> > > look through, say, 10K hosts in a Lua table among thousands of script
> > > checks?  If not, then some sort of mini-database format, or maybe a
> > > better
> > > type of lookup, would need to be created.
> >
> > Just to get a better understanding, could you provide me with a use case
> > here?
>
> Sure.  I'm scanning a couple thousand hosts to ID them via SNMP.  These
> hosts potentially use one of 7-8 community strings.  Instead of doing 7-8
> NMap scans on each community string, I want to be able to figure out the
> right community string for each host and then do version checking on them
> all to get the SNMP hostname.  This might turn into 2 NMap scans (one for a
> community string find, and the larger one for basic scanning/ID of the
> hosts), but it's better than parsing through 7-8 different XML files.

At first I thought: wouldn't you achieve this by putting these 7-8
community strings in a community dictionary file (snmp-brute.communitiesdb)
and running snmp-brute and whatever other snmp script you would like output
from? As all snmp scripts should depend on snmp-brute it should find the
proper string and have it for the other scripts running once it finishes.

BUT then I noticed that the creds library has not been implemented in the
SNMP library and that it will only check for a registry value being set,
regardless of host. I then tried to see if I could fit my creds library
into the SNMP library and quickly realized that there's no quick way of
doing so as we don't have access to the host and port tables in there. The
SNMP library is one of the old ones which simply creates the binary packet
and relies on the scripts to do the socket work. Ideally I think the SNMP
library should have a Helper class as most of the newer libraries have. The
helper class should wrap the other code and take care of socket
communication, this way we have access to the host and port tables and
could leverage the credentials stored by the credential library for each
host from within the SNMP library. This way we wouldn't have to add support
for the cred library in each and every snmp script. If you want to help out
implementing this let me know, otherwise I will add it to my TODO list.


> I got mostly everything working and figured out my looping bugs so far,
> but I'm still occasionally hitting a freeze problem with certain hosts on
> snmp-brute.  Of course, since creds-db only saves at the very end of the
> NMap run, this wastes all of the work previously and I have to debug and
> start over again.  I really wish NMap would wake up and realize that a
> script is endlessly looping, but I guess that's up to us to debug.


If you want help looking at it, send me a copy of what you have so far.


> --
> Brendan Byrd/SineSwiper <SineSwiper () GMail com>
Cheers,
Patrik

-- 
Patrik Karlsson
http://www.cqure.net
http://twitter.com/nevdull77
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/