CPEs and CVEs

March 1, 2021

Post by Robert Hansen

Understanding the low-hanging-fruit of vulnerabilities is one of the most important things to understand about an environment.  Thankfully, there are some easy ways, through fingerprinting, to get a wide variety of different vulnerability information from assets.  But to do that, it is important to understand a little about CPEs first.

CPE stands for Common Platform Enumeration and it is the default syntax for how equipment, operating systems and software is indicated.  It is a structured naming schema for the assets and the software living on the assets.  Here are a few examples:

  • cpe:/o:microsoft:windows
  • cpe:/a:php:php:5.6.25

In the first example we can see a “/o” which indicates this is an operating system.  The operating system manufacturer is “microsoft” and the operating system in question is “windows”.  Now, sometimes it is not possible to extract the version information like “vista”, but this still gives you a quick view into what is easily found externally.  While this does not necessarily have vulnerability information that can be easily extracted, it can be useful if you know that a certain type of equipment is at its end of serviceable life, or if you believe there should be none of XYZ operating systems or hardware deployed.  Therefore, being able to search on CPE data is actually quite useful.

In the second example above, we can see a “/a” which indicated that this is an application, or the software that runs the service in question. We see that it is running “php” and version number “5.6.25”.  That is a relatively old version of PHP and has some known vulnerabilities in it. The vulnerabilities lead us to CVE data.

CVE stands for Common Vulnerabilities and Exposures, and is the short-hand code for the industry-standard way of discussing a vulnerability by using a short-hand code.  By extracting the known issues found in PHP version 5.6.25 and before, we can see a huge list of issues:

It is not surprising to see this many potential issues for such an old version of an application that’s as popular as PHP is.  It is not to say that all CVEs are made equal. Some CVEs are going to be for internal privilege escalation – therefore it requires an adversary to be able to run arbitrary commands on the machine first before they can exploit it. That becomes a chicken and egg problem – how did they get onto the machine first, that seems like the real vulnerability.

That said, local users who are not supposed to have administrative access might be a very real threat in a multi-user environment, or when an employee wants to hide their tracks. It is difficult to know ahead of time what matters and what is inconsequential. Therefore, it is up to the company in question to triage and make sure these issues are not worth fixing, or if they can be mitigated in other ways, like using a web application firewall or some other active deterrent.