Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Binary code scanners, like purchasing security vulnerability insurance

In my previous article, “How to address the IoT security ticking time bomb,” we examined the expected growth of the IoT devices and components market, which according to Boston Consulting Group is expected to reach $267 billion in sales by 2020. I also highlighted the firmware security vulnerabilities that, if left unaddressed, will significantly impair IoT adoption and growth.

To recap, most of the firmware built into embedded parts and IoT devices use open source software components. Newer versions of these components are available without the security vulnerabilities. Nevertheless, it ranges from challenging to impossible for OEM development teams and their third-party software suppliers to accurately and effectively track all open source software components in their code, especially when their main focus is to concentrate on developing higher-order systems.


Because the majority of firmware is sourced externally or contains code from third-party vendors that is built using open source code components. Also, third-party code is usually distributed in binary format without the source code. This makes it nearly impossible to initially identify any potential known security vulnerabilities. As more known security vulnerabilities make their way into shipping firmware, the likelihood of litigation initiated by consumers, distributors or OEMs is very likely to flourish.

Given that the vulnerabilities are in the firmware and the code is often procured in binary format, the most efficient and cost-effective manner is to use a binary code scanner. According to Gartner, analysis of the compiled binary code is important if you don’t have the source code of the original application to analyze. Think of it as purchasing known security vulnerability insurance.

There are really four technologies from which developers can choose: static code analyzers and checksum, hash and fingerprint-based binary code scanners. Each provides value depending on the job required.

Why static code analyzers are not optimum for binary code scanning

There are three primary ways to perform static analysis: an examination of the byte code of an interpreted language like Java, an analysis of the source code or an examination of the raw binaries.

There are no pure-play static binary code analyzers. Static code analyzers that purport to examine binary code disassemble it first and then analyze the reconfigured source code for common programming errors. Interestingly, in many countries, including the U.S., disassembly of licensed third-party code is construed as reverse engineering, and therefore a violation of intellectual property laws.

As a best practice, pure-play binary code scanners should be used as the first line of defense because they look for known security vulnerabilities.

Checksum, hash and code fingerprint-based binary code scanners

For some time, checksum and hash-based binary code scanners have been used to find known security vulnerabilities. Despite their reasonable efficacy, they have been constrained by limited databases of precompiled binaries of the most commonly used open source components.

Today, there are binary code scanners that use code fingerprint-based algorithms. They examine “fingerprints” extracted from a binary, which are then compared to fingerprints collected from open source components hosted in numerous open source repositories. Once a component and its version are identified through this fingerprint-based matching, it is straightforward to locate known security vulnerabilities associated with the component from vulnerability databases, such as the National Vulnerability Database (NVD).

Another advantage of fingerprint-based scanners is their robust ability to identify a modified version of an open source software component when compared to checksum scanners. Additionally, unlike checksum or hash-based binary scanners, fingerprint-based scanners don’t need to keep separate databases of checksums or hash values for different CPU architectures. This capability significantly increases their flexibility and accuracy in comparison to legacy binary code scanners.

Fingerprint binary code scanners

OEMs should consider two fingerprint-based binary code scanners as the first and best line of defense against security vulnerabilities. The first is the Binary Analysis Tool (BAT). It has been successfully used for more than six years.

The other is a commercially available software and cloud-based service that uses the technology behind the BAT. With it, developers and users can quickly and easily scan open source software in their embedded applications and IoT devices to identify more than 180,000 known security vulnerabilities, cataloged in numerous databases. These vulnerability databases, which include the NVD and VulnDB, among others, are updated daily. The commercial product also adds enterprise support, “fuzzy matching” of binary code and support for automated build systems like Jenkins.

As a best practice, OEMs should start checking for firmware vulnerabilities with fingerprint-based scanning and then patch the security vulnerabilities before using optional tools. If an organization is faced with financial or time constraints, it should consider fingerprint-based binary code scanning as the bare minimum.

All IoT Agenda network contributors are responsible for the content and accuracy of their posts. Opinions are of the writers and do not necessarily convey the thoughts of IoT Agenda.

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

We've recently purchase a FortiGate 100D UTM appliance, and are using it with version 5 of its FortiOS software.
We find the documentation to be too-long, confusingly structured, inaccurate both technically in describing concepts and practically in that the documentation sometimes mismatches how the FortiGate device and its FortiOS software actually work, as well as buggy (or some might say that it has curious "features").

Examples include insistence in the docs that a magical "ssl.root" pseudo-interface must exist in policies in order for VPN traffic to be able to transit the appliance. But I have no reference whatsoever to ssl.root and my VPNs work. They also NAT, even though I can't find where that NAT is enabled...

The process for installing a proper CA-issued SSL certificate for the SSL VPN is documented ... but neither where nor how you expect, leading to lost time until we found a forum post explaining how to do it.

The FortiClient (for Windows, MacOSX, Linux and Android) is NOT one client, but rather three or four separate products, each with different features/capabilities, limitations, usability and bugs. (iOS has no FortiClient, can only access FortiGate VPN via IPsec, and requires a completely separate VPN server configuration on the FortiGate appliance from the other VPN client types).

We have encountered weird routing issues with a completely disconnected "Management" interface on the appliance, when we connect IPsec VPN clients. Other users have confirmed it; FortiNet has reproduced it ... and there is neither explanation nor answer (although we do know the workaround - make sure that the Management interface’s IP address configuration is cleared, itself requiring the unintuitive assignment, as you cannot leave the field simply blank).

The FortiToken service can be broken (as in, made to not work correctly). FortiNet insists on putting its token configuration and licensing servers between your FortiGate appliance and the 2-factor authentication client on your users' endpoints, instead of enabling general OAUTH compliant tokens to be serviced directly from the FortiGate appliance. This is a(n artificial) revenue stream for FortiNet, and an operational pain for you (refer back to "I broke it" - I now have a FortiToken which cannot be used, associated with a user configured on the FortiGate appliance which cannot be edited while that token is associated; FortiNet support has been working on this for a week so far without positive result).

The Firewall Policy user interface on the FortiGate appliance blends conventional firewall policies (from interface, from source IP address ranges, to interface, to destination IP address ranges, date/time, services, permissions and whether to NAT) with VPN specific policies which include authentication and access magic, in a single table-style user interface. The column names for both conventional and VPN policies are “From” and “To”, but they mean different things in the context of a conventional Firewall policy statement versus a FortiNet VPN specific policy statement. And the summary shown in the table display of the policies hides much critical detail, making it easy to misunderstand the rules as they already exist.

The use of user authentication groups to associate a user with a particular SSL VPN “Portal” (which is not a VPN, it’s an SSL protected web page which offers portal functionality, optionally also with proxies; but it also is the way that SSL VPN real VPN connections are set up) can cause non-deterministic results depending on the order in which the user’s group affiliations are enumerated and the order in which those are checked against the available SSL VPN portal configurations. This can cause some strange behaviors (obviously valid user login attempts getting errors) and requires excess caution in configuration and in ordering certain policy statements.

And more.
In short, for such a mature product, it is unnecessarily opaque to configure, surprisingly poorly documented for all of its verbosity, and buggy.

I imagine that after absorbing the frustrations which come out of these things, and the significantly larger than should-have-been-necessary amount of time to learn the FortiNet way of doing things (plus the workarounds for incorrect docs, software bugs, etc), that it will prove to be a highly functional and very reasonably priced solution. But I had expected much better.