Vulnerability scan

[NogNeetMachinaal]

See also attached screenshot:
This is the result of a vulnerability scan of an Asus rt-ac68u with the latest Merlin firmware.
This is done without any interactive logins => only portscanning.

This router is not reachable via the internet

While it looks worse then it really is due to the different host names and TCP ports, all issues have fixes available.

How, that is just my view on this => anyone with a different perspective?

In addition, is there a way to remove the different host names (already disabled?
I already set "Redirect webui access to router.asus.com" to no => this is just noise.

 

[ColinTaylor]

Have you verified that these are actually real vulnerabilities? Generic vulnerability scanners usually report many false positives. For example, it appears to be reporting an issue with PHP, but the router doesn't use PHP afaik.

 

[RMerlin]

Most of these are indeed bogus. There's no PHP on the router, and the router isn't a Polycom VoIP phone either.

 

[NogNeetMachinaal]

Thank you for the feedback.

Indeed - the first step is validating if it is a real vulnerability.
And yes - I'm aware of the fact that the router is not running php and isn't a phone.

Thinking out load now:
If I do some research on the presented "vulnerabilities" then it seems to be related to a way of bringing the webserver down by lauching certain get commands. This is characterized as "HTTP negative Content-Length buffer overflow".

At the same time, the scanner also detected an error condition where the webserver didn't respond. With this in mind, I would say this part of the result is a valid one.

The part that I'm not so sure of is where it says that an attacker may use this to disable the service or even execute arbitrary code on the system. This is because I don't have visibility on what is suppose to happen if the webserver is not responding. What is your view here?

 

[RMerlin]

If I do some research on the presented "vulnerabilities" then it seems to be related to a way of bringing the webserver down by lauching certain get commands. This is characterized as "HTTP negative Content-Length buffer overflow".

We'd need a test case to be able to reproduce and validate the result, outside of the scanner itself.