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

[Brendan Byrd <sineswiper () gmail com>]

On Wed, Dec 28, 2011 at 11:00 AM, Patrik Karlsson <patrik () cqure net> wrote:

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

Looking at it now.  Looks like it's just changes to the community string DB
reader, so I'm try to get that merged in with my own code.


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

Besides the thing below, there's another problem: snmp-brute, and in fact,
probably most of the brute scripts, don't appear to be "thread safe".
We're talking when NMap executes 128 brute scripts for 128 hosts.  The
sending of packets appear to work just fine.  However, when a host-specific
receiver thread tells pcap that it needs to find a specific packet from its
host, Pcap will happily discard all of the good responses from every other
host until it has found the right packet for the host that this single
thread is worried about.

There's no real way of fixing this via Lua.  The script is just executing
code similar to this:

pcap:pcap_open(host.interface, 104, false, "src host " .. host.ip .. " and
udp and port " .. port.number)
...
-- Yay, mass discards!
local status, plen, l2, l3, _ = pcap:pcap_receive()

All of the pcap_receive code is in C, and may even be beyond the scope of
NMap itself, since it's the PCap library.  A work-around is
"--max-hostgroup 1", but that's not ideal for a single, detailed run of
NMap.  Thus, I'm forced to do the "two scan" approach.

I guess another way of fixing it is making sure that the receiver thread
looks for ANY response, and adds creds for that host/port, but that would
involve carefully parsing the packet to acquire those host/port values
(without any table data).  Also, having all of those receiver threads is
practically useless, so it would be this weird set of 128 master/sender
threads and 1 receiver thread.  That receiver thread would somehow need to
wake up the correct per-host master thread when it's finished processing
all of the responses from that host.  Complicated....


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

Hmmm, yeah, I was looking at snmp.lua myself and noticed the same thing: no
access to host/post.  I might be interested in rebuilding the library if I
have some examples to look at.


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

Actually, it somehow fixed itself.  Maybe I changed something and forgot to
save.  Oh well, it works after running it a bunch of times.  So does the
creds-db.nse thing.  I'll need to work on merging all of this stuff
together now (without breaking anything).

-- 
Brendan Byrd/SineSwiper <SineSwiper () GMail com>
_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://seclists.org/nmap-dev/