Posted by:

David Greenwood

David Greenwood, Chief of Signal

If you are reading this blog post via a 3rd party source it is very likely that many parts of it will not render correctly. Please view the post on signalscorps.com for the full interactive viewing experience.

In this post I will show how users can define products they are using CPE URIs organise as nodes in Vulmatch.

Note: Vulmatch is an ever evolving product therefore the concepts described in this post might not always be relevant for the latest version.

In Vulmatch when a new CVE is imported or an existing CVE record updated, the products a user in Vulmatch has selected are matched against the product configurations inside the CVE.

In essence, a user is creating nodes in Vulmatch in a similar way to how they are reported in CVEs to be compared against those found in each CVE. The only difference being the configurations are benign (a users configuration does not indicate a vulnerability). It is only when a user CPE configuration matches a CVE CPE configuration that an alert is raised in Vulmatch.

The Vulmatch UI only allows users to build simplistic node combinations consisting of either a piece of hardware or an operation system or an application node.

The reason why complex combinations of hardware/OS/applications (like those in CVEs) are not allowed in Vulmatch is due to the variation in NVD CVE match node structure, as touched on in the last post.

To reiterate that point let me explain with some examples. The first using Apple iCloud;

GET https://services.nvd.nist.gov/rest/json/cpes/1.0/?apiKey=&cpeMatchString=cpe:2.3:a:apple:icloud:*:*:*:*:*:*:*:*&includeDeprecated=true

There are 56 product versions (55 defined versions, 1 undefined (-) version)

{
    "resultsPerPage": 500,
    "startIndex": 0,
    "totalResults": 56,

Some are very old. For example Apple iCloud 7.0 (last modified 2017-11-28T19:13Z);

{
    "deprecated": false,
    "cpe23Uri": "cpe:2.3:a:apple:icloud:7.0:*:*:*:*:*:*:*",
    "lastModifiedDate": "2017-11-28T19:13Z",
    "titles": [

In this case the update, edition, language, sw_edition, target_sw, target_hw, and other sections of the cpe23Uri are set to * (any specified or unspecified options for these values).

Now lets look at another entry for newer versions of iCloud (this time version 7.10);

{
   "deprecated": false,
   "cpe23Uri": "cpe:2.3:a:apple:icloud:7.10:*:*:*:*:windows:*:*",
   "lastModifiedDate": "2019-03-06T15:08Z",
   "titles": [

Here, target_sw is set to Windows.

Writing a node configuration in a CVE that would match to this CPE could be written in at least two ways;

Version 1 (where OS is specified using target_sw);

{
    "operator": "OR",
    "children": [],
    "cpe_match": [
        {
            "vulnerable": true,
            "cpe23Uri": "cpe:2.3:a:apple:icloud:7.10:*:*:*:*:windows:*:*",
            "versionEndIncluding": "7.10",
            "versionEndIncluding": "7.10",
            "cpe_name": [
                {
                    "cpe23Uri": "cpe:2.3:a:apple:icloud:7.10:*:*:*:*:windows:*:*",
                    "lastModifiedDate": "2019-03-06T15:08Z"
                }
            ]
        }
    ]
}

Version 2 (where OS is specified using a separate node);

{
    "operator": "AND",
    "children": [],
    "cpe_match": [
        {
            "vulnerable": true,
            "cpe23Uri": "cpe:2.3:a:apple:icloud:7.10:*:*:*:*:*:*:*",
            "versionEndIncluding": "7.10",
            "versionEndIncluding": "7.10",
            "cpe_name": [
                {
                    "cpe23Uri": "cpe:2.3:a:apple:icloud:7.10:*:*:*:*:*:*:*",
                    "lastModifiedDate": "2019-03-06T15:08Z"
                }
            ]
        },
        {
            "vulnerable": false,
            "cpe23Uri": "cpe:2.3:o:microsoft:windows:-:*:*:*:*:*:*:*",
            "cpe_name": [
                {
                    "cpe23Uri": "cpe:2.3:o:microsoft:windows:-:*:*:*:*:*:*:*",
                    "lastModifiedDate": "2019-03-06T15:08Z"
                },
            ]
        }
    ]
}

In both examples the configuration defines Apple iCloud 7.0 running on Windows is vulnerable, just in different ways.

As a result of this flexibility the Vulmatch design makes a trade-off to account for these variations.

To do this, a user defines a single product configuration consisting of part, vendor, product and versions.

Users 1) select either hardware, operating system, or application. They then 2) select from available vendors filtered by those matching the part selection at step one. Then then 3) select from available products filtered by those matching the vendor selection at step 2.

e.g. 1) Application > 2) Apple > 3) iCloud

Vulmatch then allows users to select version ranges from earliest (versionStartIncluding) and latest versions (versionEndIncluding) of the product (using available product versions in CPE database);

For example user might select Application>Apple>iCloud and versionStartIncluding=7.0 and versionEndIncluding=11.0.

This would select all CPEs; Application>Apple>Quicktime with versions >=7.0 to <=11.0.

Alternatively, if user wanted to select the earliest and latest version of the product in the CPE database they could select; versionStartIncluding=<EARLIEST AVAILABLE> and versionEndIncluding=<LATEST AVAILABLE>, where Vulmatch would dynamically select the earliest and latest versions of the product in the CPE database. At the time of writing this would be >=5.2 to <=12.3 (but of course this might change over time as new versions are released which Vulmatch would account for).

In my approach a user is unable update, edition, language, sw_edition, target_sw, target_hw, and other sections because it would create a very specific match criteria, leaving the potential for some matches to be missed.

In the Vulmatch design I have accepted that some false positives are better than missed matches, hence the reason for this behaviour.

To demonstrate what a user software node configuration looks like, let us assume a user selects;

  1. part = application
  2. vendor = apple
  3. product = iCloud
  4. versionStartIncluding = 12
  5. versionEndIncluding = (currently 12.3)

Currently this results in two CPE cpe:2.3:a:apple:icloud:12.0:*:*:*:*:windows:*:* and cpe:2.3:a:apple:icloud:12.3:*:*:*:*:windows:*:* nodes.

This would create the following user software node configuration for this selection;

"vulmatch_configuration": {
    "nodes": [
      {
        "operator": "OR",
        "children": [],
        "cpe_match": [
            {
                "cpe23Uri": "cpe:2.3:a:apple:icloud:12.0:*:*:*:*:windows:*:*",
                "cpe_name": [
                    {
                        "cpe23Uri": "cpe:2.3:a:apple:icloud:12.0:*:*:*:*:windows:*:*",
                        "lastModifiedDate": "2021-05-10T13:44Z"
                    }
                ] 
            },
            {
                "cpe23Uri": "cpe:2.3:a:apple:icloud:12.3:*:*:*:*:windows:*:*",
                "cpe_name": [
                    {
                        "cpe23Uri": "cpe:2.3:a:apple:icloud:12.3:*:*:*:*:windows:*:*",
                        "lastModifiedDate": "2021-05-10T13:44Z"
                    }
                ] 
            },         
          ]
        }
      ]
    }
}

There are only two nodes, because at the time of writing only two CPEs match the part/application/vendor/product/versions, as already noted.

As you can see, there is a target_sw in both examples is windows. This is because these are the only CPEs in the CPE database that match the version range selected.

CPE to CVE matching logic

This is where the Vulmatch matching logic becomes important.

Each node in a users Vulmatch configuration for a product is compared against nodes in CVE entries one-by-one (not by node) for an exact match, only where "vulnerable": true,, and ignoring the operator conditions defined in the nodes.

Let me illustrate why in an example.

This time lets assume a user selects;

  1. part = application
  2. vendor = apple
  3. product = iCloud
  4. versionStartIncluding = 7.9
  5. versionEndIncluding = 7.10

This condition matches with 3 existing CPEs creating the 3 matching nodes; cpe:2.3:a:apple:icloud:7.9:*:*:*:*:*:*:*, cpe:2.3:a:apple:icloud:7.10:*:*:*:*:*:*:*, and cpe:2.3:a:apple:icloud:7.10:*:*:*:*:windows:*:*, thus would create 3 nodes in a users software node configuration.

Each time a new CVE is added or existing CVE record is updated, Vulmatch compares these 3 user CPE nodes to the cpe_matches in CVEs where "vulnerable": true.

So lets now imagine two new CVEs are added, one with the configurations logic;

  1. cpe:2.3:a:apple:icloud:7.10:*:*:*:*:windows:*:* ("vulnerable": true,) – this is the same as Version 1 (where OS is specified using target_sw) shown earlier in this post,
  2. cpe:2.3:a:apple:icloud:7.10:*:*:*:*:*:*:* ("vulnerable": true,) AND cpe:2.3:o:microsoft:windows:-:*:*:*:*:*:*:* ("vulnerable": false,) – this is the same as Version 2 (where OS is specified using a separate node) shown earlier in this post

In this case, the 3 user configuration nodes cpe:2.3:a:apple:icloud:7.9:*:*:*:*:*:*:*, cpe:2.3:a:apple:icloud:7.10:*:*:*:*:*:*:*, and cpe:2.3:a:apple:icloud:7.10:*:*:*:*:windows:*:* would each individually be compared to cpe:2.3:a:apple:icloud:7.10:*:*:*:*:windows:*:* AND cpe:2.3:a:apple:icloud:7.10:*:*:*:*:*:*:* but not cpe:2.3:o:microsoft:windows:-:*:*:*:*:*:*:* because it is not a vulnerable product in this scenario.

Of course, what that means in the second scenario is the OS (Windows) is not considered at all, and thus might create a false positive matches (where a user is not running iCloud on Windows).

Above I have only shown examples using application CPEs.

The same logic holds true for operating system and hardware CPEs.

Whilst hardware vulnerabilities are much rarer, they are indeed still possible. Take CVE-2017-5753 for example. In this case if a user had cpe:2.3:h:intel:atom_c:c2308:*:*:*:*:*:*:* in their Vulmatch configuration, it would match to this CVE.

Next time: Turning CVEs and CPEs into STIX 2.1 Object

Now I have demonstrated how to obtain CVE and CPE data, the logic of CPE configurations, and how to match user selected products to CVEs, all this data now needs to be stored.

Vulmatch is based on the STIX 2.1 specification. In the next post I will show how to model CVE and CPE data shown in this post as STIX 2.1 Objects.




Our brand new Discord!

Like this blog?

Sign up to receive new posts in your inbox.


Stixify

Stixify. Extract machine readable intelligence from unstructured data.

Extract machine readable intelligence from unstructured data.

Obstracts

Obstracts

Turn any blog into structured threat intelligence.


Vulmatch

Vulmatch

Know when software you use is vulnerable, how it is being exploited, and how to detect an attack.

SIEM Rules

SIEM Rules. Your detection engineering database.

View, modify, and deploy SIEM rules for threat hunting.