Re: Nmap + Ncat + /dev/urandom = tarpit

[Nick Marsh <nmarsh1980 () gmail com>]

I know programmers hate hard coding limits. I wonder if tarpit defense is
something that should be considered for the NSE in the future. Maybe
checking for malformed responses and handling them as untrusted and then
applying sane limits based on that condition. That still doesn't solve all
the problems, but it might be a good thing to have regardless.

Something else to consider, the other scripts ran pretty quickly. The
responses came rapidly until I hit whatever scripts needed to recv_all. If
the NSE was able to detect that one particular script has gotten caught up,
maybe there could be some logic to handle that condition.

I hate spouting out uninformed ideas, so I'll shut up now. This is all
fascinating to me and I appreciate the background info you provided.

PS. I just found by accident that there is already a http cache maximum of
1000000 bytes when I ended the ncat listener early (see message below). It
doesn't appear to be enforced because it blew past it.

NSE: Current http cache size (163923996 bytes) exceeds max size of 1000000
NSE: Finished http-robots.txt against 10.10.4.47:8080.
NSE: Current http cache size (163966028 bytes) exceeds max size of 1000000
NSE: Finished http-git against 10.10.4.47:8080.
NSE Timing: About 69.57% done; ETC: 21:21 (0:06:50 remaining)
NSE: Current http cache size (164095804 bytes) exceeds max size of 1000000
NSE: http-cors against 10.10.4.47:8080 threw an error!

On Sat, Apr 4, 2015 at 8:35 AM, Daniel Miller <bonsaiviking () gmail com>
wrote:

> Nick,
>
> Thanks for catching this. The problem area is in the http NSE library, in
> the recv_body function, which calls recv_all if there is no information
> from the HTTP headers about the size of the response body. This is
> compliant with the HTTP spec, but probably not the safest way to do things
> (as you found out!).
>
> We could put a limit on the size of response (128MB perhaps) that is
> received in this way. Then we would need some way to inform the calling
> script that the limit was reached (and the response is incomplete).
> Unfortunately, this is not the end of the trouble that could be caused:
>
> 1. The server could return a slow response, 1 byte at a time for
> gigabytes. This doesn't hurt us as much (since we won't run out of memory
> as quickly), but does make the script take forever. This would partially be
> solved by the size limit above, but we could also impose a time limit on
> responses.
>
> 2. The server could reply with infinite headers instead of an infinite
> body, so we'd have to put a limit there, too: ncat -lkv -p 8080 --sh-exec
> "echo 'HTTP/1.1 200 OK\r'; yes 'Foo: Bar'"
>
> 3. Lots of other services could be turned into tarpits in this way; any
> time we loop over a socket receive without a termination condition other
> than a socket error.
>
> Dan
>
> P.S. I've thought over similar tarpit scenarios for HTTP in the past; the
> outcome was my TarPyt project, which focuses on slowing down or ensnaring
> web spiders without infinitely tying up server resources:
> https://github.com/bonsaiviking/TarPyt
>
> On Fri, Apr 3, 2015 at 9:06 PM, Nick Marsh <nmarsh1980 () gmail com> wrote:
>
> > I was having fun with Ncat and wanted to see if I could create a tarpit
> > and throw Nmap for a loop. My plan was to cat /dev/urandom on a http port.
> > It worked on the first try. Not sure if this is the expected behavior, but
> > I though I would throw this out there just in case. Steps to reproduce
> > below.
> >
> > # Target
> > ncat -lkv -p 8080 --sh-exec "echo 'HTTP/1.1 200 OK\r\n'; cat /dev/urandom"
> >
> > # Scan
> > nmap -A TARGET
> > nmap -sC TARGET
> >
> > # Result
> > In both cases, Nmap uses up all the available RAM on the system and dies.
> > Tried this on 6.40 and 6.47 Linux and Windows respectively. The Linux box
> > exits with code 137. The Windows box throws Application Error 0xc0000005.
> >
> > _______________________________________________
> > Sent through the dev mailing list
> > https://nmap.org/mailman/listinfo/dev
> > Archived at http://seclists.org/nmap-dev/
_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/