Fig 6 - uploaded by Dominik Maier
Content may be subject to copyright.
Large scale testing of discovered Shannon baseband crashes over time, per phone model and firmware image. Each black dot is an image tested, with state interpolated between. "Crash" indicates that the image crashed when receiving the input. "No crash" means the image did not crash when receiving the input. "Timeouts" occur when the emulator could not retrieve and process the input in time. "Emulation Error" means FIRMWIRE was not able to boot the firmware. "Unknown" indicates other types of errors.
Context in source publication
Similar publications
Citations
... By performing a comparative analysis of baseband implementations and specifications for cellular devices, Kim et al. found hundreds of mismatches utilizing the proposed BASESPEC approach [23]. Hernandez and Muench et al. [24] proposed and implemented a scalable emulation platform FIRMWIRE for baseband security testing and found new pre-authentication memory corruptions. Yu et al. [25] inspected the security implementation of 5G commercial mobile devices using SecChecker. ...
Authentication and data protection (both integrity and confidentiality) between the network and cellular devices are two fundamental security features in LTE and IMS networks. The first is implemented via authentication and key agreement mechanisms and can be compromised by relaying authentication parameters. The second security feature builds on the first one and is activated through corresponding security setup procedures. This work intends to investigate whether these basic security procedures are securely implemented and deployed in commercial networks. We analyzed the de facto situation of these security features in three major operators in China and found several new and previously disclosed configuration and implementation flaws that do not conform to specifications. These vulnerabilities allow attackers to disable LTE and IMS data protection mechanisms. We further propose novel proof-of-concept attacks to exploit the identified vulnerabilities including
IMEI
and
Phone Number Catching
,
SMS
and
Call Impersonation
and
Interception
attacks. To show the urgency of addressing these security issues and thus secure the real-world telecom networks, we successfully demonstrated these attacks in practice using open-source SDR tools as they have serious implications. For instance, the interception attacks undermine the widely-used SMS verification code security mechanism. We also discuss countermeasures to resist the proposed attacks.
... Tools like DoLTEst [25] improve the detection of implementation flaws by concentrating on negative testing with a deterministic oracle derived from specification analysis. BaseSAFE [24] and FIRMWIRE [15] use fuzzing against LTE firmware to discover vulnerabilities, such as buffer overflows, which can then be verified through over-the-air testing. ...
Security flaws and vulnerabilities in cellular networks lead to severe security threats given the data-plane services that are involved, from calls to messaging and Internet access. While the 5G Standalone (SA) system is currently being deployed worldwide, practical security testing of User Equipment (UE) has only been conducted and reported publicly for 4G/LTE and earlier network generations. In this paper, we develop and present the first open-source based security testing framework for 5G SA User Equipment. To that end, we modify the functionality of open-source suites (Open5GS and srsRAN) and develop a broad set of test cases for the 5G NAS and RRC layers. We apply our testing framework in a proof-of-concept manner to 5G SA mobile phones and provide detailed insights from our experiments. While being a framework in development, the results of our experiments presented in this paper can assist other
researchers in the field and have the potential to improve 5G SA security.
... Modifying/patching such system calls will result in achieving more EFFs, and finally, expand the coverage. In a previous study, external elements that are not necessarily required for testing were disabled or simply access-patterned to implement appropriate responses [49]. In system call emulation, there are limitations due to unnecessary parts, but by leveraging techniques that can be improved together, potential candidates (e.g. ...
Fuzzing is a practical approach for finding bugs in various software. So far, a number of fuzzers have been introduced based on new ideas towards enhancing the efficiency in terms of increasing code coverage or execution speed. The majority of such work predicates under the assumption that they have sound executable binary or source code to transform the target program as a whole. However, in legacy systems, source codes are often unavailable and even worse, some binaries do not provide a sound executable environment (e.g., partially recovered firmware). In this paper, we provide FT-Framework:
fuzzability
testing framework based on
forced execution
for binaries such as firmware chunks recovered in abnormal way so that they are hard to execute/analyze from intended booting phase. The essence of our work is to automatically classify functions inside a binary which we can apply coverage-guided fuzzing via forced execution. We evaluate FT-Framework using PX4 and ArduPilot firmwares which is based on 32-bit ARM architecture and demonstrate the efficacy of this approach and limitations.
... Cao et al. [6], Johnson et al. [29], and Zhou [62], all leverage symbolic execution to learn satisfying values to bypass peripheral checks. Hernandez et al. [27] achieve full-system emulation of closed-source Shannon baseband firmware by adding missing architectural and peripheral support in QEMU, they later demonstrate that such an approach can be extended to other basebands [26]. In contrast to the aforementioned approaches, Milburn et al. [38] build a custom emulator and peripheral models to rehost an automotive instrument cluster; they use their emulator to aid in reverse-engineering the firmware's UDS commands. ...
... Mera et al. [37] highlight this difficulty in their evaluationto test their approach on both ARM and MIPS32-based devices, they need to build separate prototypes of their tool for two different forks of QEMU, as neither variant supports both architectures. Hernandez et al. [26] note the current impossibility of porting their baseband rehosting framework to work with Qualcomm basebands, due to lack of architecture support in the PANDA [14] QEMU fork. ...
In this paper we present MetaEmu, an architecture-agnostic emulator synthesizer geared towards rehosting and security analysis of automotive firmware. MetaEmu improves over existing rehosting environments in two ways: Firstly, it solves the hitherto open-problem of a lack of generic Virtual Execution Environments (VXEs) for rehosting by synthesizing processor simulators from Ghidra's language definitions. In doing so, MetaEmu can simulate any processor supported by a vast and growing library of open-source definitions. In MetaEmu, we use a specification-based approach to cover peripherals, execution models, and analyses, which allows our framework to be easily extended. Secondly, MetaEmu can rehost and analyze multiple targets, each of different architecture, simultaneously, and share analysis facts between each target's analysis environment, a technique we call inter-device analysis. We show that the flexibility afforded by our approach does not lead to a performance trade-off -- MetaEmu lifts rehosted firmware to an optimized intermediate representation, and provides performance comparable to existing emulation tools, such as Unicorn. Our evaluation spans five different architectures, bare-metal and RTOS-based firmware, and three kinds of automotive Electronic Control Unit (ECU) from four distinct vendors -- none of which can be rehosted or emulated by current tools, due to lack of processor support. Further, we show how MetaEmu enables a diverse set of analyses by implementing a fuzzer, a symbolic executor for solving peripheral access checks, a CAN ID reverse engineering tool, and an inter-device coverage tracker.
As Internet of Things (IoT) devices have rooted themselves in the daily life of billions of people, security threats targeting IoT devices are emerging rapidly. Thus, IoT vendors have employed security testing frameworks to examine IoT devices before releasing them. However, existing frameworks have difficulty providing automated testing, as they require a lot of manual effort to support new devices due to the lack of information about the input formats of the new devices. To address this challenge, we introduce FUZZDOCS, a document-based black-box IoT testing framework designed to automatically analyze publicly accessible API documents about target IoT devices and extract information, including valid inputs used to call each functionality of the target devices. Based on the extracted information, it generates valid-enough test inputs that are not easily rejected by target devices but can trigger vulnerabilities deep inside them. This document-based input generation allows FUZZDOCS to support new devices without manual work, as well as provide effective security testing. To prove its feasibility, we evaluated FUZZDOCS in a real-world IoT environment, and the results showed that FUZZDOCS extracted input formats with 93% accuracy from hundreds of pages of documents. Also, it outperformed the existing frameworks in testing coverage and found 35 potential vulnerabilities, including two unexpected system failures in five popular IoT devices.
Security attacks abuse software vulnerabilities of IoT devices; hence, detecting and eliminating these vulnerabilities immediately are crucial. Fuzzing is an efficient method to identify vulnerabilities automatically, and many publications have been released to date. However, fuzzing for embedded systems has not been studied extensively owing to various obstacles, such as multi-architecture support, crash detection difficulties, and limited resources. Thus, the paper introduces fuzzing techniques for embedded systems and the fuzzing differences for desktop and embedded systems. Further, we collect state-of-the-art technologies, discuss their advantages and disadvantages, and classify embedded system fuzzing tools. Finally, future directions for fuzzing research of embedded systems are predicted and discussed.
