Re: [NSE] snmp-brute port to brute framework

[Patrik Karlsson <patrik () cqure net>]

I spoke to soon. For some reason I can't see (tcpdump) packets going from my host (OS X) to my guest machine 
(VirtualBox).
Even if I run the interface in bridged mode. This makes this script somewhat difficult to test as it relies on pcap to 
check for the responses :(
I'll see if I can find a workaround for this tomorrow (maybe using a second laptop).

I noticed that the old snmp-brute script was replaced with a new one and I noticed that the old hardcoded communities 
were no longer tested.
I think this is a problem and that we need to add them back until we figure out the "ultimate" community list.
Mainly because the current script relies on the default (unpwdb) dictionary that doesn't contain all of the old 
community strings (not even public).

While trying to fix this, I ran into some other bugs that I've tried to address with the attached patch.

* There was one thing that was driving me crazy and I suspected some major bug in the snmp library that had to do with 
concurrency until I found this in snmp-brute:
        
        if not nmap.registry.snmpcommunity then
                nmap.registry.snmpcommunity = result[2]
        end

  In combination with this comment: "we want to search for both readonly and readwrite community strings" we have a 
problem, as once the registry value is set it is used as the community in all snmp requests, overriding any community 
string set by buildPacket.
  I solved this by removing that code from the driver and replacing it with some code at the end of the script that 
fetches the first community stored in the credential library by using the getCredentials function 

*  Credentials were added directly to the credential database resulting in duplicate entries as the brute library takes 
care of this when an account is discovered.
    The reason why duplicates were not appearing was a typo in the code.

I also found two bugs in the brute library that I fixed:
* A bug in the brute library prevented additional passwords from being found if run in passonly mode. A fix for this 
was committed in r 24870
* A bug in the brute library failed to detect duplicate password entries in dictionaries. A fix for this was committed 
in r 24870

Cheers,
Patrik

Attachment: snmp-brute-fix.patch
Description:

On Jul 12, 2011, at 5:21 PM, Gorjan Petrovski wrote:

> I've hacked together a script to test the throughput of the snmp
> server, and my tests against a Net-SNMP server on a Ubuntu 11.04
> desktop edition showed that it processes all the probes fine. It uses
> threads so it should make for a pretty precise measurement.
>
> If you can, please test the attached script against your servers. The
> command you need to use to test it with 10000 probes (which I
> recommend for virtual machines) is:
>
> nmap -sU -p U:161 --script test --script-args
> test.probes=10000,test.community=<community_string> <target> -d
>
> Thanks a lot! :D
> Gorjan
>
> On Tue, Jul 12, 2011 at 8:19 AM, Patrik Karlsson <patrik () cqure net> wrote:
> > On Jul 12, 2011, at 12:30 AM, Gorjan Petrovski wrote:
> >
> > > Thanks for the suggestions. Currently I'm testing the throughput with
> > > unconnected sockets. I'm using a virtual machine so any limitations
> > > would be due to slow processing of requests on the server's part. I'm
> > > gonna add the default passwords after I resolve the issues with
> > > communication and losses of passwords. Currently my criteria are that
> > > under no circumstances we should DoS the server, and as a result of
> > > that miss testing some passwords. My thoughts are going toward using
> > > unconnected sockets but somehow limiting the number of probes sent per
> > > second. The host.times.timeout will definitely be of use, but I'll
> > > have to add a heuristic multiplier to that, so now I have to find what
> > > value that multiplier will be.
> > >
> > > Patrik, did you test the responsiveness of the server using multiple
> > > probes with the correct password, or was there some mysterious net-fu
> > > of yours at play? I'm asking because AFAIK the only way to find if a
> > > password is wrong is a timeout on a socket (no returned response), so
> > > we can't reliably test the snmp-brute script itself, but we can test
> > > the servers throughput.
> >
> > Yes, as far as I can tell the only way of determining whether a probe was correct or not is to wait for a) an answer 
> > or b) a timeout.
> > I didn't get very far in testing concurrent probes and server responsiveness.
> > I only did some limited testing and realized that it would be possible to run a number of parallel probes that I 
> > could wait on simultaneously.
> > Like I mentioned in my post, I moved on to SIP instead as my goal was really to implement an UDP based brute script.
> > If you need help testing, feel free to send me your current script. I have some virtual machines running SNMP I can 
> > test against.
> >
> > //Patrik
> > --
> > Patrik Karlsson
> > http://www.cqure.net
> > http://www.twitter.com/nevdull77
>
>
>
> -- 
> Gorjan
> <test.nse>

--
Patrik Karlsson
http://www.cqure.net
http://www.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/