Giters

rapid7 / recog

Pattern recognition for hosts, services, and content

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

CPE is tagged as 2.3, but is in 2.2 format

p0lr opened this issue · comments

commented

CPE is tagged as 2.3, but is in 2.2 format.

To Reproduce

  1. Look at an XML fingerprint file
  2. Notice that the tag is cpe23
  3. Notice that the actual CPE string has a "cpe:/" in it
  4. CPE 2.3 would have a "cpe:2.3:" format

Would recommend changing this to a 2.2 tag, or update the CPE to 2.3

commented

Thanks! cc @TomSellers

commented

I dug into this a bit this morning. The data in the *.cpe23 fields is indeed CPE 2.3 but it is in the URI format. Jon called this out when he added CPE in PR #172

The 2.3 specification has 3 formats:

  1. URI format, intended to be backwards compatible with 2.2 (Section 6.1 in the ref below)
    cpe:/a:hp:insight_diagnostics:7.4.0.1570:-:~~online~win2003~x64~

  2. Formatted String (Section 6.2 in the ref below)
    cpe:2.3:a:hp:insight_diagnostics:7.4.0.1570:-:*:*:online:win2003:x64:*

  3. WFN - well formatted name (Section 5 in the ref below)

wfn:[
  part="a",
  vendor="hp",
  product="insight_diagnostics",
  version="7\.4\.0\.1570",
  update=NA,
  sw_edition="online",
  target_sw="win2003",
  target_hw="x64"
]

We are currently emitting the URI variant as our cpe23 value. I can likely add a new field named cpe23_fs that is more in line with what folks expect. Here's a rough explanation of the values.

part:vendor:product:version:update:edition:sw_edition:target_sw:target_hw:language:other
                              ^       ^         ^       ^           ^       
                              |       |         |       |           ---- x86, JVM, CLR, etc.
                              |       |         |       |
                              |       |         |       --- valid OS or software env
                              |       |         |
                              |       |         --- how tailored to market / class of users
                              |       | 
                              |       --- deprecated in formatted string format
                              |
                              --- update, service pack, point release - vendor specific

Also, there are a couple things we are likely doing incorrectly.

  1. CPE 2.3 as 4 new fields (sw_edition, target_sw, target_hw, language) that don't exist in 2.2. In order to express them in a backwards compatible way they are "packed" into the edition field (deprecated in 2.3) separated by the tilde ~ character.

  2. We have't been providing these new fields when we know them. We also haven't been consistently handling the update field which comes after the version.

  3. The URI format also introduced percent encoding for certain characters. We're almost certainly doing that incorrectly or incompletely.

Proposal:

  1. Add a new cpe23_fs field to contain the 2.3 formatted string format
  2. Add handling for the 4 new fields (sw_edition, target_sw, target_hw, language) in both the URI and formatted string output.
  3. Improve the documentation around CPEs, generation, etc. where appropriate.

Thoughts @p0lr @hdm ?

Reference:

  1. https://www.govinfo.gov/content/pkg/GOVPUB-C13-c213837a04c3bcc778ebfd420c6a3f2a/pdf/GOVPUB-C13-c213837a04c3bcc778ebfd420c6a3f2a.pdf
commented

Do we also want to deprecate the cpe23 field? Any reason to leave it this way instead of perhaps removing it later and, if kept, making a distinct cpe23_22compat field with its contents?