Re: POC Payloader dat

[David Fifield <david () bamsoftware com>]

On Wed, Dec 30, 2009 at 09:48:52AM -0500, Jay Fink wrote:
> > > I'm a bit lost in thinking about how all this should work. How do
> > > Unicornscan's payload groups work?
>
> It would appear they class payloads - I am still working on
> unravelling the groups but I did discover by tracing back through the
> code that unicornscan does have multiple payloads for the same service
> - it essentially cycles through each one until it gets a hit.
>
> So - basically - I am still investigating but what I see so far is
> that unicornscan:
>
> - can share payloads/service but not ports (how ironic is that?); they
> get around the ports problem in a similar way to nmap

I don't know what you mean. What is the ports problem? I also don't
understand the distinction between "service" and "port" here. We're not
concerned at all with "service" in terms of -sV at this point in the
scan.

> - at some point iterates and loads up needed payloads - I think this
> is at the beginning of every send packet; not sure yet
> - has an option *not* to use default payloads
> - has some builtin (as in the source code not a file) payloads (I am
> assuming these are defaults) and some stored in a conf file

I didn't know there were builtin ones. We already went through
payloads.conf and used or modified the ones that 1) we could show to be
safe, and 2) were for common ports (top 1,000 I believe). There might be
some worth investigating among the builtin ones.

> - uses a module framework for handling payloads
> - uses a key do identify the payload (similar to what we want to do)

Having a name for each payload is fine, as it's a reasonable way to
distinguish multiple payloads for the same port. But don't stress out
about that too much. The internal API doesn't even have to be aware of
it as we would have no way to use it yet.

> I think we can definitely do the following:
> - use a keyword to share payloads
> - have multiple ports per service (already planning on it)

I don't understand what you mean by "share payloads." Isn't that what
we're already doing with the "1645,1812" in

radius udp 1645,1812 "\x01\x00\x00\x14"
  "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"

> The questions I have now are:
> - is there a chicken and egg problem? We know for instance if a host
> does not reply to the pre-ping we just move on but what if the scan is
> a full tcp-connect/port? Do we still iterate through every payload or
> shut it off in that case or shut it off by default but allow user
> override?

If I undertand you correctly, you want to know, if there are mutiple
payloads for a port, whether all of them should be tried or just the
first one. Let's forget that complexity for now. I'm fine with the data
format being extensible to allow multiple payloads per port but at the
moment we don't need it and don't even know how it should work.

At this stage I don't want any changes to the scanning engine. Let's
keep it simple--all we need is a new implementation of get_udp_payload
that reads from an external data file.

> - when should we load payloads? I am thinking as soon as we know what
> ports we are scanning load em up into a table then (using a similar
> method to how we get them now)  call them when needed... performance?
> :)

I think it's reasonable to load them into memory in advance. I mean,
they're in memory now, being part of the executable.

> - should we have an option not to use payloads and/or to have some
> "safe defaults"? I think this is a good idea since later on we can
> start adding more payloads; some of which I am sure  will be a little
> *sketchy*.

You can already turn off payloads with --data-length 0. (Or any
--data-length.) I don't want any sketchy payloads being sent during a
ping or port scan; that's for version detection and NSE. There's a
comment at the top of payload.cc with the safety criteria for UDP
payloads.

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