Re: [PATCH] upnp-info generating false positives

[Patrik Karlsson <patrik () cqure net>]

On 17 nov 2010, at 19.57, Thomas Buchanan wrote:

> 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.

Thanks Thomas! I've applied the patch and commited the change as r21090.

> # 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?

I removed this because the "broadcast" version of the script sends it's request to 239.255.255.250.
In that case the IP would always mismatch and the script would incorrectly try to query the multicast address for the 
XML file.
It could be restored for the unicast version of the script though. Maybe it should be default behavior to check the 
same IP and let a script argument override it?

> Thanks,
>
> Thomas 
> <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/


//Patrik

--
Patrik Karlsson
http://www.cqure.net
http://www.twitter.com/nevdull77





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