More DHCP-based fingerprints

[dmoinescu-r7]

Description

Added more fingerprints from observed DHCP vendor_class strings:

• Huawei Android
• Cisco IP Phones
• Cisco Wireless Phones
• Cisco Aironet Wireless Access Points
• Cisco Catalyst Wireless Access Points
• Cisco Integrated Access Points
• Cisco Wireless Controllers

Motivation and Context

These fingerprints can be used for identifying network devices based on the DHCP fields they advertise

How Has This Been Tested?

Ran ./bin/recog_verify xml/dhcp_vendor_class.xml

Types of changes

• New fingerprints

Checklist:

• I have updated the documentation accordingly (or changes are not required).
• I have added tests to cover my changes (or new tests are not required).
• All new and existing tests passed.

[mkienow-r7]

1. Escape the period in Inc\. otherwise we'll match any character in that position.
2. Tighten the regex rather than allowing unbounded matches that may result in unexpected matches and captures as well as possible performance issues. Is there a reason we couldn't use something like (CP-\d+G?) instead of (.*)? Note, I derived the pattern from this existing sip banners fingerprint.
3. Is there any reason not to have an end of string anchor?

[dmoinescu-r7]

I added a size limit and an end-of-string anchor. I don't see any benefit in making the model regexp more complicated (something like CP-?\d{4}(?:G|G-GE)?), since that would decrease readability and performance at the same time.

[TomSellers]

Here and elsewhere for Aironet:

IMO, The value for hw.model should not contain the c prefix. Cisco doesn't use it in human consumable marketing and it enables use to generate CPEs for the devices.

Example hardware CPES:

h:cisco:aironet_1815t
h:cisco:aironet_1815w
h:cisco:aironet_1830
h:cisco:aironet_1830e
h:cisco:aironet_1830i

Example OS CPE

o:cisco:aironet_1800_firmware
o:cisco:aironet_1800i_firmware
o:cisco:aironet_1810_firmware
o:cisco:aironet_1810w_firmware

Assuming the example of Cisco AP c1830 I recommend hw.model be 1830 adding the following attributes:

    <param pos="0" name="hw.product" value="Aironet {hw.model}"/>
    <param pos="0" name="os.product" value="Aironet {hw.model} Firmware"/>
    <param pos="0" name="os.device" value="WAP"/>

[dmoinescu-r7]

updated

[mkienow-r7]

The updated pattern won't capture model numbers that include a letter after the numeric model number as show in the sample hardware and OS CPEs shared above, for example, 1830i. @TomSellers we would want to capture the letter at the end of the numeric number, correct?

[dmoinescu-r7]

updated

[mkienow-r7]

I was taking a look at this fingerprint again after looking over the NVD CPEs and it appears the capture should include the value after the dash as a part of the model number.

For example, the value "Cisco Systems, Inc. IP Phone CP-7941G-GE" would currently result in the CPE h:cisco:unified_ip_phone_7941g, however, the model is "7941G-GE" and NVD contains the CPE h:cisco:unified_ip_phone_7941g-ge.

[dmoinescu-r7]

As far as I can tell, the CPE contains the following entries for 7941:

h:cisco:unified_ip_phone_7941g
h:cisco:unified_ip_phone_7941g-ge

o:cisco:unified_ip_phone_firmware_7941g
o:cisco:unified_ip_phone_7941g_firmware

So both the G and GE models are present, but firmware only for G. I've no idea what the correct approach is (for instance, can anything bad happen if we refer to an inexistent firmware model?), so I'm totally happy to take guidance.

[mkienow-r7]

@dmoinescu-r7 I understand the confusion. The CPEs from NVD are frequently added based on existing CVEs and sometimes reflect different naming decisions based on the individual that added them to the NVD database. In addition, understanding the reason for differences might require additional research into particular model(s) when possible. It appears we've identified an odd edge case with the 7941g model hardware and firmware. I would error on the side of emitting values that match the known model number. When we know we have the 7941g-ge model we should emit values that match known CPEs with that model number. If we were to learn that the 7941g-ge is simply a hardware revision and uses the 7941g firmware we might carve off the -ge models into their own fingerprint allowing us more flexibility over formatting the params for those models. In general, one uses NVD data to guide formatting the various params. I would advise selecting the format that matches the greatest number in the NVD database. @TomSellers do you have anything you would like to add here?

Looking closer at the full list of cisco:unified_ip_phone_ CPEs it appears the fingerprint pattern could be extended to match two more models that include nr after the numeric model.

h:cisco:unified_ip_phone_8851nr
h:cisco:unified_ip_phone_8865nr

o:cisco:unified_ip_phone_8851nr_firmware
o:cisco:unified_ip_phone_8865nr_firmware

From the perspective of new fingerprints there would be no failures caused by a reference to a nonexistent firmware model. It is simply data enrichment, but it is best to figure this out when the fingerprint is first added. As you discovered earlier the update_cpes.py script doesn't currently support strings that embed {hw.model}, therefore, it won't emit the *.cpe23 params. Formatting the product params correctly now, will allow them to be emitted in the future when the tool is enhanced.

We should schedule a call this week to discuss the joys of CPE in greater detail. :)

[dmoinescu-r7]

updated to allow for trailing NR

[mkienow-r7]

I mentioned this on our call today, but wanted to document in the PR. We should consider matching the models that include nr after the numeric model number (there are 4 cisco:unified_ip_phone_ CPEs that include the model number).

[mkienow-r7]

Thank you for the contribution @dmoinescu-r7!