Use and Misuse of CPE’s

Yesterday’s blog post dealt with problems with the current Common Platform Enumeration (CPE) system in keeping track of vulnerabilities that affect multiple systems. In writing that post I kind of glossed over how the CPE is used and how it could be used and misused in the cybersecurity environment.

Current CPE Use

Yesterday’s post was in response to a Twitversation initiated by Ron Brash (got it right today Ron). He was complaining that when a derivative vulnerability was reported using the CVE number from the original vulnerability, the CPE for the newly identified vulnerable devices were not being attached to the original CVE. This is a problem for folks like Ron because it prevents them from effectively using the intended use of the CPE. Let me explain.

If you own just a single control system device, it may be difficult to keep up with the vulnerabilities that affect that device. Some manufacturers do a good job of posting advisories to their web sites and folks like NCCIC-ICS and other CERTS do a good job of reporting on vulnerabilities coordinated through them or are reported to them by vendors. But if the vendor for your product does not publish advisories (an awful lot do not), and if a vulnerability is not reported through a CERT that you follow, it will be easy to miss vulnerability notices. The CPE system, in that case would help you keep track of your device vulnerabilities.

If you own hundreds of devices (not unusual in a manufacturing environment) with lots of different version numbers (again not unusual as equipment is added or replaced) that system of watching vendor web sites or CERT notifications gets a tad bit tiresome. This is where the CPE system really shines (when it is working right, see Ron’s complaint). All you have to do is to have a list of all of your devices and their respective CPE’s and you can write a script (okay I can’t actually write those scripts, but there are plenty of folks who can and that would be a valuable skill set to have in your security team) to periodically search the National Vulnerability Database (NVD) for vulnerabilities that reflect your specific devices.

Now that will not get all of the identified vulnerabilities as some countries do not fully report through the CVE system. But it will get the vast majority of vulnerabilities and should keep you up to date on the available mitigation measures that affect your devices. Then ALL you have to do is figure out how to implement those security measures.

Researcher CPE Use

Now if I were a cybersecurity researcher looking for vulnerabilities, one of the tools that I would use would be the CPE/CVE system. With a list of the devices that I had available to play with, I would write up the same script that I described above to track vulnerabilities in those devices.

I would then look at the CVEs for those identified vulnerabilities for other devices that had the same vulnerabilities. The CPE’s for those devices would then be added to a new script used to look for target vulnerabilities in those other devices that might also apply to the devices in my lab. There is not going to be a 100% overlap, but by careful reading of vulnerability descriptions you should be able to develop a significant list of potential vulnerabilities to search for.

For example, let’s look at the advisory that started this whole chain of blog posts, the NCCIC-ICS advisory for the Rockwell Automation Stratix Switches. If I had one of those switches in my (nonexistent) lab I would go back to CVE-2021-1392 in the NVD and note that that vulnerability was related to the “CLI command permissions of Cisco IOS and Cisco IOS XE”. Using that information, I would look at the CPE list at the bottom of the NVD CVE listing and then search those CPE’s (probably only a handful of the 214 available CPE’s) to see if there were any other ‘CLI command’ related vulnerabilities. I would place those vulnerabilities on my priority research list for the switch I had in my lab.

Adversary CPE Use

If you think that security tools are only used by the good guys (and yes cybersecurity researchers are definitely the good guys) you should not be working in the cybersecurity field. The same techniques that I outline above can by used by the bad guys. Actually, just remember, that adversarial researchers are considered to be the good guys by their side.