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

[Daniel Miller <bonsaiviking () gmail com>]

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/