2

When conducting penetration testing in a PCI-DSS compliance context, we found a known security vulnerability that's identified by a CVE number.

In this case, the finding in question is CVE-2016-20012, which is marked on the CVE database as **DISPUTED**.

There are many CVEs like this. The vendor does not want to acknowledge this as a valid vulnerability vector, and all distributions containing the affected software have marked this vector as "WILL NOT FIX" in their repositories, so there aren't even patches to apply for it.

While I as a pentester understand the vendor's reasons for wanting to dispute this CVE, the fact remains that it's still a known CVE, and has a CVSS Base score of 5.3, which is above the 4.0 score that PCI-DSS says needs to be mitigated in order to comply with their standards.

What is the best practice approach in situations like this? Can we ignore this finding? What is the justification for accepting this finding not getting fixed in a PCI-DSS context?

I couldn't find any conclusive answer on this matter anywhere on the internet.

REFERENCES:

https://ubuntu.com/security/CVE-2016-20012

https://access.redhat.com/security/cve/CVE-2016-20012

https://github.com/openssh/openssh-portable/pull/270

Improve this question
5
  • You seem to have taken the position that the vendor and distributions must be in the wrong. Why is this?
    – Joseph Sible-Reinstate Monica
    Jun 17 at 22:52
  • Because normally, when there is a username enumeration vector in other programs, it's reported as a finding in penetration tests. An application should not confirm whether or not a username exists, as this assists 50% of the process in bruteforcing attempts.
    – xpelican
    Jun 21 at 8:30
  • Then there's also the matter of the CVE just existing. This is not something I'm hung up on, but from a PCI perspective, wouldn't the CVE show up any time someone does a security scan? If I give the client a pass, and then if someone else scans their systems and sees this CVE, the client should have an explanation as to why this CVE is not an issue. I'm simply asking whether the "Disputed" claim is sufficient to explain.
    – xpelican
    Jun 21 at 8:32
  • Then mentioned version 8.7, but they are on v9 is the vulnerability still present?
    – cybernard
    Jun 23 at 19:47
  • I think so, yes. Because OpenSSH explicitly states they do not consider username enumeration a vulnerability vector so they will not change how the program behaves in this regard. Pretty much every version of OpenSSH has this vector.
    – xpelican
    Jun 26 at 14:10

1 Answer 1

Reset to default
1

As a penetration tester, you role is to confirm whether this vulnerability actually exists (i.e, that it isn't a false positive), determine whether it's exploitable, and explain the impact of it to your client. You should not be ignoring issues just because they're inconvenient, or because your client is doesn't want any issues above an arbitrary CVSS score.

The fact that the OpenSSH developers have said they're not planning to fix it is irrelevant to the risk that it represents - although it will affect the recommendations that you give.

It's then up to your client to argue with their QSA why they do not believe that this is a legitimate risk, or to demonstrate how they have mitigated the issue to reduce the risk to an acceptable level.

Improve this answer
3
  • I understand and agree completely, and I have no problems telling my clients it is what it is. I'm not looking for ways to sweep these off the table, I'm more curious about how organizations can move forward with these issues. For a vulnerability vector like this example; it's safe to assume this is present in virtually all modern versions of OpenSSH, which would mean a very high percentage of organizations are using versions that are affected, and thus, should be PCI incompatible. How do they become PCI compliant? I find it hard to believe they would just stop using OpenSSH, for example.
    – xpelican
    Jun 17 at 13:45
  • @xpelican you would have to look at exactly what the requirements of PCI DSS are. But I suspect that most companies get around this either by ignoring it, or by demonstrating that they have appropriate mitigations in place to reduce the risk to a level that the standard (or QSA) considers acceptable.
    – Gh0stFish
    Jun 17 at 16:29
  • This is exactly what I'm suspecting is probably the case. I don't have enough expertise on what PCI dictates specifically so I'm hoping someone who's an expert can help tackle this one with me. There has to be some way of explaining this away, because otherwise a significant portion of the world would be in hot water due to "unfixable" CVEs like this. But there seems to be literally no discussion about this on the internet. I find it hard to believe no one has ever run into this problem, but can't find anything being discussed.
    – xpelican
    Jun 21 at 8:36

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .