Re: GSoC 2011: NSE Script Development

[Gorjan Petrovski <mogi57 () gmail com>]

On Wed, Apr 6, 2011 at 6:09 PM, Toni Ruottu <toni.ruottu () iki fi> wrote:
> Note that after moving to portrule, you get the port information as
> the second parameter of action.

Yes, thanks, I've been using your netbus-info amongst other scripts as
a helpful reference. I'm currently trying the shortport lib like this:
portrule = shortport.port_or_service (31337, {"BackOrifice","unknown"}, "udp")
but the script won't run if I run it against a service on another udp
"open|filtered" port.


> On Wed, Apr 6, 2011 at 5:55 PM, Toni Ruottu <toni.ruottu () iki fi> wrote:
> > > A quick use command:
> > > nmap -sn -Pn --script ./backorifice-info.nse --script-args
> > > 'backorifice-info.port=<port_number>,backorifice-info.password=<password>'
> > > <target>
> >
> > The usage should be:
> > nmap -sU -p 31337 --script backorifice-info <target> --script-args
> > backorifice-info.password=<password>
> >
> > ./ and .nse are not needed in the script name, and you should use sU
> > which actually initiates a UDP scan against the port. To make this
> > work you need to modify your script to use portrule instead of
> > hostrule. You want to use the shortport library.
> >
> > require("shortport")
> > portrule = shortport.port_or_service (31337, "BackOrifice", "udp")
> >
> > This means that the script will get executed whenever open udp port
> > 31337 is discovered, but also if some other open udp port is
> > identified as BackOrifice. Please verify the service name by doing
> > nmap -sU -sV -p 31337 <target>, and see what nmap returns as the major
> > service name.
> >
> > You should remove the hostrule, as this script is executed against
> > ports, and not against hosts.
> >
> > > The sample output is copied directly from console. As you can see the
> > > output is not formatted yet, however I've organized the script so that
> > > adding more commands, and formatting the output should be pretty
> > > simple (adding rows to the "cmds" table and a formatting function).
> > > I'm going to do this right after this mail is sent.
> >
> > There is a standard function that does the formatting. See netbus-info
> > for example.
> >
> > > If there is no information about a certain category (ex. no plugins
> > > installed), should the script return no information at all in that
> > > category, or should it return info that there are no plugins
> > > installed?
> >
> > I think it would make sense to show the category although I do not
> > remember what netbus-info does, and it would be good to hear a second
> > opinion. I think it is useful to see what kind of information could be
> > available.
> >
> > > The BackOrifice service listens on a UDP port and every packet is
> > > encrypted, even if a password is not supplied. The service is easily
> > > configurable to any port and any password, so the only way to reliably
> > > detect it would be to send an encrypted command with the correct
> > > password to the specific port. Currently the script gets the port
> > > number as an explicit argument and it just doesn't feel right. Having
> > > these things in mind, should I tie it to a portrule with the default
> > > port - 31337, as well as a hostrule?  Should I tie it to OS detection?
> >
> > portrule yes, hostrule no, os detection no
> > The server could be running under wine on Linux and in a virtual
> > machine in an Apple. In some cases the service can still be detected.
> >
> > Use case:
> > The admin knows that port 80 is open in the company firewall. He
> > suspects someone is running a hidden back orifice service on port 80.
> > The admin runs backorifice-brute against udp port 80. The hacker used
> > an easily guessable password like "123abc". bakcorifice-brute gets a
> > response to a probe, and records version information. backorifice-info
> > gets executed because of the version detection backorifice-brute did.
> >
> > I also wonder if it would make sense to send the default encrypted
> > ping for no password as a version detection probe to some ports. What
> > ports? I am not an expert on the version detection, so someone else
> > might need to look at this.
> >
> > > Which categories should I add it to?
> >
> > categories = {"default", "discovery", "safe"}
> >
> > > I'll update the Script_Ideas page with the output as soon as I define it.
> > >
> > > Cheers,
> > > Gorjan
> > >
> > > On Tue, Apr 5, 2011 at 4:04 PM, Gorjan Petrovski <mogi57 () gmail com> wrote:
> > > > Thanks. I actually got it working with a small optimization before I
> > > > checked my mail. Sorry for the fuss.
> > > >
> > > > On Tue, Apr 5, 2011 at 5:36 AM, David Fifield <david () bamsoftware com> wrote:
> > > > > On Tue, Apr 05, 2011 at 04:31:20AM +0200, Gorjan Petrovski wrote:
> > > > > > I'm currently implementing the encryption for the backorifice-info
> > > > > > script, and I have a problem with the multiplication of numbers which
> > > > > > are too large for lua. Is there currently a workaround for that kind
> > > > > > of problem in Nmap, like lua-bc
> > > > > > http://penlight.luaforge.net/packages/lbc.html , or should I just hack
> > > > > > around some kind of multiplication function which will do the trick
> > > > > > for me?
> > > > >
> > > > > There are bignum routines in the openssl library. Unfortunately I don't
> > > > > see a multiply function, but that's probably because we just haven't
> > > > > defined a binding to it. So I would say, see if you can add a binding in
> > > > > nse_openssl.cc (you can probably mostly copy the l_bignum_add function).
> > > > >
> > > > > 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/