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?

schroeder
  • 123,438
  • 55
  • 284
  • 319
brad_huntington
  • 1
  • 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 '21 at 09: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 '21 at 09:57
  • "validate this" -- validate *what* exactly? That's what I'm asking. – schroeder May 27 '21 at 09:59
  • Sorry, "validate this" the vulnerability reported by the scanner. Example CVE-2019-13917. – brad_huntington May 27 '21 at 10:00
  • Validate whether the vul is exploitable? Or if it exists on the target? – schroeder May 27 '21 at 10:03
  • Both. Because the scanner does a version check and will tell me it exist - then I want to validate whether it does. But without a public exploit, what are my options? – brad_huntington May 27 '21 at 10:05
  • I think that you are still combining concepts. You do not need a PoC to prove that a CVE exists on a target. You only need a PoC when you want to assess the risks for that context. Once you separate your concepts, then your options become a lot clearer. – schroeder May 27 '21 at 10:38
  • Point taken. However, what do you do in this instance where the vulnerability scanner has reported a High vulnerability, but you dont have a PoC? – brad_huntington May 27 '21 at 11:23
  • I look at ***why*** the CVE is considered high, PoC notwithstanding, and see if the reasons why the CVE is a general concern apply in the target's context. A PoC is just one specific way to verify the risks, but I have never felt the need to run a PoC against a finding to verify anything. If the CVE has a published exploit, then that's a reason to take the finding seriously and remediate. But the point is to determine if the vector for the PoC, not the PoC itself, is viable. – schroeder May 27 '21 at 11:54

2 Answers2

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.

Thomas Owens
  • 1,022
  • 8
  • 9
  • Thanks Thomas. That would be my next step, after trying to validate the vulnerability if I can manually. – brad_huntington May 27 '21 at 09: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 '21 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 '21 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 '21 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.

achillean
  • 384
  • 1
  • 5