Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Firmware Reviewer Emulation Framework is an automated and scalable scalabile system for performing Dynamic Analysis of RTOS, QNX and Linux-based embedded Firmware, with No need of related physical Device.

...

The bootloader is the first code that is executed after a system reset. Its goal is to bring the system to a state in which it can perform its main function. This requires hardware initialization and choosing the correct image to load from flash or other sources. Because of its key role, the bootloader is usually placed in a part of the Flash that is protected from accidental erasure or corruption. Hardware initialization may imply enabling access to RAM, setting up clocks and PLLs, and configuring other key peripherals. However, hardware initialization should be restricted to the essential at this level leaving the rest of the initializations for upper application code. The bootloader is a critical part of an embedded system because, if it is corrupted, there is no solution to start a program or to update a new bootloader. This is the reason why today, in all systems, there is a safe bootloader, stocked in ROM. The users or extrernal systems cannot access this memory and so cannot modify it. In case of problem, the system can use this bootloader to start. Generally, it allows to download a new bootloader to fix the older one which has been corrupted. Our Emulation Framework can simulate a bootloader corruption and modify the bootloader, inserting a Bootloader Agent.

...

Modified Kernels

MIPS, ARM, PPC, x86 and other libnvram-compatible architectures are supported, for instrumentation of firmware execution

...

For example, here is a comparison of the same 24MB file after being put through the AES, 3DES, gzip and lzma algorithms:

Algorithm

Chi Square Distribution

Monte Carlo Pi Approximation Error

None

15048.60

.920%

AES

351.68

.022%

3DES

357.50

.029%

LZMA

253.54

.032%

Gzip

11814.28

.765%

As you can see, gzip has extreme differences between expected and observed data randomness, making it easy to identify. LZMA is much closer to the AES and 3DES encryption results, but still shows significant variations, particularly on the Chi Square distribution.

...

Consumer firmware are often limited in computing power. This limitation rules out slower, harder-to-crack asymmetrical encryption such as RSA. Also, vendors sometimes use the same encryption scheme for multiple routers. Look for routers that are in the same product line, with same processor architecture. Look around there and you might find the right decryption executable. In case of firmware related to Enteprise products, there is no easy method to obtain the decryption routine, other than using the Bootloader Agent.

Full system emulation

Sometimes, we’ll need to analyze the firmware more comprehensively and will benefit from full system emulation. There are many ways to fully emulate a device.

...

Several techniques exist for hardening ELF binaries in RTOS, QNX and Linux. Firmware Reviewer is able to detect them all and measure their level of hardening.

...

Debugging Information

Discover debugging information, like: Left developer’s configuration files, SCM archives (GIT, SVN, CVS, etc.), Debuggable executables and Libraries. Debugging information in beta versions of IoT devices equips developers with internal systems knowledge of a device. Unfortunately, debugging systems are often left in production devices, giving hackers access to the same inside knowledge of a device.

...

Finds backdoors based in: Suspicious open TCP ports, suspicious connection to external IPs and URIs, presence of Non-standard services and Suspicious executables. When it comes to firmware, hidden backdoors are a favorite hacker exploit. Backdoors are intentional vulnerabilities that are planted into an embedded device to provide remote access to anyone with the "secret" authentication information. Although backdoors are potentially helpful for customer support, when they're discovered by malicious actors, they can have severe consequences. And hackers are great at finding them.

...

...

Insecure executables

Firmware Reviewer detects exposed vulnerable standard library functions, like strcpy, sprintf, strcat, strncat, memcpy, memmove, gets, getw, scanf, system, etc, by analyzing all binaries existing in the firmware. They can expose it to Buffer Overflow, Heap Overflow and Stack Overflow, DoS, Comman Command Injection and Integer Overflow vulnerabilities, as described by CISA CERT coding practices and CERT C Secure Coding Standard. They can be included both in system components and application components. In case of system components it is suggested to update to a non-vulnerable version, while in case of vulnerable application components it is suggested to use safe functions, like: strcpy_s, sprintf_s, etc. The vulnerabilities are classified using CVE standard and CVSS scoring. Firmware Reviewer immediately identifies this binary as a High-risk Insecure executable, and viewing the details we see the code analysis has identified some insecure function calls inside of unsafe_functions  as potential vulnerabilities. 

As their names imply, safe_functions plugin handles  safe functions handle the user supplied data in a safe manner, while unsafe_function plugin while insecure functions handles user supplied data in an unsafe manner.

...

Although simplistic, these These potential vulnerabilities are indicative of the bugs found in the vast majority of embedded devices.

...

Firmware Reviewer detects components, libraries or executables with known vulnerabilities classified by CVE (Common Vulnerability and Exposure). CVE is a list of entries—each containing an identification number, a description, and at least one public reference—for publicly known cybersecurity vulnerabilities. Firmware Reviewer extracts every day such vulnerabilities regarding Firmware, to be used during Firmware Analysis.

...

Hardening Compliance

Other tools typically use the same data files to perform tests. Instead, Firmware Reviewer is not limited to a specific OS distribution, therefore it uses the knowledge of 10+ years from a wide range of sources. It may help you to automate or test against security best practices from sources like:

...

This is what happens during a typical Hardening Compliance scan:

  1. Initialization

  2. Perform basic checks, such as file ownership

  3. Determine operating system and tools

  4. Search for available software components

  5. Run enabled plugins

  6. Run security tests per category

  7. Report status of security scan

Other Tests

Test

Description

Malware Analysis

Dynamic analysis of ELF files:

  1. Starting and Termination: Time Stamps and Elapsed Time.

  2. Processes Information: clone, execve and exit etc.

  3. File I/O: open, read, write and delete etc.

  4. Network: TCP, UDP, HTTP and HTTPS etc.

  5. Typical Malicious Actions: self deletion, modification and lock.

  6. API Information: getpid, system, dup and other libc functions.

  7. syscall sequences.

Default Credentials

Finds default vendor’s and telco operators' credentials, using a monthly-updated list. The users rarely change those default credentials

Hardened Credentials

Finds hardened users and password stored in the firmware’s file system, as well as decrypting passwd and shadow files

Password Policy

Detects weak password policies, that increases the probability of an attacker having success using brute force and dictionary attacks against user accounts. An attacker who can determine user passwords can take over a user's account and potentially access sensitive data in the application. Weak passwords can be easily guessed and are an easy target for brute force attacks. This can lead to an authentication system failure and compromise system security

Password Expiration

There are different ways to detect the password expiration of a user. For example, one can easily check the user account password expiry information on Linux. The /etc/shadow files stores actual password in encrypted format for user’s account. You need to use the chage command. It can display password expiry information as well as changes the number of days between password changes and the date of the last password change. This information is used by the system to determine when a user must change his/her password

Password Recovery

It detects a wrong Password Recovery process inside the firmware

Account Lockout

It detects wrong Account Lockout policies

Role Separation

It checks the effectiveness of Role separation for different users

Role Hardening

It checks the effectiveness of Role hardeningfor different users

Check Authentication

Unauthenticated access: One of the most common vulnerabilities in firmware, unauthenticated access allows threat actors to gain access to an IoT device, which makes it easy to exploit device data and any controls provided by it. 

Weak authentication: Threat actors can easily gain access to devices when the firmware has a weak authentication mechanism. These mechanisms can range from single-factor and password-based authentication to systems based on weak cryptographic algorithms that can be broken into with brute-force attacks.

Upgrade Feature

It checks weaknesses during the firmware upgrade process

Exploitable Vulnerabilities

Tests for the presence of 60 known vulnerabilities using exploits from an embedded version of Metasploit. In addition, it also checks for a number of previously-unknown vulnerabilities discovered by our lab

Encrypted Upgrade Protocol

It checks a weak encryption algorithm during the firmware upgrade process

Upgrade Validation

It checks weaknesses during the firmware upgrade process, with focus on validity and integrity using a digital signature

Upgrade Rollback

It checks weaknesses during the firmware upgrade rollback process

Upgrade Security Alerting

It checks the presence of an effective security notification system during the firmware upgrade process

Sensitive Data

Dynamically checks the visibility of sensitive data

Sensitive Data Security

Dynamically checks the protection of sensitive data using ‘at rest’ cyphering or 'in transit'

Anonymized Personal Data

Dynamically checks the efficiency of anonimization of personal data (personal name, phone numbers, e-mails, etc.)

Data Collecting

Dynamically checks if Data Collecting is correctly notified to the user

Unencrypted Protocols

Dynamically checks the usage of Unencrypted Protocols

Traffic Anomalies

Dynamically checks anomalies in communications with unknown public IPs or URI, tracking their geo-location and the cipher level

Local Firewall

Dynamically checks the efficiency of the local firewall feature provided by the firmware

Security Event Logging

Dynamically checks the presence of separated Event log regarding security issues only

Security Event Alerting

Dynamically checks the presence of separated Event alerting system regarding security issues only

Binary Fuzzing Analysis

Dynamically executes a binary fuzzing analysis on executables/libraries exposing vulnerable functions

Network Fuzzing Analysis

Dynamically executes a network fuzzing analysis on exposed services

Directory Traversal and Discovery

Dynamically executes directory traversal tests and content discovery to Web pages, to identify debug or test functionalities

Wrong Input Validation

Dynamically executes web interface and API tests to find vulnerabilities like: weak authentication/authorization management, SQL Injection, XSS, XXE, CSRF, directory traversal, remote code execution

Wrong Error Handling

Dynamically executes a fuzzy analysis on executables parameters to observe the effectiveness of exception handling and stack trace

Bootloader Analysis

Dynamically checks if bootloader sequence modifications are permitted, as well as arbitrary kernel loading and boot from untrusted sources

Firmware Integrity Testing

Dynamically attempts to load a custom firmware or modified binaries to check if integrity testing is provided by the firmware upgrade process

Runtime Analysis

Dynamically attempts to switch in debugging mode for altering a process at runtime

Binary Exploitation

Dymanically exploit attempts in order to execute an arbitrary binary execution

Firmware Complexity

The Firmware of modern IoT devices is complex and made of multiple components. These components can take the form of either different binaries, packaged in an embedded QNX or Linux distribution, or different modules, compiled into a large, single-binary embedded OS (“blob firmware”).

...

The former type of firmware is, by far, the most ubiquitous: a large-scale experiment analyzed 19K firmware samples, and found that 86% of them were Linux-based. Similar to other Linux-based systems, Linux-based firmware includes a large number of interdependent binaries. The different binaries (or components) of the firmware on embedded devices share data to carry out the device’s tasks. Under our attacker model, this interaction is critical, as we focus on bugs that can be triggered by attacker input from “outside” of the device (i.e., over the network), but may affect binaries other than those directly facing the network.

...

IoT devices exchange data over the network. This data can come directly from the user (e.g., through a web interface), or indirectly from a trusted remote service (e.g., cloud backends). Many devices, especially routers, smart meters, and a host of low-power devices, such as smart light bulbs and locks, use the former paradigm. Moreover, recent attacks have shown that such devices can be exploited by clever remote attackers, even when their communication is restricted to a closed local network. In this work, we consider builind or own network-based attack tasks who communicate directly with the device, either through a local network or the Internet. However, our Embedded Framework can be easily extended to other scenarios.

...

We first identify the set of binaries that export network services (i.e., network-facing binaries) in a, even encrypted, Firmware sample. We leverage the observation that network-facing binaries are the components of the Firmware sample that receive and parse user-provided data.

...

Therefore, we identify those binaries within the Firmware sample that parse data read from a network socket. We utilize three features to identify functions in embedded systems that implement parsers:

...

DISCLAIMER: Firmware Reviewer never operates on physical devices. COPYRIGHT (C) 2014-2020 SECURITY REVIEWER SRL. ALL RIGHTS RESERVEDSecurity Reviewer declines all responsabilities derived by inappropriate use of Firmware Reviewer software.