Re: DNS fuzzer

[David Fifield <david () bamsoftware com>]

On Fri, Apr 02, 2010 at 07:01:56PM -0400, Michael Pattrick wrote:
> On Fri, Apr 2, 2010 at 4:33 PM, David Fifield <david () bamsoftware com> wrote:
> > 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 have to apologize; looking at my Bash history I was running against
the wrong IP address. The one I ran against didn't have a DNS server
running. But the results are the same with the correct IP address.

PORT   STATE         SERVICE REASON
53/udp open|filtered domain  no-response
| dns-fuzz-1: Server stopped responding... He's dead, Jim.
|_Offending packet: 
0x1126000000020000000000000773636274727667066e616e66696f04647a6a79076a6b757a79776e0000010001056876676a7807627467756768690570777574770372726ec00c00050001

PORT   STATE         SERVICE REASON
53/udp open|filtered domain  no-response
| dns-fuzz-2: Server stopped responding... He's dead, Jim.
|_Offending packet: 0xd2da0000000100000000000007716d687667737904646d69630000010001

With the latest version (which I'm calling dns-fuzz-3 here), I get

PORT   STATE         SERVICE REASON
53/udp open|filtered domain  no-response
|_dns-fuzz-3: Server is not a DNS server

PORT   STATE SERVICE REASON
53/udp open  domain  udp-response
| dns-fuzz-3: Server stopped responding... He's dead, Jim.
|_Offending packet: 
0xdca6000000020000000000000561752d706b06777174666f6d0773796d716a706f00000100010370726406656169726d6a057a7a767476056e62617a79c00c00050001

Running the script seven times, I only got the offending packet once.
The other times it was "Server is not a DNS server". I'm starting to
think it's just this proxy being weird. With Wireshark I saw that I had
to increase the timeout to 5 seconds to get a server failure. If I run
directly against my ISP's DNS server, it's

PORT   STATE         SERVICE REASON
53/udp open|filtered domain  no-response
| dns-fuzz-3: Server stopped responding... He's dead, Jim.
|_Offending packet: 
0x7811000040020000000020000770626d7173696d0e7a6e78636a68076d69716c6477690000010001057966616c670568776f746dc00c00050001

But here it's different; the server is sending a response to the
pingServer query (server status), but later sends of the same query
don't get a response. It looks like the server is rate-limiting. I
thought it was because of the constant transaction IDs, but I randomized
them and it didn't make a difference.

The dproxy server is finicky; I can't get it to respond to server status
every time, only sometimes. It's too bad, because it would be a good
fuzzer target. There's a remote root exploit in a version recent enough
to be on my router: http://seclists.org/fulldisclosure/2007/Mar/552.

So, ignoring these server-specific difficulties, the logic for pinging a
server and printing the correct crashing packet looks right. My advice
is to remove the recursiveOnly code, because I don't think that was
really the problem, and replace the message "Server is not a DNS server"
with "Server didn't response to liveness probe, can't fuzz". Increase
the timeout when doing the liveness check. If someone's fuzzing for an
hour, it's not unreasonable to wait 30 seconds after the server appears
to stop responding. Even if some servers are making it hard, I think the
script is far enough along that once you've made these changes we can
commit it and refine it from there.

One other thing: would you add a short description of the fuzzer
category to scripting.xml? It's the part that corresponds to
http://nmap.org/book/nse-usage.html#nse-categories.

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