In October 2018, Government of UK published code of practice for IoT vendors to improve the security of consumer IoT products. In this blog post, we explore those guidelines that are applicable to IoT device manufacturers and show how they can be addressed automatically using Firmalyzer platform.

The document listed 13 guidelines for consumer IoT devices that are connected to the Internet and/or home network such as smart cameras, TVs, home appliances and home automation systems. The GOV.UK guidelines can also be mapped to several industry standards and best practices on IoT security that includes ENISA and IoT Security Foundation. A detailed mapping between these guidelines has been published in a separate document. The following guidelines were concerned with secure firmware development:

  1. No default passwords

  2. Keep software updated

  3. Securely store credentials and security-sensitive data

  4. Communicate Securely

  5. Minimise exposed attack surfaces

  6. Validate input data

Firmalyzer helps device manufacturers to adapt these guidelines in an automated, continuous and cost-effective way through device firmware risk analysis. The following sections outline mapping between every or multiple guideline(s) and relevant analysis module of Firmalyzer. We also demonstrate examples of security vulnerabilities discovered by Firmalyzer, in real world products that were the results of failure to follow the guidelines.

No default passwords

Default passwords have been the root cause of many IoT security incidents and malware attacks. 
The credentials scanner module of Firmalyzer inspects application and configuration files extracted from firmware image to discover hardcoded passwords.

The following figure shows credential scanner report that highlighted password file from a firmware that has a high privilege account (root) with a default password.   

Figure 1 - default password found by credential scanner module


Keep software updated

Device manufacturers should track published security vulnerabilities and fixes for operating system, 3rd party components and libraries they use so that they can update the firmware of their customer devices with security patches on time. In many cases, firmware development teams use third party components and libraries that may have dependencies on other libraries. As such, it is important to keep track of security vulnerabilities in all of software dependencies and to do so, it is required to identify all of the dependencies per application. Firmalyzer addresses these requirements in the following two steps: a) Its dependency analyzer module identifies 3rd party libraries of each executable or library file extracted from firmware together with their version number b) registers those modules with CVE vulnerability tracker module that monitors disclosed vulnerabilities in libraries and operating systems and automatically warns firmware development team of the exact binary files in the firmware that is affected by published vulnerability

Figure 2 - Vulnerable libraries highlighted by CVE tracker module

Securely store credentials and security-sensitive data

Device manufacturers should store cryptographic keys on secure storage provided by system on a chip (SoC). Keying material that are embedded in firmware although obfuscated or encrypted, can be reverse engineered and discovered by attackers. The crypto key scanner module of Firmalyzer examines the files in a given firmware to discover hard-coded cryptographic keys and reports their location and type. 

Figure 3 - Private key found by crypto scanner module

A device that uses such extractable and fixed symmetric or asymmetric encryption keys would be exposed to authentication bypass or  traffic eavesdropping attacks. 

Communicate Securely

Often times, firmware developers use cryptographic communication libraries such as OpenSSL for connecting devices to management server securely. If firmware developers do not follow security best practices when using such library APIs, it can expose IoT device to remote take over and data disclosure threats. The OpenSSL API auditor module of Firmalyzer, inspects extracted executable and library files from a firmware and reports API calls that can be exploited by remote attackers to eavesdrop on device to server communications  

The following figure shows warnings from OpenSSL API auditor module for “cloud device management agent” (/sbin/signalc) that was found on D-Link cloud routers. The lack of SSL/TLS certificate verification in this file could be used by a remote attacker to remotely take control of large number of routers via TLS Man-in-the-middle attacks. We demonstrated this attack in our lab, notified and helped the router manufacturer to fix the issue. More details on this vulnerability in available on this  page.   

 Figure 4 - vulnerable ssl connection found by  OpenSSL API auditor module


Minimise exposed attack surfaces

In most cases IoT developers use some ready-to-use embedded linux operating systems with default components that are not really required for the functionality of the device and thus should be removed. Firmalyzer helps device developers easily identify these components and remove unnecessary ones.

It also detects compilers and debuggers that developers sometimes forget to remove from production firmware. 

Figure 5 - debuggers found by debugger detection module


Another functionality of the platform to reduce attack surfaces and prevent buffer overflow attacks is being able to check for the security flags set during the compile-time.

Figure 6 - the status of security flags found by binary analysis module


Validate input data

Failure to properly validate data size, format and integrity is a common source of vulnerabilities in IoT devices. We have developed several Firmalyzer modules to analyze binary executable and libraries as well as PHP, Python, Java and JavaScript files to discover input validation vulnerabilities such as potential buffer overflows and remote command injection.     


Figure 7 - Potential XSS vulnerabilities highlighted by web security module

Figure 8 – Binary analysis module highlighting possible command injections