Nmap Development mailing list archives
Re: GSoC 2011: NSE Script Development
From: Toni Ruottu <toni.ruottu () iki fi>
Date: Sun, 3 Apr 2011 17:04:41 +0300
On Sun, Apr 3, 2011 at 3:58 PM, Gorjan Petrovski <mogi57 () gmail com> wrote:
On Sun, Apr 3, 2011 at 2:25 PM, Toni Ruottu <toni.ruottu () iki fi> wrote:Looks good! Are we currently doing TYPE_SYSLISTPASSWORDS? That seems useful.Thanks for the reply, you reminded me of some things I neglected to mention. I experimented with TYPE_SYSLISTPASSWORDS but it crashes the server on my instalation (Windows 98 SE) if there are no cached passwords present (while screen server is running?), and I couldn't get it to work when I did have passwords, so I chose not to add it. Is this right?
Maybe it only works on older flavors of Windows. If it crashes the server we should not add it to the info script. If we knew it worked on some systems we could create another script that is not run by default. Or maybe we could find a way to check whether the remote system supports this feature, and add it to the info script. I am not sure how important this is. I guess seeing leaked passwords is useful, but crashing servers is not very helpful. :-)
You might want to create a separate backorifice-ls script to list contents of the/some root directory by using TYPE_DIRECTORYLIST.I like that idea. Once basic communication of the script with the server is established it would be very easy to write new scripts which send different commands. I'm working on this now.
You need to check if backorifice can handle multiple simultaneous users. Otherwise you need to figure some way of doing mutual exclusion. You could also do a backorifice-brute script that tests passwords against a password protected backorifice server. You can not use the brute library, as it is connection based, but you can (and should) use the unpwdb library. See netbus-brute for example. We discussed UDP brute scripts a while ago. See http://seclists.org/nmap-dev/2011/q1/973
What about TYPE_REGISTRYENUMKEYS and TYPE_REGISTRYENUMVALS? Are they useful? Do they dump too much information?Since TYPE_REGISTRYENUMKEYS and TYPE_REGISTRYENUMVALS are commands for working with the Windows Registry, I thought these could be useful for getting specific pinpointed system info which we could be interested in (ex. processes that run on startup) instead of listing general contents.
Sounds good.
Another thing you might want to experiment with, is the integrated http server. This should not go into the same script as it is a different service. At least we could check what nmap's service scan returns for it. If it seems like a computer interface more than a human interface, we could add a separate script for it.Will do. I'll reply when I have something useful.
great!
cheers, --ToniRegards :-) GorjanOn Sun, Apr 3, 2011 at 8:20 AM, Gorjan Petrovski <mogi57 () gmail com> wrote:I had some small problems with the virtual machine networking which is now resolved. The Unix BackOrifice client Vlatko gave me is very stable. Thanks a lot! I tested all of the features mentioned on the wiki page with the client except the plugin listing, since I couldn't find plugins but I'll continue looking. Any comments about the wiki page or my line of reasoning there is gladly welcomed. This is more of a general outline which could easily be adapted once I have a somewhat functional script. http://secwiki.org/w/Nmap/Script_Ideas#backorifice-info On Sat, Apr 2, 2011 at 9:54 PM, Toni Ruottu <toni.ruottu () iki fi> wrote:If there is some particularly long listing you might want to have a separate script for that one and limit default output like quake3-getservers and gopher-info do. Otherwise I'd say just write it first. It is always easier to work on details once we see how it looks in practice. On Sat, Apr 2, 2011 at 10:40 PM, Gorjan Petrovski <mogi57 () gmail com> wrote:I've been looking through the commands that the client can send and it seems that the info script output is going to be very long. There are many commands which if successful, would produce valuable information (ex. system passwords, running processes). I'm still selecting which information would be included in the output, but I had to ask, is there a maximum preferred length for the script output? On Sat, Apr 2, 2011 at 7:14 PM, Gorjan Petrovski <mogi57 () gmail com> wrote:Sorry I didn't answer sooner, I'm getting right on it. On Thu, Mar 31, 2011 at 3:32 PM, Toni Ruottu <toni.ruottu () iki fi> wrote:The output will probably be somewhat similar to that of netbus-info. See the example output at http://nmap.org/nsedoc/scripts/netbus-info.html There is no need to copy the categories from netbus-info. Just use what ever makes most sense with backorifice. On Thu, Mar 31, 2011 at 2:12 AM, David Fifield <david () bamsoftware com> wrote:On Wed, Mar 30, 2011 at 09:10:53PM +0200, Gorjan Petrovski wrote:Hello, I have experimented somewhat with the Windows and Unix backorifice client, and found out that the Unix client is constantly crashing the server. I'll use the Unix client source code for reference(for crypto, etc.), however I'm gonna base most of the script on the Wireshark analyses of the Windows client.Gorjan, could you edit the Script_Ideas page and fill in examples of the kind of information that a backorifice-info script would be able to find. It's a good idea but the description could be better. The best is if you can include some sample output, wihch the script will look like when it is finished. I'm assuming you already know about the protocol and what its capabilities are; if you are still learning and don't know yet, then don't worry about it. David Fifield _______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
_______________________________________________ Sent through the nmap-dev mailing list http://cgi.insecure.org/mailman/listinfo/nmap-dev Archived at http://seclists.org/nmap-dev/
Current thread:
- Re: GSoC 2011: NSE Script Development Gorjan Petrovski (Apr 02)
- Re: GSoC 2011: NSE Script Development Gorjan Petrovski (Apr 02)
- Re: GSoC 2011: NSE Script Development Toni Ruottu (Apr 02)
- Re: GSoC 2011: NSE Script Development Gorjan Petrovski (Apr 02)
- Re: GSoC 2011: NSE Script Development Toni Ruottu (Apr 03)
- Re: GSoC 2011: NSE Script Development Gorjan Petrovski (Apr 03)
- Re: GSoC 2011: NSE Script Development Toni Ruottu (Apr 03)
- Re: GSoC 2011: NSE Script Development Gorjan Petrovski (Apr 04)
- Re: GSoC 2011: NSE Script Development David Fifield (Apr 04)
- Re: GSoC 2011: NSE Script Development Gorjan Petrovski (Apr 05)
- Re: GSoC 2011: NSE Script Development Gorjan Petrovski (Apr 06)
- Re: GSoC 2011: NSE Script Development Toni Ruottu (Apr 06)
- Re: GSoC 2011: NSE Script Development Toni Ruottu (Apr 06)
- Re: GSoC 2011: NSE Script Development Gorjan Petrovski (Apr 06)
- Re: GSoC 2011: NSE Script Development Gorjan Petrovski (Apr 06)
- Re: GSoC 2011: NSE Script Development David Fifield (Apr 06)
- Re: GSoC 2011: NSE Script Development Gorjan Petrovski (Apr 06)
- Re: GSoC 2011: NSE Script Development Toni Ruottu (Apr 02)
- Re: GSoC 2011: NSE Script Development Gorjan Petrovski (Apr 02)