Scanning principle of EMBA

[shadowhunter-YC]

I want to know the principle of CVE detection. Does it only use version number matching? Are there any other matching mechanisms?

Our team conducted some tests on CVE and found that the false positive rate of this EMBA is relatively high. We speculate that this EMBA will only detect version information in the system kernel and place it in the database for version number matching, and it will not check the version number of the compiled software. For example, there were originally two software packages, ssh and busybox, in the system kernel, but I only used ssh as the only package. In this case, EMBA will scan both software packages, which will cause more false positives

Our team manually checked the EMBA scan results of some software packages and found that although many of them mentioned CVE vulnerabilities, our software engineers did not actually use the software.

Is there any way to reduce the false positive rate of vulnerabilities?

[shadowhunter-YC]

Additionally, if there are no root files found in the firmware package, such as www, var, bin, rootfs, and only some ELF, XML, HTML, or RSA files, will there be no software CVE vulnerabilities in this situation?

[m-1-k-3]

Perfect if you found false positives and issues in EMBA ;)

Please provide examples with test firmware for reproducing. Otherwise we are not able to fix these issues.

You can also check our version identifiers here: https://github.com/e-m-b-a/emba/blob/master/config/bin_version_strings.cfg And further documentation here https://github.com/e-m-b-a/emba/wiki/User-mode-Emulator

[shadowhunter-YC]

Additionally, if there are no root files found in the firmware package, such as www, var, bin, rootfs, and only some ELF, XML, HTML, or RSA files, will there be no software CVE vulnerabilities in this situation?

[m-1-k-3]

This wiki entry should help you: https://github.com/e-m-b-a/emba/wiki/OS-support#vxworks-based-firmware

At the end you need to test it ...

[shadowhunter-YC]

I found the following sentence in the URL： https://github.com/e-m-b-a/emba/blob/master/config/bin_version_strings.cfg ”no_static -> typically this rule produces false positives in static analysis -> only use this rule in emulation mode” Does this mean that most software versions will generate false positives？

[shadowhunter-YC]

I encountered the same problem as this one: https://github.com/e-m-b-a/emba/issues/193 I want to know if EMBA can solve this problem now

[m-1-k-3]

You can use the cve-black and whitelists here https://github.com/e-m-b-a/emba/blob/master/config/cve-blacklist.txt and here https://github.com/e-m-b-a/emba/blob/master/config/cve-whitelist.txt

[shadowhunter-YC]

May I ask if CVE detection is only based on version number matching? Are there any other rules?

[m-1-k-3]

The CVE detection is a bit more complicated.

• The mechanism is based on the version detection regex rules defined here
• These rules are then modified with sed (same config) to query the cve database via cve-search
• For the detection by itself we have multiple modules:
  • s06 for distribution identification (rules are coded in the module)
  • s08 for package management
  • s09 for static detection
  • s24/s25 for kernel version detection
  • s26 for kernel vulnerbility detection/verification based on the kernel config or extracted symbols
  • s115/s116 for user-mode emulation
  • L10/L15 for detection in system mode emulation via Nmap scanning
  • L25 for web server detection (in system mode emulation)
  • L35 for CVE detection via exploitation from Metasploit
• F20 is finally the aggregator module which brings everything together

As you can see the CVE/version detection is not that easy. Every module has its own advantages and disadvantages. Some are only running for special firmwares and if some special conditions are met.

[m-1-k-3]

Without the firmware which was used and produced the high number of false positives we can't further help. Closing for now ... please re-open if needed with a dedicatet firmware example