mailing list archives
Re: [NSE] How brute scripts and UN/PW scripts interact with creds
From: Brendan Byrd <sineswiper () gmail com>
Date: Wed, 28 Dec 2011 21:38:16 -0500
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
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
Archived at http://seclists.org/nmap-dev/