Improve "ISC DHCP" detection and CVE search

[gluesmith2021]

Is your feature request related to a problem? Please describe.

There are missing CVE in results for ISC DHCP Client/Server, and this is in part related to a cpe naming issue in NVD data.

In NVD database cpe strings, isc:dhcp_client CVEs seems to apply a DHCP "client", while isc:dhcpd CVEs apply to the server component instead. However, in many CVEs the string isc:dhcp is used instead, for both client and server components.

For example, CVE-2018-5732 applies to the client, while CVE-2018-5733 apply to the server part. Both use cpe:2.3:a:isc:dhcp:*:... among others. Only the textual description allows to discriminate.

The choice of one or the other might be related to the CVE year, since only a single name is used per year. Of course, that might be a mere coincidence as well:

• 1999-2000: dhcp_client
• 2002-2006: dhcpd
• 2009-2018: dhcp
• 2019: dhcpd
• 2021-2022: dhcp

Describe the solution you'd like

First, EMBA could detect "ISC DHCP Server" as well, just like the client currently is.

Second, given that NVD DB does not discriminate between "client" and "server" in using isc:dhcp, EMBA could somehow aggreate CVEs using:

• isc:dhcp_client and isc_dhcp for the client
• isc:dhcpd and isc_dhcp for the server

This will brings false positives in aggregated CVEs, but the NVD database does not allow to discriminate better. Right now, we have false negatives (missing CVEs) given that EMBA only search for dhcp_client.

Describe alternatives you've considered

Changing the string replacements in bin_version_strings.cfg as in original PR #1150 before changes were reverted. The string replacement mechanism alone does not allow for the above solution.

Priority issue
Are you already a Sponsor? N

Additional context

I had to analyze a firmware image that had both client and server DHCP binaries, and the identification string is straightforward. Version however is not detectable from S09 as it is not part of the identification string. S116 can detect it though. In my case, both were version 4.3.4 from 2016. EMBA would report isc:dhcp_client for the client, and not report the server at all. In both case, it misses the few CVEs that apply to that version:

• In /sbin/dhclient file: Internet Systems Consortium DHCP Client
• In/usr/sbin/dhcpd file: Internet Systems Consortium DHCP Server
• From S116 on /sbin/dhclient:
  • Internet Systems Consortium DHCP Client 4.3.4
  • isc-dhclient-4.3.4

[m-1-k-3]

As a first step we could include fresh identifiers for the dhcpd (server) to identify it in s09 via cpe: "isc:dhcpd:version"

└─$ grep "cpe.*isc:dhcpd" external/nvd-json-data-feeds/* -r | wc -l
56
└─$ grep "cpe.*isc:dhcp_client" external/nvd-json-data-feeds/* -r | wc -l
4

For the server identification just isc:dhcp: would work not too bad. As far as I can see most of the available CVEs are server related:

└─$ grep "cpe.*isc:dhcp:" external/nvd-json-data-feeds/* -r

This will not solve the main issue but will allow us to improve the detection in this area a little bit. What do you think?

[gluesmith2021]

Sounds like a fair solution to me. The vast majority of isc:dhcp CVEs indeed apply to the server.

In practice, I see two cases:

1. DHCP server is detected (by the new rules), EMBA then reports both server-side and client-side CVEs from isc:dhcp. Sounds good to me:
   • The analyzed system is quite likely to contain the corresponding client as well (reported as isc:dhcp_client), there will be no false postives/negatives overall.
   • Only "error" would be that some CVE will be reported under the wrong product, but that's as far as the NVD database gets us.
2. On a client-only system, the few client-side isc:dhcp CVEs will go missing. Probably not that bad:
   • Avoids the noise of a bunch of server-side false positives.
   • In the "analyst wants it all" scenario, analyst would likely use multiple analysis tools anyway.

Thank you for your prompt response so far (here and in other PR/Issues). It's nice to see a very-actively maintained project.

[m-1-k-3]

Could you include the new identifiers in the config and provide the binaries for verification testing?

[gluesmith2021]

• I'm not sure what you mean by "include fresh identifiers for S09". In the current case, S09 can't identify either product.
• Then, in config file, should that resolve to isc:dhcp or isc:dhcpd? isc:dhcp has much more CVEs, but I just realized from your solution above that we can't have both.

In the meantime, here are the two binary files.

dhcp.zip

Those are 32-bit ARM ELF. Running them with --version and -help (an unknown command but gives "help" anyway) gives:

isc-dhclient-4.3.4

Internet Systems Consortium DHCP Client 4.3.4
...

isc-dhcpd-4.3.4

Internet Systems Consortium DHCP Server 4.3.4
...

[m-1-k-3]

• I'm not sure what you mean by "include fresh identifiers for S09". In the current case, S09 can't identify either product.

sorry for the misunderstanding. S09 is the static analysis module for version detection. In comparison to that the modules s115 and s116 are doing dynamic analysis via qemu execution. Both are using the same config file. So, I would recommend to include the version identifiers into the config file and verify them afterwards with a default run of EMBA.

• Then, in config file, should that resolve to isc:dhcp or isc:dhcpd? isc:dhcp has much more CVEs, but I just realized from your solution above that we can't have both.

I think we need to deal with both of them.

In the meantime, here are the two binary files.

dhcp.zip

Those are 32-bit ARM ELF. Running them with --version and -help (an unknown command but gives "help" anyway) gives:

is the EMBA s115 module able to get the help out of it?

isc-dhclient-4.3.4

Internet Systems Consortium DHCP Client 4.3.4
...

isc-dhcpd-4.3.4

Internet Systems Consortium DHCP Server 4.3.4
...

[m-1-k-3]

after a quick static check we can implement the following rules:

dhcpd -> multi_grep rule - see here

1st identifier:

└─$ strings dhcpd | grep -E "Internet Systems Consortium DHCP Server"
Internet Systems Consortium DHCP Server

2nd identifier (reflects the version)

└─$ strings dhcpd | grep -E "^[0-9]+\.[0-9]+\.[0-9]+$"
4.3.4

This should then give the rules like the following - please take a look and verify/fix them (these are more blind guesses)

dhcpd;multi_grep;ISC;'"^Internet Systems Consortium DHCP Server$"&&"^[0-9](\.[0-9]+)+?$";"sed -r 's/([0-9]+(\.[0-9]+)+?)/dhcpd:\1/'";
dhcpd;multi_grep;ISC;'"^Internet Systems Consortium DHCP Server$"&&"^[0-9](\.[0-9]+)+?$";"sed -r 's/([0-9]+(\.[0-9]+)+?)/dhcp:\1/'";

If the emulator also prints the version like the following

Internet Systems Consortium DHCP Server 4.3.4

we can include the additional rules for the emulator:

dhcp;no_static;ISC;'"^Internet Systems Consortium DHCP Server [0-9](\.[0-9]+)+?$";"sed -r 's/Internet Systems Consortium DHCP Server ([0-9]+(\.[0-9]+)+?)/dhcp:\1/'";
dhcpd;no_static;ISC;'"^Internet Systems Consortium DHCP Server [0-9](\.[0-9]+)+?$";"sed -r 's/Internet Systems Consortium DHCP Server ([0-9]+(\.[0-9]+)+?)/dhcpd:\1/'";

Does this makes sense for you?

[gluesmith2021]

I made a few tests (about one analysis per day, given the time it takes) and I'm getting results. I'll create a pull request when everything works. So far, I had to:

• add string rules as above
• fix emulation blacklisting so that dhcp and dhcpd are not blacklisted by udhcpd

Then I had issues with F20. I noticed that the sed replacement command sometimes replaces the string with vendor:product:version (e.g.: isc:dhcp_client:\1) but most often with product:version only (e.g.: iptables:\1). However, F20 can't cope well with the three part string. For example, it can find vulnerabilities for dhcp:4.3.4 but not isc:dhcp:4.3.4. In the latter case, the first grep looks for ...*:4.3.4:*... or *isc:4.3.4:* which does return product names ending with isc, not dhcp.

So, before I remove all isc: is sed expression

• is there any reason why some have the vendor in it and other don't?
• Should F20 be able to handle both cases? (there are many other cases that fail right now if it doesn't)

[m-1-k-3]

hmm ... we have identifiers in the format vendor:product:version: but also product:version: and F20 should be able to deal with both of them.
The short identifiers are somehow legacy but usually working quite well. The longer identifiers are the way to go. I think there are some parsing issues in the output of F20 or F50 which we need to address in the future. Nevertheless, the vulnerability identification should work with both (long and short). If there are issues we need to take a look at it. Do you have non working examples?

[gluesmith2021]

Indeed, F20 fails to retrieve CVEs for isc:dhcp:version as with its first grep to get potential CVE, it searches for either the exact version, or :.*${BIN_NAME}:\*:. In that case, BIN_NAME is extracted as isc, not dhcp. Therefore it gets any product name that "ends with isc".

Oddly enough, F20 handles and remove vendor name in other cases, such as in its log for CVE search.

In other words, looking at F20 log:

• with isc:dhcp in sed replacement:

[+] Found Version details (aggregated): isc:dhcp:4.3.4

...

[*] Vulnerability details for dhcp / version 4.3.4 / source UEMU:
[-] Found NO CVEs and NO exploits (including POC's) in dhcp with version 4.3.4 (source UEMU).

• when using dhcp only in sed replacement, it finds 4 correct vulnerabilities:

[+] Found Version details (aggregated): dhcp:4.3.4

...

[*] Vulnerability details for dhcp / version 4.3.4 / source UEMU:

�[0;32m	BIN NAME            :   BIN VERS    :   CVE ID            :  CVSS VALUE : EPSS :   SOURCE         :   EXPLOIT�[0m
�[0;31m	dhcp                :   4.3.4       :   CVE-2017-3144     :   7.5       :  NA  :   UEMU           :   No exploit available�[0m
�[0;31m	dhcp                :   4.3.4       :   CVE-2018-5732     :   7.5       :  NA  :   UEMU           :   No exploit available�[0m
�[0;31m	dhcp                :   4.3.4       :   CVE-2018-5733     :   7.5       :  NA  :   UEMU           :   No exploit available�[0m
�[0;33m	dhcp                :   4.3.4       :   CVE-2022-2929     :   6.5       :  NA  :   UEMU           :   No exploit available�[0m

[+] Found 4 CVEs and 0 exploits (including POC's) in dhcp with version 4.3.4 (source UEMU).

[m-1-k-3]

Thx for testing ... I need to check this.

[m-1-k-3]

sorry for the delay and lack of intense tests. As I'm out of office I have just limited time ... Currently I'm just poking around and trying to reproduce the issue between long and short version identifier

Indeed, F20 fails to retrieve CVEs for isc:dhcp:version as with its first grep to get potential CVE, it searches for either the exact version, or :.*${BIN_NAME}:\*:. In that case, BIN_NAME is extracted as isc, not dhcp. Therefore it gets any product name that "ends with isc".

The following should extract the version:

emba/modules/F20_vul_aggregator.sh

Line 621 in c590aee

BIN_VERSION_ONLY=$(echo "${BIN_VERSION_%:}" | rev | cut -d':' -f1 | rev)

ASDF="isc:dhcpd:4.3.4:"
└─$ echo "${ASDF%:}" | rev | cut -d':' -f1 | rev
4.3.4

looks good

Next it extracts the name:

emba/modules/F20_vul_aggregator.sh

Line 623 in c590aee

BIN_NAME=$(echo "${BIN_VERSION_%:}" | rev | cut -d':' -f2 | rev)

└─$ echo "${ASDF%:}" | rev | cut -d':' -f2 | rev
dhcpd

looks also good

If we grep for the long identifier here

emba/modules/F20_vul_aggregator.sh

Line 651 in c590aee

if grep -q "cpe.*:${BIN_VERSION_%:}:" "${CVE_VER_SOURCES_FILE}"; then

we have a vuln and log it. Otherwise we check for further criteria with the short name of binary which should be fine.

[m-1-k-3]

I think I got it ...

emba/modules/F20_vul_aggregator.sh

Line 534 in c590aee

BIN_NAME=$(echo "${BIN_VERSION_}" | cut -d':' -f1)

[m-1-k-3]

I think we are done for now. See you next time again :)