Re: POC Payloader dat

[David Fifield <david () bamsoftware com>]

On Mon, Nov 23, 2009 at 12:04:57PM -0500, Jay Fink wrote:
> Attached is a very minimalist parser to change keeping payload data in
> the payload.cc file. In this example (which is not in the nmap tree) I
> am using a very simple parameter retrieve ; in the example were just
> getting and printing the DNS Request payload - but I think I can
> implement this in nmap - just wanted to get some thoughts on it.
> Eventually the way it would work is the case in payload.cc now would
> simply read in the value from payload.dat (or db et cetera).  It needs
> work like better dynamic allocation etc. but this is a POC idea right
> now.

Thank you for starting work on this. Having the payloads in a separate
data file is indeed a goal. Not only would it make it possible to add
payloads without recompiling, but it would allow people to easily
disable payloads they don't like.

There are some things to be considered for the data file format. The
contents of the data file you sent are
        DNS_STATUS_REQUEST "\x00\x00\x10\x00\x00\x00\x00\x00\x00\x00\x00\x00"
There is more information that should be stored in the data file. In
this case, Nmap still has to know that DNS_STATUS_REQUEST corresponds to
port 53/udp, and to change it would require recompiling.

We can learn from Unicornscan's payloads.conf. I think they have a good
format. An example entry looks like this:

/* citrix */
udp 1604 -1 1 {
        "\x20\x00\x01\x30\x02\xfd\xa8\xe3\x00\x00\x00\x00\x00\x00\x00\x00"
        "\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"
};

The five fields are protocol (udp or tcp), destination port, source
port, payload group, and { payload }. -1 for the source port means any
port can be used. I don't know what the payload group means.

This is a good format. Its biggest deficiency is that you have to copy
and paste if you want the same payload on different ports. We already
have one case of that in payload.cc. It is expressed very nicely in C++:

    /* RFC 2865: "The early deployment of RADIUS was done using UDP port number
       1645, which conflicts with the "datametrics" service. The officially
       assigned port number for RADIUS is 1812. */
    case 1645:
    case 1812:
      SET_PAYLOAD(payload_radius);
      break;

The symbolic names (payload_DNSStatusRequest, payload_radius) are an
implementation detail and there's no reason to keep them in an external
data file.

Here is a list of desiderata for the ideal payload definition file
format.

  * Uses the C string syntax like payloads.cc or nmap-service-probes.
  * Allows comments at least as expressive as what are in payload.cc.
    (This includes comments between the bytes of a payload.)
  * Lets several ports share the same payload without redundancy.
  * Allows indicating if a payload should come from a specific source
    port. For example, our payload_ike works better coming from 500.

And here are some bonus items that would make it even better.

  * Allows variable payloads through simple substitutions (for example
    an IP address or 8 bytes of random data). Our payload_ike uses a
    constant initiator cookie, but in my testing this causes targets not
    to respond to any probes after the first. It would be great if we
    could fill the first 8 bytes with random data instead. I wouldn't be
    totally happy with a format that made this impossible.
  * Allows indicating if the response will come from a port other than
    the one the probe was sent to. A TFTP server sends its responses
    from a random ephemeral port, not the tftp port. If you use
    Unicornscan's TFTP payload and do a -p1-65535 scan of a TFTP server,
    you get the tftp port open|filtered but a random high port open,
    which is not what you want. This is a tricky problem and hasn't been
    fully specified.

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