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:
Initialization
Perform basic checks, such as file ownership
Determine operating system and tools
Search for available software components
Run enabled plugins
Run security tests per category
Report status of security scan
Other Tests
Test | Description |
Malware Analysis | Dynamic analysis of ELF files:
|
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.