[PATCH] upnp-info generating false positives

["Thomas Buchanan" <TBuchanan () thecompassgrp net>]

Hello.  In the current SVN version of nmap, the upnp-info script is
generating false positives, marking filtered ports as open when the
connection times out.  The issue appears to be in the new upnp.lua
library, and causes an assertion failure, as shown below.  The attached
patch corrects the issue for me.

# nmap -sU -v -d -p 1900 --script=upnp-info scanme.nmap.org
<...>
NSE: Starting upnp-info against 64.13.134.52:1900.
Discovered open port 1900/udp on 64.13.134.52
NSE: upnp-info against 64.13.134.52:1900 threw an error!
/usr/local/share/nmap/nselib/stdnse.lua:551: No data was passed to
format_output()
stack traceback:
        [C]: in function 'assert'
        /usr/local/share/nmap/nselib/stdnse.lua:551: in function
</usr/local/share/nmap/nselib/stdnse.lua:549>
        (tail call): ?
        (tail call): ?

Completed NSE at 12:45, 5.00s elapsed
Nmap scan report for scanme.nmap.org (64.13.134.52)
Host is up, received echo-reply (0.076s latency).
Scanned at 2010-11-17 12:45:04 CST for 6s
PORT     STATE SERVICE REASON
1900/udp open  upnp    script-set
<...>

After the patch is applied we have the following:

# NMAPDIR=. ./nmap -sU -v -d -p 1900 --script=upnp-info scanme.nmap.org
<...>
Initiating NSE at 12:55
NSE: NSE Script Threads (1) running:
NSE: Starting upnp-info against 64.13.134.52:1900.
NSE: Finished upnp-info against 64.13.134.52:1900.
Completed NSE at 12:55, 5.00s elapsed
Nmap scan report for scanme.nmap.org (64.13.134.52)
Host is up, received echo-reply (0.073s latency).
Scanned at 2010-11-17 12:55:07 CST for 5s
PORT     STATE         SERVICE REASON
1900/udp open|filtered upnp    no-response
<...>


One other issue that I noticed in testing the new version of this
script.  The previous (monolithic) version of the script would retrieve
the IP address of the HTTP server that serves up the XML files that UPNP
uses, and if that IP address was different from the currently tested IP
address, would generate a warning that the two differed, then go ahead
and try to retrieve the XML file using the original IP address.  This
seemed to work fairly well for devices that have the UPNP service
available on the Internet-facing network interface, but would then
return the IP address of the internal NIC in the address of the
webserver where the XML is stored.  This was a feature that I found
useful, as it would occasionally disclose information about the internal
network architecture.  I noticed that the new version of the script
doesn't exhibit this behavior any longer.  Would there be any interest
in a patch to restore this capability, perhaps through a script
argument?

Thanks,

Thomas

Attachment: upnp-library.diff
Description: upnp-library.diff

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