Nmap Development mailing list archives
Re: Nmap + Ncat + /dev/urandom = tarpit
From: Nick Marsh <nmarsh1980 () gmail com>
Date: Sat, 4 Apr 2015 10:22:59 -0500
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/
Current thread:
- Nmap + Ncat + /dev/urandom = tarpit Nick Marsh (Apr 03)
- Re: Nmap + Ncat + /dev/urandom = tarpit Daniel Miller (Apr 04)
- Re: Nmap + Ncat + /dev/urandom = tarpit Nick Marsh (Apr 04)
- Re: Nmap + Ncat + /dev/urandom = tarpit Dave Horsfall (Apr 06)
- Re: Nmap + Ncat + /dev/urandom = tarpit Daniel Miller (Apr 04)