0

How do you manually validate vulnerabilities from a vulnerability scan or a vulnerability release from a vendor?

Say you received a report with a high vulnerability. The vulnerability scanner used a version check of the header. If there are no public exploits for this vulnerability, how would you check it if you do not have access to the server internally? An example would be CVE-2019-13917, I can't seem to find a public exploit to throw at the server to validate the vulnerability, and my last resource would be to send it to the IT team responsible. Is this the right approach? - if there are no public exploits, the only other way is to create yourself an exploit by reverse-engineering the patch from the vendor...

I have been given a report from Shodan Vulnerability scanner, which seems to do a version check and I need to validate if the vulnerabilities are actually an issue.

I know that version checking is prone to a large amount of false positives, is there any way around this?

9
  • I think that you have some assumptions here. The report will explain why it is seen as a vulnerability. You can check the headers yourself to see if the report is correct. Are you asking how to assess the risk of the finding? If the report says that the header is X, and X has certain vulnerabilities, and you are actually using X, then that's not a "false positive". It might not be a risk in your context, but that's a different concept. Are you asking about "false positives" or about "risk"? – schroeder May 27 at 9:44
  • Thanks Shroeder. So I understand the "risk" aspect of it. Because the header is displaying a version with "potential" vulnerabilities, it is reporting it. I guess what I was after was, if I was a pentester and needed to validate this, without a public exploit, I really cant. If there was a PoC, I understand how to exploit it and perform the validation. Without either, my only choice is to report it as a "potential" but cannot validate it. – brad_huntington May 27 at 9:57
  • "validate this" -- validate what exactly? That's what I'm asking. – schroeder May 27 at 9:59
  • Sorry, "validate this" the vulnerability reported by the scanner. Example CVE-2019-13917. – brad_huntington May 27 at 10:00
  • Validate whether the vul is exploitable? Or if it exists on the target? – schroeder May 27 at 10:03
1

Just because a vulnerability scanner identifies that a vulnerability exists in a package or library that you use doesn't mean that it's exploitable in your system. Even if it is exploitable, there may be controls in place that limit who can exploit it that are sufficient to reduce the risk.

Depending on the context, I'd recommend not blindly following the results of a vulnerability scanner. Instead, perform a risk assessment and prioritize deploying patches or fixing code based on the risk of the vulnerability to your code or organization. Taking on different user roles - public actor, end-user, administrator, operations engineer - and attempting to exploit the vulnerability to determine the impact on your system.

4
  • Thanks Thomas. That would be my next step, after trying to validate the vulnerability if I can manually. – brad_huntington May 27 at 9:59
  • 1
    @brad_huntington You may not need to manually validate the vulnerability. In fact, nearly every time a tool reports a CVE in a dependency, there's usually enough information to determine how to exploit and that can be used to reason through a risk assessment. – Thomas Owens May 27 at 11:50
  • Thanks Brad. So if a pentester receives a High finding from his vulnerability scan, but doesnt have enough information about how to exploit the vulnerability, he would still need to report the issue even though he hasn't technically validated that it exists? – brad_huntington May 27 at 12:32
  • @brad_huntington It depends. In my experience, pen testers use both automated and manual tools during their work. Depending on the rules of the engagement, I'd generally expect a human pen tester to attempt to exploit the vulnerability and report not only the vulnerability but what was done to attempt to exploit it and the results of those attempts. Whoever owns and maintains the system (and engaged the pen testers) would need to evaluate the report and findings and evaluate the risk, prioritizing how to deal with potential vulnerabilities based on their risk assessment. – Thomas Owens May 27 at 13:20
0

The first thing I would recommend doing is looking at the raw banner data to determine whether the vulnerability information has been verified or not.

There are 2 types of vulnerabilities that can be attached to the banners in Shodan: verified and unverified. Unverified vulnerabilities are vulnerabilities that are implied based on the metadata we've collected. For example, if a server is running an old version of Apache then we will associate known issues with that version and set the associated verified property in the banner to False. Shodan has increasingly also started to verify vulnerabilities when possible. If a verified vulnerability is discovered then we set the verified property to True.

In our own products such as Shodan Monitor we only send out notifications for verified vulnerabilities. Unverified ones can be unreliable and require manual follow-up/ good understanding of your environment. Finally, Shodan isn't a vulnerability scanner. It doesn't comprehensively test or identify all vulnerabilities. Our main focus is on helping organizations understand what devices they have connected to the Internet. And we check for serious issues that we're seeing actively exploited in the wild. The unverified information was added due to requests from customers as a convenience so they don't need to do it on their own but it generates a lot of false positives.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.