HTML toggles for false positives

[m-1-k-3]

This issue was originally reported in the EMBA area: e-m-b-a/emba#193

This is a tall order but would be nice for the roadmap

In most cases. the discoveries for the CVEs don't actually affect the product. For example, if I'm running a kernel version that has 200 CVE's and 7 exploits. When I look at those findings I notice the CVE's are just a raw version analysis but if you dig down into the CVE it can say stuff like "If IPV6 is enabled" "IF the following flag is enabled in x config". IT would be nice to have the ability to go into the HTML report and maybe toggle stuff off that you know is a false positive.

Kina like this project lets you do https://github.com/Guezone/SECMON.

The toggling could let you generate an XML or something that logs the CVE's that you could apply to your next scan --fpxml

[BenediktMKuehne]

Since White-listing CVEs wouldn't be the best idea, I would suggest doing the opposite and adding a Blacklist-Filter to the Report-Dashboard or to EMBAs html-report directly.
Maybe a filter navbar for CVEs, firmware, software-components etc.

[keesj-exset]

I think this problem is mostly present for the Linux kernel. We ran an analysis and found a zillion CVEs. At the same time
EMBA did find the kernel (possibly the kernel configuration) was would be really nice would be to combine both of them. e.g. try to determine if a module / configuration was enabled).

At the same time in the scan we did the from 10.0 severity issue we consider that only the one remotely exploitable are of relevance. This of course depends on the use for the firmware (quite a few bug where in the DVB subsystem).

while brainstorming it would be nice to be able to store some of those choices..

[m-1-k-3]

Currently the EMBArk report is quite limited in this area. Instead, you can use the f20 log files with all the details from EMBA. You could just do a bit of grep to get all the remote exploits:

└─$ grep CVE ~/firmware/emba_logs_manual/dir300/f20_vul_aggregator.txt | grep Exploit | grep "(R)"

Another help is the final report which also shows you how many remote exploits are available:

In the future we will include a csv report of f20 which will simplify things and probably can be used in EMBArk.

[m-1-k-3]

Does it makes sense to load a CVE blacklist file from the config directory?
The idea is that you can for example place multiple CVE lists in the config directory and create a scan profile per cve list. This give you the possibility to collect the kernel CVEs into a file and ignore it in the future. Another possibility would be to generate CVE lists for Metasploit exploits and so you can generate a list for Metasploit exploits and so on.

[keesj-exset]

Hi, we have used emba in several projects. In all cases we found issues where if we wanted to use the statistics it was required to make substantial changes to the report. We did not follow this approach but instead used emba as a good indicator of the state of the system. I will name a few problems I saw here

• (R) Remote : The definition is up for interpretation but we consider remote as "over the network" this means that an exploit that can be triggered over the local network will be regarded as remote. We have had reports showing no "remote" exploitable code while the reality was that there were entries that in fact were. Missing entries in this area makes exploit selection harder. Still emba was pretty good e.g. for the kernel we would select the top 20 entries en manually go through them. An example of this was https://nvd.nist.gov/vuln/detail/CVE-2017-18017
• Some builds (bitbake or buildroot) can add additional strings to the version e.g. instead of libbla having version 1.2 the software will add abc_1.2. In such cases there is a need to filter the versions for emba to correctly find problems.
• We had emba incorrectly find an "linux 2.4" kernel and you might guess this messed up the whole report :P

Overall perhaps adding the option to filter data(python/shell code) can be used to fix a few of those issues e.g. allowing to

• filter versions (modify)
• skip versions/components
• possibly filter modify or skip CVE entries.

In our setting we are writing the report using overleaf (latex) so .. a lot of work is still manual.

As "user" I did not easily found/understood how to make such modifications to the system without building it all myself.

[keesj-exset]

it might also be possible to generate issues that are then for example imported into writehat https://github.com/blacklanternsecurity/writehat this could allow to remove / modify content "post" reporting.

[m-1-k-3]

@keesj-exset can you provide example firmware for the additional version strings and the linux 2.4 false positive? These things should be fixable.
Regarding the category of remote exploitability EMBA is based on the details from exploit-db or Metasploit. I'm currently thinking if it makes more sense to use CVSS vector for this rating.

[m-1-k-3]

I think the best way to handle the complete process is to load the generated SBOMs into dependency track here https://dependencytrack.org/