Re: DNS fuzzer

[Michael Pattrick <mpattrick () rhinovirus org>]

On Fri, Apr 2, 2010 at 4:33 PM, David Fifield <david () bamsoftware com> wrote:
> On Mon, Mar 29, 2010 at 03:38:17PM -0400, Michael Pattrick wrote:
> > On Mon, Mar 29, 2010 at 1:11 PM, David Fifield <david () bamsoftware com> wrote:
> > > On Sat, Mar 27, 2010 at 03:19:02AM -0400, Michael Pattrick wrote:
> > > > On Fri, Mar 26, 2010 at 8:46 PM, David Fifield <david () bamsoftware com> wrote:
> > > > > On Sun, Mar 21, 2010 at 07:28:14PM -0400, Michael Pattrick wrote:
> > > > > > I've been playing with Bind10 lately, I wanted to incorporate fuzz
> > > > > > testing in the mix but could only find one DNS fuzzer[0]. It didn't
> > > > > > really suit my needs and was closed source so I wrote my own. Attached
> > > > > > is my fuzzer.
> > > > > >
> > > > > > It's a very naive fuzzer and hasn't found any flaws yet, so I'd
> > > > > > appreciate feedback on it or suggestions on how such a fuzzer could be
> > > > > > improved.
> > > > >
> > > > > Your script needs some more documentation. I can't tell what it does
> > > > > from just looking at it. In your "description" field, explain at a high
> > > > > level what the script is doing and how many packets it's sending.
> > > >
> > > > New version, with docs, attached.
> > >
> > > Thanks, this is good.
> > >
> > > > > I understand that since you may be making broken packets, you can't use
> > > > > the dns library for everything, but if you find a place where you can
> > > > > make use of it then you should.
> > > >
> > > > The DNS library doesn't appear to support sending compressed DNS
> > > > queries. The basic operation of this fuzzer is to induce bit errors.
> > > > Sort of like the 'dumb fuzzers' described by Charlie Miller and used
> > > > to win this years Pwn2Own.
> > > >
> > > > And just to clarify, I don't think this script should be included by
> > > > default with Nmap. Instead I'm leaving it on the mailing list to be
> > > > discovered by anyone who needs it.
> > >
> > > On the contrary, I think there is a place for scripts like this. "vuln"
> > > category works even though it's testing for a general, not a specific
> > > vulnerability.
> > >
> > > I'd like to include this script if it can be made not to run forever,
> > > instead running some fixed number of rounds (controlled by a script
> > > argument).
> >
> > I've added the option to limit how long this script runs for in
> > minutes. Unlimited runtime is still available.
> >
> > > I would like to see other fuzzing techniques too, though of
> > > course those can be added incrementally. I'm thinking something like 100
> > > rounds each of:
> > >
> > > * Randomly swap bits (like you have now).
> > > * Randomly drop bytes.
> > > * Randomly duplicate bytes.
> > > * Randomly swap bytes.
> > > * Truncate packets at a random location.
> > >
> > > Plus:
> > >
> > > * A standard battery of invalid compressed names.
> >
> > I'll have to think about those suggestions a bit more and perhaps some
> > up with my own new modes.
>
> I ran this against the server in my DSL router, which is dproxy.
> The server didn't really crash in any of these cases. This server
> doesn't respond to version detection. Probably, the script should send
> an initial uncorrupted packet, and only start fuzzing if it receives a
> response.
Interesting, I had only envisioned usage against non-recursive
servers, although I guess adding recursive support wont hurt. I've
added support for servers which only respond to recursive requests.

> I'm concerned about the lag between the packet that stops the server
> stops responding. The script requires three non-responses before it
> reports the offending packet, but it changes the packet in between each
> non-response. The packet that's printed is not the one that caused the
> server to crash, but one even further corrupted. That's going to make it
> harder to find the source of a bug. What the script should do, when it
> gets a non-response, is to keep sending the same packet three times.

You raised some very good points here, however, I disagree that I
should send the same packet because some corrupt DNS packets illicit
no response. This is why I added the three strike rule, although, as
you point out, how I implemented it was flawed. Perhaps it would be
better to send a non corrupted DNS packet to 'ping' the server. Doing
so would also solve the first problem that you mentioned as well.

> Let's change the name of the script argument "fuzztime" to "timelimit".
>
> Other scripts take time arguments in seconds, not minutes. It's not the
> best for this script but I'd like it if you make this script work that
> way too. In the future we should have a standard function for parsing a
> time specification like "60s" or "1m".

I have implemented it to stay consistent with the new argument name,
but I don't think it works well... No one would be running a fuzzer
for less then one minute.

> Running without the dns-fuzz.fuzztime argument gives
> 53/udp open|filtered domain  no-response
> | dns-fuzz-2: Cannot fuzz for zero minutes, please enter a valid length of time to fuzz for.
> |_Or -1 to fuzz for an unlimited amount of time.
> Other scripts have the convention that 0 means unlimited. In case the
> script argument is not specified, use a default limit of 10 minutes.

That's by design, to prevent the script from being run accidentally.

Now I plan on adding support for different modes of corruption.

-M

Attachment: dns-fuzz.nse
Description:

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