Re: [NSE RFC] MS RPC libraries

[Ron <ron () skullsecurity net>]

David Fifield wrote:
> On Sat, Sep 27, 2008 at 04:00:31PM -0500, Ron wrote:
> It's great to see so much development going on in this area. As usual,
> the code looks good and the documentation is outstanding. I tried the
> new scripts against a Windows XP machine, but all I got was
>         Host script results:
>         |_ MSRPC: List of user accounts: ERROR: NT_STATUS_ACCESS_DENIED
>         |_ MSRPC: NetShareEnumAll(): ERROR: NT_STATUS_ACCESS_DENIED
>         |_ MSRPC: List of user accounts: ERROR: NT_STATUS_ACCESS_DENIED
>         |_ MSRPC: List of domains: ERROR: NT_STATUS_ACCESS_DENIED
> as you mentioned. I would like to hear from others who can try them
> against suitable machines. To install the scripts, download nmap-smb_tgz
> from http://seclists.org/nmap-dev/2008/q3/1007.html, then
>         cd nmap
>         tar xzf --strip-path 1 ../nmap-smb_tgz
>         make install
>         nmap --script-updatedb
>         nmap --script=smb-msrpc-bruteusers.nse,smb-msrpc-enumdomains.nse,smb-msrpc-enumshares.nse,smb-msrpc-enumusers.nse 
> <target>
>
> Here are my observations and suggestions for the new scripts and
> libraries.
>
> Currently the four new scripts (smb-msrpc-bruteusers.nse,
> smb-msrpc-enumdomains.nse, smb-msrpc-enumshares.nse,
> smb-msrpc-enumusers.nse) work only against Windows 2000. Is that because
> of a lack of authentication? Will all four work against other versions
> of Windows when authentication is in place?
Yes, Windows XP and higher don't let anonymous users make these kinds of 
queries. My next big change is going to be adding authentication, but 
I've been dragging my feet on that a bit.

All four will work against everything up to Vista when all's said and 
done (I currently have it implemented in C, and it works fine).

> Can you summarize the amount of overlap between all the new
> SMB/NetBIOS/MSRPC scripts? There are
>
>         nbstat.nse
>         smb-enum.nse
>         smb-msrpc-bruteusers.nse
>         smb-msrpc-enumdomains.nse
>         smb-msrpc-enumshares.nse
>         smb-msrpc-enumusers.nse
>         smb-os-discovery.nse
>         smb-security-mode.nse
>
> It appears to me that smb-enum, smb-msrpc-bruteusers, and
> smb-msrpc-enumusers all enumerate users, for example, though they do it
> in different ways. Is there a way scripts with the same purpose could be
> combined into one, and the total number of scripts reduced? I don't know
> anything about these protocols. If I wanted a list of users, I wouldn't
> know which script to pick.
There's definitely some overlap between the users ones. I agree that 
combining them is a good idea. enumusers will get the most information 
about is most likely to fail. bruteusers will try to reverse-lookup 
common RID values (500, 501, 1000+) to the equivalent users. This will 
work on more systems (older versions of XP and 2k, I think), but still 
not on everything. The only other option to enumerate users would be to 
try logging in, but that could create a DoS so I'm not going to 
implement it.

smb-brute and smb-msrpc-enumshares also overlap, they both attempt to 
enumerate shares. They can also likely be combined.

The scripts I've written so far are largely to demonstrate the 
functionality, I hadn't really thought about how to logically group 
them. But I'll definitely look at combining ones with similar 
functionality.

> It looks like this comment didn't get changed with the code:
>
>         -- It's possible that the mutex wouldn't be created if there was an erro
> r condition. Therefore,
>         -- I'm calling 'trylock' first to ensure we have a lock on it. I'm not s
> ure if that's the best
>         -- way to do this, though...
> -       mutex "trylock"
> +       stdnse.print_debug(3, "SMB: Attempting to release SMB mutex (4)")
>         mutex "done"
> +       stdnse.print_debug(3, "SMB: SMB mutex released (4)")
Good call. Having to use 'trylock' was a hack, I'm glad I figured out 
why I was getting an error there.

> I would prefer to see the smbconstants.lua code folded into smb.lua,
> rather than being its own module. All the constants could be entered
> into a table, so instead of typing smbconstants.SMB_COM_NEGOTIATE you
> would type smb.constants.SMB_COM_NEGOTIATE. Or the SMB_COM_* and
> NT_STATUS_* constants could be broken into different tables.
>
> About half the length of smbconstants.lua is the long if..elseif in
> error_to_string. It could be made much shorter by having it use an
> inverse table. If you have a table mapping names to numbers, you just
> turn it around to map numbers to names. There's an example of creating
> an inverse table at http://www.lua.org/pil/4.3.5.html. There's something
> similar in msrpc.lua.
Cool, didn't know that was possible! I still have a lot to learn with Lua.

There are still a whole lot of constants to scroll past, even if they're 
only done once. But I'll see how it looks.

Thanks for taking a look!

> David Fifield
>
> _______________________________________________
> Sent through the nmap-dev mailing list
> http://cgi.insecure.org/mailman/listinfo/nmap-dev
> Archived at http://SecLists.Org

_______________________________________________
Sent through the nmap-dev mailing list
http://cgi.insecure.org/mailman/listinfo/nmap-dev
Archived at http://SecLists.Org