Microsoft IIS susceptible to CVE-XXXXXXXX. Recommend applying accordingly patch.
Another almost good finding - but according to the appendix, this host is a RHEL 5.x box. Those sysadmins - finding ways to run IIS on linux!! Brilliant!
I used to see crap like this all the time coming out of PCI compliance audits. The hosts I dealt with ran Apache on RHEL, too. We'd point this out, and they'd "accept" that "fix."
Some of these sound reasonable. For example there are un-patched minor Denial-of-Service attacks in both Windows and Linux, and I'd expect a pentest to report on those, even if there's nothing we can do about them (for example monitor, inform ops etc of the potential for said attack).
If OS detection is wrong (and its not a precise science), reporting on these is reasonable.
I've seen similar to this with our pen-test firm (who apparently do pen-tests for the UK NHS) - we're a C#/ASP.NET shop, running on Windows servers and they know this.
For some reason when I examine our logs after each test I see attempts at access to /usr etc.
It does make me wonder if all so called pen-test companies are just one massive scam.
Those parts are typically automated. Also even if you're a .net shop, you might have your stuff placed in front a linux/bsd based router which responds to certain requests (it does happen).
A pen tester can't know what infrastructure changes you've made, and should work from scratch each time, IMO. It might not have even been your company which made the change, hoster might have made change to the environment etc etc.
If it doesn't cost you any more to have them to try and scan /usr, ../../../../../../etc/passwd and so on, why not?
When I did pentests, we encountered a customer who, via a misconfigured puppet manifest, installed WordPress on a public facing server with a known-vulnerable plugin, which we found by always scanning /wp-admin/ even though the customer was a strictly RoR shop.
They are probably using an automated testing tool of which there are many. These tools are all pretty dumb and the typically end up running all the tests on all the machines w/o taking into account prior knowledge like, "This is a windows server". These tools end up returning a bunch of useless information that a knowledgeable person then needs to sort through to confirm each potential problem.
The issue arrises when someone takes what pops out of the scanner as gospel instead of investigating if it is true or a false positive.
Usually when we see stuff like that it's because there's a device doing some traffic control (load balancer, proxy, WAF, whatever) for the web server that runs some version of Linux. So you'll get a report that says IIS on Redhat or IIS and Apache both running on port 80.
Since the automated scanners are... stupid, they'll then gleefully go off and check for Linux vulnerabilities too.
The guys doing the analysis should of course catch all that, but if no one is doing any analysis and just parroting what the tools tell them, it ends up in the report.
Comments
I used to see crap like this all the time coming out of PCI compliance audits. The hosts I dealt with ran Apache on RHEL, too. We'd point this out, and they'd "accept" that "fix."
Some of these sound reasonable. For example there are un-patched minor Denial-of-Service attacks in both Windows and Linux, and I'd expect a pentest to report on those, even if there's nothing we can do about them (for example monitor, inform ops etc of the potential for said attack).
If OS detection is wrong (and its not a precise science), reporting on these is reasonable.
I've seen similar to this with our pen-test firm (who apparently do pen-tests for the UK NHS) - we're a C#/ASP.NET shop, running on Windows servers and they know this.
For some reason when I examine our logs after each test I see attempts at access to /usr etc.
It does make me wonder if all so called pen-test companies are just one massive scam.
Those parts are typically automated. Also even if you're a .net shop, you might have your stuff placed in front a linux/bsd based router which responds to certain requests (it does happen).
A pen tester can't know what infrastructure changes you've made, and should work from scratch each time, IMO. It might not have even been your company which made the change, hoster might have made change to the environment etc etc.
If it doesn't cost you any more to have them to try and scan /usr, ../../../../../../etc/passwd and so on, why not?
When I did pentests, we encountered a customer who, via a misconfigured puppet manifest, installed WordPress on a public facing server with a known-vulnerable plugin, which we found by always scanning /wp-admin/ even though the customer was a strictly RoR shop.
They are probably using an automated testing tool of which there are many. These tools are all pretty dumb and the typically end up running all the tests on all the machines w/o taking into account prior knowledge like, "This is a windows server". These tools end up returning a bunch of useless information that a knowledgeable person then needs to sort through to confirm each potential problem.
The issue arrises when someone takes what pops out of the scanner as gospel instead of investigating if it is true or a false positive.
Usually when we see stuff like that it's because there's a device doing some traffic control (load balancer, proxy, WAF, whatever) for the web server that runs some version of Linux. So you'll get a report that says IIS on Redhat or IIS and Apache both running on port 80.
Since the automated scanners are... stupid, they'll then gleefully go off and check for Linux vulnerabilities too.
The guys doing the analysis should of course catch all that, but if no one is doing any analysis and just parroting what the tools tell them, it ends up in the report.
"We got local file inclusion but cannot read /etc/passwd. No idea what went wrong..."