Skip to content

Running subscans effectively

Basic binary scanning strategies

The Weak binaries page serves as a good starting point for analyzing a firmware using PRIS. The simplest technique to find actionable vulnerability alerts is to rely on BugProve’s heuristic score to select binaries for further analysis. This will be the default behaviour during firmware scans if you don’t specify advanced options when starting scans.
In order to investigate more binaries, you can try to sort on the Score column or individual unsafe function columns to direct your attention. In order to find command injection vulnerabilities, for example, you should order the table on system() counters, and run PRIS scans for binaries that look suspicous based on their Risk Score or due to some other reason.

If you were after vulnerabilities that are almost surely exploitable, you should do the same by focusing on binaries with a high score that have the fewest hardening flags set for them.

IoT devices with web Interfaces

With embedded devices that feature a web interface it is often the case that HTTP request handling is the largest attack surface that adversaries might target. Therefore, it is important to make sure that the web server executable, associated libraries, CGI files and scripts are all resistant against specially crafted user input.

IoT systems are very heterogenous, so there isn’t a single embedded web interface implementation that we can investigate (some popular ones include Lighttpd, Boa, uC-HTTP, apache, etc). However, in our professional experience, there are three main different ways used in firmware to address this:

  • Option 1. A monolithic embedded web server executable is present on the system that includes vendor specific modifications in-binary. CGI requests or other routes used by the web frontend are implemented inside the executable as separate functions (but not separate binaries), usually dispatched via a function pointer table.
  • Option 2. An embedded web server executable is present on the system with little vendor specific code modifications, configured to handle CGI requests via standard ways. On HTTP requests, the server executes separate ELF CGI executables on the file system and passes input data to those via environment variables.
  • Option 3. An embedded web server is present, configured to support a rich gateway for running interpreted scripts or programming languages, such as PHP, Python or Lua. Web interface related business logic is not implemented in binary, but in one of these languages.

Now, unfortunately, PRIS based analysis can’t tackle Option 3.

In order to find potential vulnerabilities in case we have Option 1 is simply to find the web server executable (httpd, boa, etc.) and run a PRIS subscan on it.

For Option 2, however, we have a cool trick that could potentially result in 0-day vulnerability alerts with RCE impact.💡

Use the Weak binaries page and try to filter on CGI executables. The search will actually look into the full paths of the binaries and recognize if they are located in something like a /cgi-bin/ folder.

Filtering on CGI files in Weak binaries
Filtering on CGI files in Weak binaries

Use the score values and your own analysis guide you on selecting CGI executables for execution. These are usually small and self-contained binaries, resulting in clean and quick PRIS findings.

IoT Devices with networking 😈 daemons

Similarly to web interfaces, any network facing executable poses a serious risk to the device if the implementation is prone to vulnerabilities or lacks strong input validation measures.

Use Weak binaries to identify these and execute PRIS scans on them to see if they are vulnerable.