Address false positive in hnap-info

[TomSellers]

Currently hnap-info is generating false positives because it is treating HTTP 200 responses to requests for /HNAP1 as valid HNAP services. There are multiple services that respond to every request with a HTTP 200 response. Against these services hnap-info is often, but not consistently, overwriting the version detection result with hnap. I've added the standard code that will detect services that always responds 200 and then exit if found. This should not break the normal functionality of the script unless hnap services behave this way to. In that case the script needs to parse the response and validate the result prior to changing/updating the version detection result.

I have NOT tested this with an actual HNAP service.

CC @h4ck3rk3y

[dmiller-nmap]

@TomSellers This looks like a good approach. Please commit after fixing these issues:

1. Return nil instead of false to avoid any script output.
2. Also check the first return value, which could be false if there was some network problem or non-HTTP response.

Be sure to include "Closes #241" in your commit message to auto-close this PR.

[dmiller-nmap]

@TomSellers This looks like a good approach. Please commit after fixing these issues:

1. Return nil instead of false to avoid any script output.
2. Also check the first return value, which could be false if there was some network problem or non-HTTP response.

Be sure to include "Closes #241" in your commit message to auto-close this PR.

[h4ck3rk3y]

nice find!
what are your thoughts regarding putting the block of code that sets the port version inside an if #output >0 then .. end block?

[h4ck3rk3y]

nice find!
what are your thoughts regarding putting the block of code that sets the port version inside an if #output >0 then .. end block?

[TomSellers]

@dmiller-nmap Thanks for the feedback. I should have this committed tonight. I have a service that may be generating an incorrect result from http.identify_404. I want to validate this first.

@h4ck3rk3y I would add a regex or some form of validation of the page content to ensure that it is actually a hnap sevice. If the parsing process is reliable ( results in some valid data consistently ) I would check the values of one or more of the reliable fields.

Do you have some recommended software that can be downloaded to test with?

[TomSellers]

@dmiller-nmap Thanks for the feedback. I should have this committed tonight. I have a service that may be generating an incorrect result from http.identify_404. I want to validate this first.

@h4ck3rk3y I would add a regex or some form of validation of the page content to ensure that it is actually a hnap sevice. If the parsing process is reliable ( results in some valid data consistently ) I would check the values of one or more of the reliable fields.

Do you have some recommended software that can be downloaded to test with?

[TomSellers]

I've committed an update that deals with the issue of servers always returning 200.

I also handled the situation where response body doesn't parse correctly resulting in the 'output' variable being an empty table.

I used the following as using the # lua operator isn't reliable on the table.

-- Counting size of entries in table to determine if it is empty
-- using the '#' operator is not reliable on tables
local count = 0
for _ in pairs(output) do count = count + 1 end
if count < 1 then return nil end

[TomSellers]

I've committed an update that deals with the issue of servers always returning 200.

I also handled the situation where response body doesn't parse correctly resulting in the 'output' variable being an empty table.

I used the following as using the # lua operator isn't reliable on the table.

-- Counting size of entries in table to determine if it is empty
-- using the '#' operator is not reliable on tables
local count = 0
for _ in pairs(output) do count = count + 1 end
if count < 1 then return nil end

[dmiller-nmap]

The canonical way of checking for an empty table is to use "next"

if not next(output) then return nil end

http://www.lua.org/manual/5.2/manual.html#pdf-next

On Thu, Dec 3, 2015 at 6:19 AM, Tom Sellers notifications@github.com
wrote:

I've committed an update that deals with the issue of servers always
returning 200.

I also handled the situation where response body doesn't parse correctly
resulting in the 'output' variable being an empty table.

I used the following as using the # lua operator isn't reliable on the
table.

-- Counting size of entries in table to determine if it is empty
-- using the '#' operator is not reliable on tables
local count = 0
for _ in pairs(output) do count = count + 1 end
if count < 1 then return nil end

—
Reply to this email directly or view it on GitHub
#241 (comment).

[dmiller-nmap]

The canonical way of checking for an empty table is to use "next"

if not next(output) then return nil end

http://www.lua.org/manual/5.2/manual.html#pdf-next

On Thu, Dec 3, 2015 at 6:19 AM, Tom Sellers notifications@github.com
wrote:

I've committed an update that deals with the issue of servers always
returning 200.

I also handled the situation where response body doesn't parse correctly
resulting in the 'output' variable being an empty table.

I used the following as using the # lua operator isn't reliable on the
table.

-- Counting size of entries in table to determine if it is empty
-- using the '#' operator is not reliable on tables
local count = 0
for _ in pairs(output) do count = count + 1 end
if count < 1 then return nil end

—
Reply to this email directly or view it on GitHub
#241 (comment).

[TomSellers]

@dmiller-nmap Thanks! Fixed

[TomSellers]

@dmiller-nmap Thanks! Fixed