Re: Always practice safe software: a lesson from UnrealIRCd

[David Fifield <david () bamsoftware com>]

On Fri, Jun 25, 2010 at 10:27:02AM -0600, David Fifield wrote:
> On Thu, Jun 24, 2010 at 10:05:04AM -0500, Ron wrote:
> > The attached version of the code, in my testing, had no false
> > positives and no false negatives. The downside is, it's incredibly
> > slow. 
> >
> > A mutex + 10 second delay and 20 second timeout had 5 good, 1 false
> > positive. A mutex + 25 second delay + 35 second timeout = perfect, 5
> > out of 5 on my test list with no false positives/negatives. So
> > basically, 25 seconds for every infected host, 35 seconds for every
> > host that times out, and basically no time for hosts that aren't
> > affected either way. 
>
> Ron, please commit this as it stands. It is very very slow but it seems
> to be accurate. In my test I got 7 servers correctly detected, with 4
> false positives, in 4 hours. I will send you the list of hosts I found
> off-list.
>
> The timing data are being corrupted by the time taken for the remote
> server to do reverse DNS and ident lookups. One server I saw has a
> 36-second timeout on ident lookups, which makes it a false positive. I'm
> testing a version that receives all the server's initial banner
> (including host name and ident lookups) before sending the AB command
> and starting the timer. But I think the script is ready to be added to
> revision control now.

I just committed (r18508) the revisions I planned to make to the script.
These greatly improve its speed and slightly increase its accuracy.

The main obstacle was that most servers run a reverse-DNS lookup and
ident lookup, and don't process any commands until those have timed out.
The timeouts were being included in the total time recorded by the
script, so the times were longer than they should have been. If the
timeouts were long enough, a server would appear to be vulnerable even
if it wasn't.

I got around this by first sending a dummy command (TIME) immediately
upon connection. When we get a response to TIME (":hostname 451 TIME
:You have not registered"), then we start the timer and send the "AB"
sleep command. I reduced the delay to 8 seconds, and here is the
distribution of times I found:

  0 
####################################################################################################################################################################################################################################################################################
  1 ########################################
  2
  3
  4
  5
  6
  7
  8 ####
  9 ##

Each # is two hosts. You can see these timing data are much cleaner than
those at http://seclists.org/nmap-dev/2010/q2/937.

I removed the mutex that allowed only one copy of the script to run at a
time. I think the cause of inaccuracy was timeout corruption, not
parallelism. These are results of different versions.

The original committed script with mutex:
7 correctly detected (missed 4), 4 false positives.
Nmap done: 592 IP addresses (592 hosts up) scanned in 14455.28 seconds

No mutex:
8 correctly detected (missed 3), 2 false positives.
Nmap done: 592 IP addresses (592 hosts up) scanned in 703.65 seconds

r18508:
11 correctly detected, 0 false positives.
Nmap done: 592 IP addresses (592 hosts up) scanned in 650.75 seconds

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