Fuzzing Radio Resource Control Messages in 5G and LTE Systems

Home , Conformance testing, Continuous testing, Radio Resource Control

DEGREE PROJECT IN COMPUTER SCIENCE AND ENGINEERING, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2021

Fuzzing Radio Resource Control messages in 5G and LTE systems

To test telecommunication systems with ASN.1 grammar rules based adaptive fuzzer

SRINATH POTNURU

KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE

Fuzzing Radio Resource Control messages in 5G and LTE systems

To test telecommunication systems with ASN.1 grammar rules based adaptive fuzzer

SRINATH POTNURU

Master’s in Computer Science and Engineering with specialization in ICT Innovation, 120 credits Date: February 15, 2021 Host Supervisor: Prajwol Kumar Nakarmi KTH Supervisor: Ezzeldin Zaki Examiner: György Dán School of Electrical Engineering and Computer Science Host company: Ericsson AB Swedish title: Fuzzing Radio Resource Control-meddelanden i 5G- och LTE-system Fuzzing Radio Resource Control messages in 5G and LTE systems / Fuzzing Radio Resource Control-meddelanden i 5G- och LTE-system

Abstract

5G telecommunication systems must be ultra-reliable to meet the needs of the next evolution in communication. The systems deployed must be thoroughly tested and must conform to their standards. Software and network protocols are commonly tested with techniques like fuzzing, penetration testing, code review, conformance testing. With fuzzing, testers can send crafted inputs to monitor the System Under Test (SUT) for a response. 3GPP, the standardization body for the telecom system, produces new versions of specifications as part of continuously evolving features and enhancements. This leads to many versions of specifications for a network protocol like Radio Resource Control (RRC), and testers need to constantly update the testing tools and the testing environment. In this work, it is shown that by using the generic nature of RRC specifications, which are given in Abstract Syntax Notation One (ASN.1) description language, one can design a testing tool to adapt to all versions of 3GPP specifications. This thesis work introduces an ASN.1 based adaptive fuzzer that can be used for testing RRC and other network protocols based on ASN.1 description language. The fuzzer extracts knowledge about ongoing RRC messages using protocol description files of RRC, i.e., RRC ASN.1 schema from 3GPP, and uses the knowledge to fuzz RRC messages. The adaptive fuzzer identifies individual fields, sub-messages, and custom data types according to specifications when mutating the content of existing messages. Furthermore, the adaptive fuzzer has identified a previously unidentified vulnerability in Evolved Packet Core (EPC) of srsLTE and openLTE, two open-source LTE implementations, confirming the applicability to robustness testing of RRC and other network protocols. Keywords: RRC, 5G NR, robustness testing, fuzzing, ASN.1, network protocol testing, vulnerability detection, software security iv

Sammanfattning

5G-telekommunikationssystem måste vara extremt tillförlitliga för att möta be- hoven för den kommande utvecklingen inom kommunikation. Systemen som används måste testas noggrant och måste överensstämma med deras standar- der. Programvara och nätverksprotokoll testas ofta med tekniker som fuzzing, penetrationstest, kodgranskning, testning av överensstämmelse. Med fuzzing kan testare skicka utformade input för att övervaka System Under Test (SUT) för ett svar. 3GPP, standardiseringsorganet för telekomsystemet, producerar ofta nya versioner av specifikationer för att möta kraven och bristerna från tidigare utgåvor. Detta leder till många versioner av specifikationer för ett nät- verksprotokoll som Radio Resource Control (RRC) och testare behöver stän- digt uppdatera testverktygen och testmiljön. I detta arbete visar vi att genom att använda den generiska karaktären av RRC-specifikationer, som ges i be- skrivningsspråket Abstract Syntax Notation One (ASN.1), kan man designa ett testverktyg för att anpassa sig till alla versioner av 3GPP-specifikationer. Detta uppsatsarbete introducerar en ASN.1-baserad adaptiv fuzzer som kan användas för att testa RRC och andra nätverksprotokoll baserat på ASN.1- beskrivningsspråk. Fuzzer extraherar kunskap om pågående RRC meddelanden med användning av protokollbeskrivningsfiler för RRC, dvs RRC ASN.1 schema från 3GPP, och använder kunskapen för att fuzz RRC meddelanden. Den adaptiva fuzzer identifierar enskilda fält, delmeddelanden och anpassade datatyper enligt specifikationer när innehållet i befintliga meddelanden mu- teras. Dessutom har den adaptiva fuzzer identifierat en tidigare oidentifierad sårbarhet i Evolved Packet Core (EPC) för srsLTE och openLTE, två open- source LTE-implementeringar, vilket bekräftar tillämpligheten för robusthets- provning av RRC och andra nätverksprotokoll. Nyckelord: RRC, 5G NR, robusthetstest, fuzzing, ASN.1, nätverksproto- kolltestning, sårbarhetsdetektering, mjukvarusäkerhet Acknowledgments v

Acknowledgments

I am grateful for the opportunity provided by the host company Ericsson AB, my manager Hans Eriksson, and my supervisor Prajwol Kumar Nakarmi for trusting me to carry out this project. The guidance and support provided by Prajwol helped me identify many challenges and solutions along the way. His immense knowledge in security and radio access solutions made it easy for me to carry out the thesis work. I would also like to thank my KTH supervisor Ezzeldin Zaki and my examiner Dr. György Dán who helped me frame the research question and provided valuable inputs throughout my thesis. I thank all the open-source communi- ties and forums which gave enough support for many of my questions. Lastly, I would like to extend my gratitude towards my closest friends and family who stood by me throughout the period of this thesis.

Stockholm, February 2021 Srinath Potnuru

Contents

List of Figures ...... x List of Tables ...... xi List of Acronyms and Abbreviations ...... xvi

1 Introduction 1 1.1 Background ...... 1 1.2 Problem description ...... 3 1.3 Contribution ...... 4 1.4 Goals ...... 4 1.5 Ethical and Sustainability Aspects ...... 4 1.6 Method ...... 5 1.7 Stakeholders ...... 5 1.8 Delimitations ...... 6 1.9 Outline ...... 6

2 Background 7 2.1 Introduction to 5G ...... 7 2.1.1 5G Architecture ...... 9 2.2 5G New Radio ...... 10 2.3 Radio Resource Control (RRC) ...... 16 2.3.1 RRC State Machine ...... 17 2.3.2 Messages in RRC ...... 18 2.4 ASN.1 ...... 19 2.5 Fuzzing ...... 21 2.6 Related Work ...... 23 2.7 RRC and Fuzzing ...... 25 2.8 Similarities between 5G and LTE ...... 26 2.9 Summary ...... 28

vii viii CONTENTS

3 Design and Methodology 29 3.1 Design Requirements ...... 29 3.2 The adaptive fuzzer ...... 29 3.2.1 Fuzzer ...... 31 3.2.2 Observer ...... 32 3.3 Summary ...... 33

4 Implementation 34 4.1 Fuzzer ...... 34 4.1.1 Fuzzing Strategies ...... 36 4.2 Observer ...... 40 4.3 Summary ...... 43

5 Evaluation 44 5.1 Evaluation tools ...... 44 5.2 Integrating adaptive fuzzer with srsLTE ...... 45 5.3 Identifying testing strategies ...... 46 5.4 Collecting Results ...... 48 5.5 Filtering out false positives ...... 51 5.6 Summary ...... 52

6 Results and Analysis 53 6.1 Results ...... 53 6.2 Crash in EPC ...... 56 6.3 Impact on performance of srsLTE due to fuzzing ...... 57 6.4 Summary ...... 58

7 Conclusions and Future Work 59 7.1 Conclusions ...... 59 7.2 Future Work ...... 60

References 62 List of Figures

1.1 Minimalistic view of 5G system...... 2

2.1 Use case categorization triangle in 5G by ITU-T...... 8 2.2 Overview of 5G communication system...... 9 2.3 Service Based Architecture with diﬀerent network functions in 5G system...... 10 2.4 Networking layers involved in 5G control plane messages. . . . 11 2.5 Networking layers involved in 5G user plane messages. . . . . 12 2.6 Mapping between logical, transport and physical channels in the downlink [19]...... 13 2.7 Mapping between logical, transport and physical channels in the uplink [19]...... 14 2.8 RRC State Machine in 5G NR [25]...... 17 2.9 ASN.1 language structure for RRCConnectionRequest in EU- TRA TS 36.331 v15.4...... 19 2.10 Example tree fashion ASN.1 structure of an RRC Message. . . 20 2.11 General fuzzing framework...... 22 2.12 Networking layers involved in 5G and LTE control plane messages...... 26 2.13 srsLTE nodes no RF front-end...... 28

3.1 Adaptive fuzzing framework for an ASN.1 based network protocol...... 30 3.2 RRC State Machine in EUTRA [49]...... 33

4.1 Components of the mutation based adaptive fuzzer...... 36 4.2 ASN.1 description of DedicatedInfoNAS in 3GPP TS [49]. . . 36 4.3 Wireshark packet capture of UECapabilityInformation generated by srsUE (UE implementation in srsLTE)...... 39

ix x LIST OF FIGURES

4.4 Wireshark packet capture of UECapabilityInformation with fuzz_append_string set to true...... 40

5.1 Integrating the adaptive fuzzer with srsLTE...... 46 5.2 RRC messages sent between UE and network during initial activation in 5G and LTE system...... 47 5.3 Automated toolchain for continuous testing (dashed lines indicate fuzzing during initial AS activation)...... 50 5.4 Flowchart for replaying RRC messages to verify a TRUE crash (dashed lines indicate fuzzing in initial AS activation). . . . . 51

6.1 Boxplot distribution of measured latency for 44,383 fuzzed uplink RRC messages...... 57 List of Tables

2.1 Names and Abbreviations of Physical Channels in 5G NR [18] 13 2.2 Names and Abbreviations of Transport Channels in 5G NR [18] 15 2.3 Names and Abbreviations of Logical Channels in 5G NR [18] 15

5.1 Diﬀerent fuzzing strategies identiﬁed for RRC messages in srsLTE ...... 49

6.1 Number of RRC messages from srsLTE fuzzed by the adaptive fuzzer and the range of seed values used ...... 56

xi xii List of Acronyms and Abbreviations

List of Acronyms and Abbreviations

3G Third Generation Telecommunication System

3GPP 3rd Generation Partnership Project

5G Fifth Generation Telecommunication System

5G NR Fifth Generation New Radio

5GC 5G Core

AFL American Fuzzy Lop

AM Acknowledged Mode

AMF Access and Mobility Management Function

ARQ Automated Repeat Request

AS Access Stratum

ASN.1 Abstract Syntax Notation One

BCCH Broadcast Control Channel

BCH Broadcast Channel

C-RNTI Cell Radio-Network Temporary Identiﬁer

CCCH Common Control Channel

DCCH Dedicated Control Channel

DCI Downlink Control Information

DL Down Link

DL-SCH Downlink Shared Channel

DTCH Dedicated Traﬃc Channel

E-UTRA Evolved UMTS Terrestrial Radio Access eMBB enhanced Mobile Broadband List of Acronyms and Abbreviations xiii

eNB Evolved Node Base station

EPC Evolved Packet Core

FTP File Transfer Protocol gNB Next Generation Node Base station

GTP GPRS Tunneling Protocol

HSPA High Speed Packet Access

HSS Home Subscriber Server

HTML Hypertext Markup Language

IETF Internet Engineering Task Force

IIoT Industrial Internet of Things

IP Internet Protocol

ITU International Telecommunication Unit

ITU-T ITU Telecommunication Standardization Sector

LTE Long-Term Evolution

MAC Medium Access Control layer

MME Mobile Management Entity mMTC massive Machine-Type Communication

NAS Non Access Stratum

NF Network Function ng-eNB Next Generation - Evolved Node Base station

NG-RAN Next-Generation Radio Access Network

NSA Non-StandAlone option

OFDM Orthogonal Frequency Division Multiple Access xiv List of Acronyms and Abbreviations

OSI Open Systems Interconnection

P-GW PDN Gateway

PBCH Physical Broadcast Channel

PCCH Paging Control Channel

PCH Paging Channel

PDCCH Physical Downlink Control Channel

PDCP Packet Data Convergence Protocol layer

PDN Packet Data Network

PDSCH Physical Downlink Shared Channel

PDU Protocol Data Unit

PHY Physical layer

PLMN Public Land Mobile Network

PRACH Physical Random-Access Channel

PTF P1 Telecom Fuzzer

PUCCH Physical Uplink Control Channel

PUSCH Physical Uplink Shared Channel

QoS Quality of Service

RACH Random Access Channel

RAM Random Access Memory

RAN Radio Access Network

RAT Radio Access Technology

RF Radio Frequency

RLC Radio Link Control layer List of Acronyms and Abbreviations xv

RRC Radio Resource Control layer

S-GW Serving Gateway

SBA Service Based Architecture

SBI Service Based Interface

SCADA Supervisory Control And Data Acquisition

SDAP Service Data Adaption Protocol layer

SDR Software Deﬁned Radio

SDU Service Data Unit

SMF Session Management Function

SMS Short Message Service

SQL Structured Query Language srs Software Radio Systems

SSH Secure Shell

SSL Secure Sockets Layer

SUT System Under Test

TS Technical Speciﬁcations

TTCN-3 Testing and Test Control Version 3

UCI Uplink Control Information

UDP User Datagram Protocol

UE User Equipment

UL Up Link

UL-SCH Uplink Shared Channel

UMTS Universal Mobile Telecommunications System xvi List of Acronyms and Abbreviations

UPER Unaligned Packed Encoding Rules

UPF User Plane Function

URLLC Ultra Reliable and Low Latency Communication

USIM Universal Subscriber Identity Module

USRP Universal Software Radio Peripheral vCPU Virtual Central Processing Unit

XML eXtensible Markup Language Chapter 1

Introduction

This thesis work discusses the use of an adaptive fuzzer for testing network protocols. This chapter contains a background study to understand the thesis, problem statement and goals identiﬁed for the work, purpose fulﬁlled with the work, method for implementation, delimitations concerning the work. Finally, outline for the rest of thesis work is presented.

1.1 Background

Telecommunication networks have become critical infrastructure in present world [1, 2]. They provide a multitude of services like telephony and data to businesses and public. There is a common requirement for 99.999% (5 9’s) uptime availability of telecommunication networks [3, 4]. That is less than ﬁve and half minutes of downtime in a year. To ensure such high availability, the networks must be rigorously tested for robustness against failures. 5G is the next generation of telecommunication system currently in development. A minimalistic illustration of 5G system is shown in Figure 1.1. UE is the User equipment or mobile devices, NG-RAN is next generation radio access network in 5G, and 5G-C represent the core network in 5G system. Uu is the radio interface between UE & NG-RAN, and N2/N3 interfaces for control or user plane traﬃc. Devices in a network exchange messages according to standardized rules called protocols. The rules specify grammar, message, and size constraints for carrying data. Similarly, in 5G and telecommunication networks, there are multiple network protocols used between UE and NG-RAN, within NG-RAN, between NG-RAN, 5G-C and between UE and 5G-C. Section 2.1 provides a

1 2 CHAPTER 1. INTRODUCTION

UE Uu NG-RAN N2/N3 5G-C

Figure 1.1: Minimalistic view of 5G system. brief overview of network protocols in 5G system. 5G New Radio (5G NR) is the primary radio access technology in 5G. There is support for Evolved Universal Mobile Telecommunication System (UMTS) Terrestrial Radio Ac- cess (EUTRA), the radio access technology from 4th generation (4G)/Long Term Evolution (LTE) networks. EUTRA coexists with 5G NR in the foresee- able future. Radio Resource Control (RRC) network protocol in 5G NR and EUTRA manage the radio resources in radio access networks towards UE. Standardization bodies like 3rd Generation Partnership Project (3GPP) and Internet Engineering Task Force (IETF) provide standards or technical specifications for network protocols in revisions or releases. 3GPP provided specifications for 5G systems beginning with Release 15. Currently Release 16 consists of latest specifications with more releases under development for future updates. The telecommunication standards (specifications) by 3GPP specify grammar rules for all telecommunication network protocols (like Radio Resource Control (RRC), Non-Access Stratum (NAS), S1AP, XnAP, etc.) for message encoding and decoding. Among others, for RRC, the grammar rules are specified in the description language called Abstract Syntax Notation One (ASN.1). Testing hardware, software and network protocols are part of their development cycles. Through testing, vulnerabilities in the system can be identified before the systems get deployed. If left unidentified, hackers or attackers could take advantage of the vulnerability. Hence, identifying vulnerabilities becomes important in the development process. One of the methods that allows detection of hidden vulnerabilities is fuzzing. It is used for testing hardware, software or network protocols. Fuzzing/robustness-testing/negative-testing of software, network protocols is a common practice to identify vulnerabilities in a software, or network protocol. It is the process of sending malformed messages to a System Under CHAPTER 1. INTRODUCTION 3

Test (SUT) and monitoring SUT’s behavior under the malformed message. Fuzzing helps uncover faults not identiﬁed by conformance testing (where messages sent are set according to known scenarios). Fuzzing involves test automation process that sends a large number of malformed messages in a short span and retracing the steps that led to unexpected behavior (if any) in the SUT. Intelligent/smart fuzzers incorporate the knowledge from SUT (either software or network protocol) to create the message that looks similar to expected messages at SUT. This way, intelligent fuzzers reduce the testing space and identify faults that are meaningful. Network protocols use grammar-based rules to encode or decode messages into programming environments for message handling. Intelligent fuzzers for network protocols would require the grammar to be embedded in message creation. Multiple vulnerabilities have been identiﬁed with fuzzing in network protocols such as OpenVPN, OpenSSL, FTP [5, 6, 7, 8].

1.2 Problem description

Even with widespread use of fuzzing for network protocols and software, there is a research gap for using fuzzing on telecommunication systems. Especially previous fuzzers that are designed for core network protocols in telecommunication networks, are not easily adaptable for testing radio interfaces and RRC protocols. In addition, with the number of revisions to each protocol (175 versions for EUTRA’s and 20 versions for 5G NR’s RRC protocol definition by 3GPP), embedding the knowledge of such network protocol into the fuzzer for each revision in not feasible leading to slower development and testing processes. By using the grammar rules provided by 3GPP for RRC (defined in ASN.1), it could be possible to design an adaptive fuzzer that does not conform to a specific version of protocol specifications and can be made adaptable to any version of protocol specification it takes as input. Previous attempts to include generic language rules for telecom systems use Testing and Test Control No- tation (TTCN-3) rules (by T-Fuzz for NAS [9] and T3FAH for SIP [10]) and do not consider the ASN.1 definitions for RRC. 4 CHAPTER 1. INTRODUCTION

1.3 Contribution

Contributions of this thesis include the design and implementation of an adaptive ASN.1 based RRC fuzzer. Bugs identified by the fuzzer in an open-source project were reported to product owners and developers for responsible disclosure and to overcome the vulnerabilities. This thesis provides a working proto- type for adaptive ASN.1 based fuzzer and future works that can be extended to test network protocols using ASN.1 as their description language. According to the author’s knowledge, this work is the first to integrate any formal ASN.1 specification to test the implementation of RRC protocol.

1.4 Goals

This thesis addresses the stated problem statement by fulﬁlling the following primary requirements and goals:

1. Create an adaptive fuzzing framework for testing RRC and other network protocols of 5G NR, EUTRA based on ASN.1 speciﬁcation

2. Verify the applicability of the adaptive framework by testing an open- source implementation of RRC protocol by sending fuzzed messages to an open-source evolved node base station (eNB), Evolved Packet Core (EPC)

3. Identify errors in implementations of the network protocols

1.5 Ethical and Sustainability Aspects

The work performed in this thesis can be considered similar to ethical hack- ing where faults or vulnerabilities are identiﬁed in a controlled manner. This leads to preemptive action for resolving bugs and makes the telecommunication networks reliable. At the same time, the evaluation work was conducted entirely in virtual machines without any use of radio frequency hardware. This led to greatly reduced power consumption as the thesis work uses simulated components for a telecommunication system to evaluate the tool developed in this thesis. Vulnerabilities identiﬁed during the experimentation process in this thesis are disclosed in a controlled manner to developers of telecommunication systems (to bring the existing vulnerability to their notice) and, through CHAPTER 1. INTRODUCTION 5

Ericsson, to a national Computer Emergency Response Team (CERT) for responsible wider disclosure. It can be noted that such a tool in the wrong hands can lead to compromising security of a telecom system and further the communication infrastructure that millions of people rely on.

1.6 Method

The work in this thesis was carried using a qualitative and quantitative research methodology. The research is qualitative in the sense that it attempts to answer the question of feasibility in designing an adaptive fuzzer. Also, it is quantitative where it identifies several bugs by sending thousands of fuzzed messages. The extensive study of existing literature and fuzzers helped in identifying the problem of lack of fuzzers that can adapt to any version of RRC specifications in EUTRA and 5G NR. Existing fuzzers like SPFuzz [6], AutoFuzz [7] previously showed that using protocol specifications could lead to faster testing cycles. Coupled with language-based fuzzing, the author believed that protocol specifications could allow fuzzing of RRC messages. And through the fuzzing, test different components in the telecom network (UE, base station, and core network). Even though RRC messages are processed by both UE and base stations, this thesis considered fuzzing only messages from UE to base station due to the limitation of resources and the necessity of a safer network (which serve multiple UEs, while compromising one UE might not affect other UEs).

1.7 Stakeholders

There are multiple categories of people and organizations who might benefit from the results of this thesis work. Companies working in telecommunication environment like telecom operators would benefit with reliable and robust equipment in their operations, services. The telecom equipment vendors would benefit by being able to provide the robust equipment to operators. At the same time, smartphone and mobile manufacturers could use the princi- ples from the adaptive fuzzer and this thesis work to test their products before selling to their consumers. Testers and developers working with telecommunication and networking systems can integrate this adaptive fuzzer into their daily testing activities for early identification of bugs, vulnerabilities. Overall, the society will benefit from robust communication services to handle their voice or data enabled by this adaptive fuzzer. 6 CHAPTER 1. INTRODUCTION

1.8 Delimitations

This thesis work was performed with following limitations in consideration:

• In general, there are generation-based and mutation-based fuzzing and we use only mutation-based fuzzing for RRC protocol

• If available, an open-source ASN.1 parser would be used to translate technical speciﬁcations of network protocols into programming environment

• The proof of concept fuzzer will be tested with any available open- source implementation of telecommunication system by diverting uplink RRC messages through the adaptive fuzzer. It would not test any other network protocol

• If possible, the tests would be conducted without using any Radio Front- end (RF) devices by running the network nodes in the same machine

• As this thesis proposed a proof of concept, the number of messages fuzzed could be limited based on resource availability and feasibility to obtain results in limited duration

• When the fuzzer identiﬁes a bug or vulnerability, investigating source of the bug is out of scope in this thesis

1.9 Outline

This thesis is organized as follows: Chapter 2 provides the necessary background study to perform the thesis work. It helps in understanding the problem and contributions through this thesis work. Chapter 3 introduces the methodology and design concepts used to realize the fuzzer for RRC protocol. Chap- ter 4 discusses the implementation steps involved for a proof of concept. Chap- ter 5 presents the measurement techniques employed and automation steps involved for tracking the bugs and verifying the bugs as vulnerabilities. Chap- ter 6 presents the number of unique messages sent and bugs identiﬁed with the adaptive fuzzer. Finally, chapter 7 provides the conclusions from this work and future extensions, usability of the adaptive fuzzer for other network protocols. Chapter 2

Background

This chapter introduces the concepts used in the thesis including 5G, 5G New Radio, Radio Resource Control (RRC), Fuzzing, ASN.1 language. It identiﬁes related works in fuzzing of telecommunication and networking systems with gaps and motivation for this thesis.

2.1 Introduction to 5G

Mobile communications have evolved in four generations over last 40 years. The number of subscriptions for mobile communications has increased to 8.3 billion and is expected to increase to 8.9 billion by 2025 [11]. New use cases are being identified to use mobile communication, like wireless Industrial In- ternet of Things (IIoT) to support the latency sensitive industrial sensors and processes. Similarly, the amount of data being created, captured, copied and consumed worldwide is projected to increase to 149 Zettabytes (1 Zettabyte = 1012 Gigabytes) per year by 2024 with expected requirement for high bandwidth applications like games, video streaming [12]. Current telecommunications cannot meet the needs of future applications. A new telecommunication system, called 5G, is being prepared with an emphasis on accommodating use cases of future (both identified and unidentified). Figure 2.1 shows the various use cases identified by International Telecom- munication Union Telecommunication Standardization Sector (ITU-T) for 5G networks and beyond. Current LTE networks and the evolution in telecommunications considered the increasing data rates for mobile applications. The trend has continued into 5G. Apart from increasing data rate, 5G networks also consider more use cases by the end users. Particularly, three classes of commu-

7 8 CHAPTER 2. BACKGROUND

Enhanced Mobile Broadband (eMBB)

Gigabytes in a second

3D Video, UHD screens

Smart Home Building Work and play in the cloud

Voice Industry Automation

Smart City Self Driving Cars

Massive Machine Type Ultra-reliable and Low Latency Communication (MMTC) Communications (URLLC)

Figure 2.1: Use case categorization triangle in 5G by ITU-T. nication are considered. Enhanced mobile broadband (eMBB) for high data throughput; massive machine-type communication (mMTC) for communication across large network of devices with low cost and low energy consumption; and ultra-reliable low latency communication (URLLC) for automatic control, factory automation, etc. Some use cases could fall into multiple categories with varied network requirements. For example, working and playing in cloud would require low latency streaming applications with high bandwidth requirements. Hence, the 5G network would cater to both needs of working and playing in cloud. Currently, 5G mobile communication networks are in development and will be deployed through 2020s. The standardization organization, called 3GPP, proposes technical specifications of 5G and other generations of mobile networks for use by telecommunication operators and vendors. The specifications are organized into releases to be implemented by developers [13, 14]. The release 14 by 3GPP paved the way forward for 5G inclusion. Release 15 and 16 contain the specifications for 5G networks and are scheduled to be released through 2020 [15]. CHAPTER 2. BACKGROUND 9

2.1.1 5G Architecture The 5G communication system created an access independent core network to accommodate existing access technologies including LTE, 3G, non-3GPP technologies as well. Similar to LTE, the 5G networks consist of a core network and access network. The core network handles signaling and control aspects of the communication while the access network provides radio interface towards UE (as shown in Figure 2.2). The core network is called 5G Core Network (5G CN or 5G C) and the access network is called Next Generation Radio Access Network (NG-RAN). The Data Network (DN) corresponds to internet and its services.

NG-RAN 5G CN DN Control Plane User Plane N2 AMF NFs

UE Uu gNB N3 UPF N6 Internet

Figure 2.2: Overview of 5G communication system.

The 5G network is split into control plane and user plane where control plane consists of logical network to handle control and signaling functionalities while user plane consists of the logical network to handle user data. Figure 2.2 shows the nodes involved in control plane with dashed lines and user plane with solid line. For 5GC, a new approach is proposed with service based interfaces between diﬀerent functionalities of a communication system. These functionalities are handled by Network Functions (NF) which interact in a service provider-consumer relationship. The NFs consume services exposed by service providers and thus become service consumers. It is called Service Based Architecture (SBA) with interaction between NFs over a Service Based Inter- face (SBI). Control plane consists of AMF, SMF, and other network functions as identiﬁed by NFs with "bubbles" in Figure 2.3. 10 CHAPTER 2. BACKGROUND

User Plane Control Plane Service Based Interface

NSSF NEF PCF UDM AF

AUSF AMF SMF

N1 N2 N4

Uu N3 N6 UE RAN UPF DN

Figure 2.3: Service Based Architecture with diﬀerent network functions in 5G system.

2.2 5G New Radio

A new radio standard called 5G New Radio (or simply 5G NR or NR) is proposed for 5G systems. The new standard should support requirements iden- tiﬁed for future use like higher data speed, lower latency, mobility, and reliability. 5G NR is the access mechanism to use over licensed electromagnetic spectrum for transmission of data between RAN and UE. The NG-RAN in 5G system can consist of multiple Next generation Node Base stations (gNBs) or a single gNB. NG-RAN will provide support to legacy radio access technologies from LTE, 3G, etc. The RAN provides an interface to UE to interact with core and data networks. 5G NR consists of a stack of network protocols for handling control plane and another stack for user plane messages, as shown in Figure 2.4, Figure 2.5 respectively. The interface between UE and NG-RAN is called Uu (as shown in Figure 2.2) which carries both control and user plane traﬃc. This thesis is concerned with the messages passed over Uu interface in control plane.

The 5G NR stack consists of PHY, MAC, RLC, PDCP, SDAP, RRC layers [16]. The layers in 5G stack provide services to upper layers or use the services of a lower layer similar to the Open Systems Interconnection (OSI) model stack in general networking [17]. This layering enables devices to communicate with another device in the network on the same layer. A layer can receive its payload or message, called Service Data Unit (SDU), from the upper CHAPTER 2. BACKGROUND 11

UE gNB AMF

NAS NAS

RRC RRC

PDCP PDCP

RLC RLC

MAC MAC

PHY PHY

Figure 2.4: Networking layers involved in 5G control plane messages. layer. Each SDU is converted into a Protocol Data Unit (PDU) with encapsu- lation of the current layer related header and data. Each layer on either side interacts with through their PDUs. Messages transmitted from NG-RAN or core network to UE are called downlink messages and messages from UE to NG-RAN or core network are called uplink messages. RRC is involved in the control plane messaging between UE and NG-RAN. Similarly, SDAP is involved in the user plane traﬃc carrying messages from IP layers (for user data in general networking, calls). MAC, RLC, PDCP and SDAP are considered as sub-layers of Layer 2 (L2) in 5G NR. PHY is considered as Layer 1 (L1) in 5G NR. The functionality for each layer is as follows:

• Physical (PHY): Oﬀers data services to upper layers through mapping radio physical resources (time and frequency) to physical channels, refer to Table 2.1. Upper layers use the physical resources through transport channels which are mapped as shown in Figure 2.6, Figure 2.7 to the physical channels. The physical resources are divided in time and frequency domain that allow modulation, demodulation of digital signals into radio waves [18, 19, 16, 20]

• Medium Access Control (MAC): MAC layer performs the multiple ac- 12 CHAPTER 2. BACKGROUND

UE gNB DN

IP IP

SDAP SDAP

PDCP PDCP

RLC RLC

MAC MAC

PHY PHY

Figure 2.5: Networking layers involved in 5G user plane messages.

cess possibility through multiplexing and demultiplexing of MAC SDUs. Upper layers use services of MAC layer through logical channels. MAC layer is responsible for scheduling of transmission resources for both downlink & uplink and reports the scheduling information to upper layers. Also responsible for prioritization between diﬀerent logical channels [21, 19, 16]

• Radio Link Control (RLC): Oﬀers its services to upper layers in one of three modes: Transparent Mode (TM), Unacknowledged Mode (UM), Acknowledged Mode (AM). Its services include error correction through Automatic Repeat Request(ARQ), (re)segmentation of RLC SDUs by framing, duplicate removal, RLC retransmission. Each logical channel in MAC layer is associated with an RLC mode [19, 16, 22]

• Packet Data Convergence Protocol (PDCP): PDCP layer is responsible for IP header compression, decompression in user plane, integrity protection and ciphering for security, retransmission, and in-sequence delivery of SDUs [19, 16, 23]. RRC layer relies on PDCP for securely delivering the RRC messages with no loss and in order

• Service Data Adaption Protocol (SDAP): Maps Quality of Service (QoS) ﬂows from core network to data radio bearers. The QoS handling is es- CHAPTER 2. BACKGROUND 13

sential for the Network Slicing, a major feature in 5G. SDAP is present only in User Plane to handle user IP packets [19, 16, 24]

• Radio Resource Control (RRC): Responsible for handling RAN related control plane messages. It is described in more detail in section 2.3

The services between layers in 5G NR control, user plane is handled through channels. Lower layers provide speciﬁc services with a channel to the upper layer. The mapping of channels between layers for downlink and uplink in 5G NR are shown in Figure 2.6, Figure 2.7.

DCCH Logical PCCH BCCH CCCH DTCH Channels

Transport Channels PCH BCH DL-SCH

DCI

Physical Channels PBCH PDSCH PDCCH

Figure 2.6: Mapping between logical, transport and physical channels in the downlink [19].

Channel Name PDSCH Physical Downlink Shared Channel PBCH Physical Broadcast Channel LogicalPDCCH PhysicalCCCH DownlinkDTCH ControlDCCH Channel Channels PUSCH Physical Uplink Shared Channel PUCCH Physical Uplink Control Channel PRACH Physical Random-Access Channel Transport Table 2.1:Channels Names and Abbreviations ofUL Physical-SCH ChannelsRACH in 5G NR [18]

UCI Each physical channel corresponds to a set of time, frequency resources and are listedPhysical in Table 2.1. The PHY layer maps information from transport Channels PUSCH PUCCH PRACH DCCH Logical PCCH BCCH CCCH DTCH Channels

Transport Channels PCH BCH DL-SCH

DCI

Physical Channels PBCH PDSCH PDCCH

14 CHAPTER 2. BACKGROUND

Logical CCCH DTCH DCCH Channels

Transport Channels UL-SCH RACH

UCI

Physical Channels PUSCH PUCCH PRACH

Figure 2.7: Mapping between logical, transport and physical channels in the uplink [19]. channels to physical channels. The functions for each physical channel are as follows [19]:

• Physical Downlink Shared Channel (PDSCH): For unicast data, paging information, etc.

• Physical Broadcast Channel (PBCH): For carrying parts of System In- formation (SI)

• Physical Downlink Control Channel (PDCCH): For Downlink Control Information (DCI), scheduling decisions

• Physical Uplink Shared Channel (PUSCH): Similar to PDSCH for uplink

• Physical Uplink Control Channel (PUCCH): For sending Hybrid-ARQ (HARQ) acknowledgments, channel-state reports and requesting resources for uplink

• Physical Random-Access Channel (PRACH): For random access

PDCCH and PUCCH, unlike other physical channels, do not carry information from a transport layer. They carry downlink control information CHAPTER 2. BACKGROUND 15

Channel Name BCH Broadcast Channel DL-SCH Downlink Shared Channel PCH Paging Channel RACH Random Access Channel UL-SCH Uplink Shared Channel

Table 2.2: Names and Abbreviations of Transport Channels in 5G NR [18] Channel Name BCCH Broadcast Control Channel PCCH Paging Control Channel CCCH Common Control Channel DCCH Dedicated Control Channel DTCH Dedicated Traﬃc Channel

Table 2.3: Names and Abbreviations of Logical Channels in 5G NR [18]

(DCI) and uplink control information (UCI) respectively. DCI contain resource scheduling decisions from gNB, and UCI are used for requesting resources from UE, sending HARQ acknowledgments. As mentioned before, MAC layer uses the services of PHY layer through transport channels which are listed in Table 2.2. The functions for transport channels are as follows [19]: • Broadcast Channel (BCH): Used for transmission of BCCH system information, speciﬁcally Master Information Block (MIB)

• Paging Channel (PCH): Used for transmission of paging information from PCCH logical channel. It supports Discontinuous Reception (DRX) for saving battery on the device

• Downlink Shared Channel (DL-SCH): It is the main transport channel used for downlink data. It supports channel-dependent scheduling in time and frequency domains

• Uplink Shared Channel (UL-SCH): It is similar to DL-SCH for uplink

• Random Access Channel (RACH): Does not carry MAC PDUs

The logical channels oﬀered by MAC layer are shown in Table 2.3 and the functions for each channel are as follows [19]: 16 CHAPTER 2. BACKGROUND

• Broadcast Control Channel (BCCH): Similar to BCH, provides transmission of system information from network

• Paging Control Channel (PCCH): Used for paging of a device from network

• Common Control Channel (CCCH): Control information related to random access. Also, for sending control information from device to network

• Dedicated Control Channel (DCCH): Used for individual conﬁguration of devices with various parameters. Also, for sending control information from device to network

• Dedicated Traﬃc Channel (DTCH): Used for user data in unicast downlink or uplink

The logical channels CCCH, DCCH and DTCH are present in both downlink and uplink. They are identiﬁed by DL-CCCH, DL-DCCH, DL-DTCH for downlink and UL-CCCH, UL-DCCH and UL-DTCH for uplink messages.

2.3 Radio Resource Control (RRC)

This thesis is concerned with RRC protocol layer and the messages involved at RRC. RRC operates in the control plane messages between UE and gNB in NG-RAN. It carries information related to control plane procedures for RAN. RRC layer also provides services to NAS messages that are sent between UE and Access and Mobility Management Function (AMF) in core network. The messages in RRC rely on PDCP to provide a channel with ciphering and integrity protection when necessary. It is responsible for broadcast of system information or acquisition of it to communicate within a cell, to transmit paging messages in RRC_IDLE state, connection management, mobility management, etc. RRC layer is responsible for bulk of messages in control plane procedures and it is important for any implementation of RRC layer to be robust to withstand malicious attacks and provide reliable service to upper layers. The main functions of RRC and services to upper layers of RRC include [25, 19]:

• Broadcast of system information: Information necessary for device to communicate in a cell like cell (re-)selection parameters, neighboring CHAPTER 2. BACKGROUND 17

Establish/ Release RRC_IDLE RRC_CONNECTED

Resume/ Release Release with suspend

RRC_INACTIVE

Figure 2.8: RRC State Machine in 5G NR [25].

cell information in RRC_IDLE and RRC_INACTIVE states and common channel conﬁguration information in RRC_CONNECTED state

• RRC connection control: Performs functions related to Paging; RRC connection - Establishment, modiﬁcation, suspension, resumption, release; Initial Access Stratum (AS) security activation; RRC connection mobility

• Inter-RAT mobility: AS security activation and transfer of RRC context information

• Measurement configuration and reporting: Establishment, modification and release of measurement configuration, Setup and release of measurement gaps, Measurement reporting, etc.

• Transfer of dedicated NAS information

• Transfer of UE radio access capability information

• Information about UE in speciﬁc RRC states to upper layers

2.3.1 RRC State Machine RRC layer provides speciﬁc set of services based on a state machine as shown in Figure 2.8. A device can exist in either of three RRC states (RRC_IDLE, 18 CHAPTER 2. BACKGROUND

RRC_INACTIVE, RRC_CONNECTED). Each state is based on the traffic activity involved [25, 19]. The RRC_IDLE and RRC_CONNECTED states are also present in LTE’s radio access technology, EUTRA. The additional state RRC_INACTIVE is introduced for 5G NR. The functionality for each state is: • RRC_IDLE: It is the state where network does not contain RRC connection information of a UE. Hence the device cannot send or receive data. The device wakes up periodically to receive paging messages from the network to change to RRC_CONNECTED state. Mobility between cells and networks can take place through cell re-selection procedure • RRC_INACTIVE: Cannot send or receive data. RRC context is main- tained in both UE and gNB. UE can sleep similar to RRC_IDLE mode to save battery power. Less transition time to RRC_CONNECTED mode for data transfer as context already established at core network. Mobility through cell re-selection procedure • RRC_CONNECTED: RRC context established between UE and gNB for data transfer to or from network. Network identifies device through Cell Radio-Network Temporary Identifier (C-RNTI) used for signaling purposes. Mobility managed by RAN for handover when required The new state RRC_INACTIVE helps reduce the amount of signaling involved in state transition before sending user data. With increasing smartphone usage for internet and frequent small data requests, RRC_INACTIVE acts as an intermediary state for direct transition when RRC context is already established. The device can sleep similar to RRC_IDLE in RRC_INACTIVE state.

2.3.2 Messages in RRC RRC layer uses the services of lower layers for reliable and secure delivery of RRC messages. The messages are sent through the logical channels UL- CCCH, UL-DCCH in uplink and DL-CCCH, DL-DCCH, BCCH, PCCH in downlink. Messages in CCCH, PCCH and BCCH channels are sent in plain text for initial AS activation and random-access procedure through the Trans- parent Mode (TM) in RLC. Hence, these messages do not use services of PDCP layer for ciphering and integrity protection. RLC still provides the error detected retransmission and no-duplicate delivery of RRC payloads. In uplink, RRC messages are sent only through UL-CCCH and UL-DCCH. 3GPP speciﬁes the RRC messages to be transferred by UE and gNB for various procedures involved in the lifetime of UE. The messages are encoded CHAPTER 2. BACKGROUND 19

RRCConnectionRequest ::= SEQUENCE { criticalExtensions CHOICE { rrcConnectionRequest-r8 RRCConnectionRequest-r8-IEs, rrcConnectionRequest-r15 RRCConnectionRequest-5GC-r15-IEs } }

RRCConnectionRequest-r8-IEs ::= SEQUENCE { ue-Identity InitialUE-Identity, establishmentCause EstablishmentCause, spare BIT STRING (SIZE (1)) }

InitialUE-Identity ::= CHOICE { s-TMSI S-TMSI, randomValue BIT STRING (SIZE (40)) }

Figure 2.9: ASN.1 language structure for RRCConnectionRequest in EUTRA TS 36.331 v15.4. into binary format before being passed on to lower layers for transportation. On receipt, the binary format messages are decoded into various fields and sub-fields present in the RRC message. 3GPP specifies the grammar rules to be followed by both gNB and UE for encoding and decoding RRC messages. Rules for RRC are specified in a language called ASN.1. An example rule set for the RRC message RRCConnectionRequest is shown in Figure 2.9.

2.4 ASN.1

Abstract Syntax Notation One (ASN.1) is an interface description language used for describing rules of communication in heterogeneous systems. It is commonly used in Telecommunications and computer networking for network protocols including RRC, S1AP, XnAP, NGAP, etc. [26] ITU-T developed the standards for ASN.1. The messages identified in technical specifications are defined in ASN.1 language as shown in Figure 2.9. It is important to translate the ASN.1 type message into machine understandable format for programming and encoders, decoders. For this, open-source and proprietary translators are available like asn1c by vlm [27], ASN1C by OSS [28]. The translators parse ASN.1 definitions from a given standard (through the ASN.1 file) and create data structures usable by many programming environments. The ASN.1 specification also defines various encoding, decoding rules to be used during message transportation. The encoding and decoding rules specify how messages should look like while transmission. For RRC messages, 20 CHAPTER 2. BACKGROUND

RRC Message of SEQUENCE Type

Field Type Type

OCTET STRING (Optional) Structure of Structure of 4-8 bytes SEQUENCE Type SEQUENCE OF Type

Field Field Type

INTEGER BIT STRING Structure of 1-65535 40 bits SEQUENCE Type

Field

OCTET STRING 4-8 bytes

Figure 2.10: Example tree fashion ASN.1 structure of an RRC Message.

3GPP specifies to use Unaligned Packed Encoding Rules (UPER) for encoding/decoding messages given in ASN.1 syntax in TS38.331 [25]. UPER is standardized by ITU-T in X.691 (Last updated in 2015) [29]. The UPER considers ASN.1 syntax and defines the message structure bit by bit (or by octets) to produce the most compact transfer syntax for data structures in ASN.1. The UPER encoding produces a byte sequence with no regard for octet (byte) boundaries. The decoders require data structure knowledge from specifications in ASN.1 or some translated form to parse the received byte sequence bit by bit. The ASN.1 structure for messages can be identified as a data structure in a tree fashion as shown in Figure 2.10. Each message could contain multiple sub fields or sub structures with their own message definition. The size of each data or data structure type can be restricted based on constraints provided in message specifications. For example, RRCConnectionRequest shown in Figure 2.9 specifies the size of randomValue to be exactly of 40 length bit string. Such constraints are applicable for every data type. These constraints are taken into consideration when encoding and decoding the transmitted message. Few data types might be unbounded, as in an undefined length for a bit or octet string. Unbounded strings can lead to no size limit on the message length. The tool developed in this thesis work would identify data fields that are unbounded and send long messages to trigger errors in receiving systems (here EPC and eNB). CHAPTER 2. BACKGROUND 21

asn1c asn1c is an open-source tool that provides the functionality of converting message schemas in ASN.1 format into programming environments. It translates given schema into C/C++ language programming environment and can be integrated into any programmable system for easy translation, decoding, encoding of a an ASN.1 message. By using 3GPP’s ASN.1 file (a description file containing all RRC messages extracted from 3GPP technical specifications), this thesis work provides knowledge related to RRC messages into the fuzzing scenarios considered for testing. asn1c conforms to X.91 specifications of ITU-T for UPER, which are used by RRC messages in as specified in 3GPP standards. asn1c would identify constraints corresponding to a data type (INTEGER, OCTET STRING, BIT STRING, ENUMERATED, BOOLEAN, NULL, SE- QUENCE, SEQUENCE OF, SET, SET OF, custom data types). By traversing through the given standard, asn1c would generate “C” language files that can be used in C/C++ programming environments.

2.5 Fuzzing

Testing a software is part of the development process of the software. Sim- ilarly, networks and network protocols are also tested for various scenarios before deploying them. To ensure reliability in a network-based communication, multiple testing techniques are employed before deploying them. Con- formance testing is one of the testing methods to verify that networks and software adhere to a standard way (or user expected manner) by sending user expected inputs or messages. While robustness testing tries to identify the behavior under maligned inputs or messages. Fuzzing is a commonly used technique for security testing a software to identify vulnerabilities. It is a robustness testing technique that creates malformed messages and sends it to a System Under Test (SUT) to monitor for potential crashes or errors. Fuzzing creates or simulates attacks similar to what an attacker or hacker would send to compromise the system. It is a brute force method that creates various possibilities and observes the SUT for crashes or deviation from expected behavior (for e.g., OSS-fuzz by google [8]). Commonly found fuzzers either perform a black-box or grey-box fuzzing. A black-box fuzzer does not have any prior knowledge about the SUT and creates messages at random. Such black-box testing fuzzers are not able to identify many vulnerabilities due to lack of intelligence about the SUT [30, 31, 22 CHAPTER 2. BACKGROUND

System Fuzzer Under Test

Observer

Figure 2.11: General fuzzing framework.

32]. Grey-box testing assumes some knowledge about the SUT and creates test cases or messages intelligently to let the SUT assume that the messages are in fact correct and go deeper into the code coverage. This way higher number of faults could be identified by a fuzzer [33, 34]. A fuzzing framework, as shown in Figure 2.11, generally consists of a fuzzer to create test cases, an SUT under test, and an observer that monitors behavior of SUT to provide feedback to the fuzzer for next test case creation or identify vulnerabilities triggered. The messages created by a fuzzer can be through mutating previous inputs or messages available beforehand or generating from scratch. This type of classification is applicable to fuzzers and they can be broadly classified into a mutation-based or generation-based, depending on the method of message creation. A mutation based fuzzer parses and stores existing inputs provided by the SUT or sender and changes or mutates some or all fields in the message before passing on to the SUT. Similarly, a generation based fuzzer creates the messages from scratch before sending to the SUT. A generation based fuzzer provides complete coverage of the testing or fuzzing space of SUT while mutation based can be easier to implement and begin testing of SUT. The mutation based fuzzers can mutate (fuzz) existing fields in variety of ways like bit/byte flips of specific bits, max/min values of integers, characters and strings, integers that commonly find bugs (special bytes), appending long sequences of bit/bytes, splicing of two strings, etc. The fuzzing can also be a combination of these strategies to trigger and identify a fault in SUT. American Fuzzy Lop (AFL) is a mutation based fuzzer that creates test cases based on provided input [35]. Similar mutation based fuzzers include Sulley, SPIKE, CHAPTER 2. BACKGROUND 23

ZZUF, boofuzz, etc. [36, 37, 38, 39, 40] On the contrary, generation based fuzzers, as mentioned before, do not require knowledge from previous inputs. The generation-based method can produce test cases using knowledge from SUT and/or various sources to try all possible values in an input. Fuzzers like Peach, SNOOZE, SPFuzz, T-Fuzz and LTEFuzz are considered as generation based that can cover entire fuzzing space possible [41, 42, 6, 43, 9]. The above mentioned fuzzers are descried briefly with differences and gaps identified to motivate this thesis. Fuzzers can also be classified as smart/intelligent and dumb fuzzers based on the knowledge of messages being sent to SUT. This classification stands apart from black/gray box fuzzing which depend on the knowledge of SUT. A dumb fuzzer tries all possible values in a binary file to identify possible errors. While, a smart/intelligent fuzzer uses knowledge from various sources and feedback to create the next message being sent to SUT. In network communication among heterogeneous systems, the devices employ grammar or rules based communication to standardize the understanding of messages sent or received. Fuzzers in such scenarios that use the rules to create the message are called grammar based fuzzers which are smart. Examples for grammar based fuzzers include T-Fuzz, SPFuzz and AutoFuzz. Some fuzzers use the state of SUT to trigger new or specific messages based on the state machine of SUT [5, 39, 41, 42, 7, 6]. The fuzzers store state machine of SUT and monitors the state engine of SUT to identify proper response, input from fuzzer. The fuzzers SNOOZE, Boofuzz, SPFuzz, Auto- Fuzz use state machine of SUT when testing them and have the capability to return to a valid state before beginning the next fuzzing session.

2.6 Related Work

As mentioned earlier, fuzzing is a common robustness testing technique used before deployment and for early identiﬁcation of bugs. There are some generic fuzzers like OSSFuzz by Google [8] and American Fuzzy Lop by Michal Za- lewski [35] which can be used directly to test any software or network protocol implementation with few original messages or inputs. Meanwhile, fuzzers like SNOOZE [42], SPIKE [36], Sulley [39] and boofuzz [38] are built for network protocols providing testing frameworks around automating the test process. OSSFuzz, AFL, SPIKE, Sulley and boofuzz do not consider the grammar- based implementation of network protocols (example - ASN.1 rules for RRC 24 CHAPTER 2. BACKGROUND

in LTE and 5G) and would try many possible messages to trigger and identify a fault. At the same time fuzzers like AutoFuzz [7] and SPFuzz [6] are using protocol specifications to extract knowledge about grammar rules of SUT. While they are popular for Internet protocols, they do not consider grammar rules like ASN.1 for testing telecommunication protocols. Fuzzing in telecommunication is becoming increasingly popular with introduction of proprietary fuzzers like PeachFuzz [41], Defensics by Synopsys [44] and P1 Telecom Fuzzer (PTF) [45]. LTEFuzz [43] and GSMFuzz pro- pose the testing of control plane and SMS implementations in telecom networks. Fuzzers mentioned here for telecommunication systems craft the input messages by embedding SUT knowledge into fuzzing process. These fuzzers are not agnostic of the protocol and its version of specifications. The fuzzing tool developer would have to carefully analyze each release of specifications for changes before embedding the fuzzer with new knowledge. The closest to being protocol and version agnostic in telecommunications testing are T-Fuzz [9] and T3FAH [10]. Both use TTCN-3 models that are commonly used for conformance testing of NAS and other layers in telecom. Both T-Fuzz and T3FAH cannot extract knowledge directly from 3GPP specifications and require additional effort for beginning the testing process. Also, none of the above mentioned fuzzers are used for RRC protocol. As RRC messages are encoded by UPER rules using ASN.1 structure, this thesis work provides a so- lution to use decoder of UPER rules coupled with ASN.1 syntax of RRC messages from 3GPP specifications that can be agnostic to any version of 3GPP RRC specifications. At the same time, this thesis work provides the methodology that can be used for fuzz testing other ASN.1 based protocols (S1AP, XnAP). The adaptive fuzzer developed in this thesis chooses a mutation-based fuzzing technique opposed to generation-based fuzzing (used by T-Fuzz, LTE- Fuzz, Sulley, SNOOZE and Peach fuzzers). Using mutation-based fuzzing technique provides greater control to testers over the fuzzing process in an input. Though mutation-based fuzzer is restrictive in the amount of fuzzing space it can cover, it creates the messages that look very similar to the expected message (as it uses the structure of original input). Also, mutation- based fuzzers are easier to begin with for testing the network protocol or telecom system. CHAPTER 2. BACKGROUND 25

2.7 RRC and Fuzzing

RRC protocol carries the bulk of control plane messages between UE and 5G network. Errors in gNB and 5G-C are dangerous compared to errors in UE. As the first case would lead to loss of availability across network compared to latter where only a specific handset can be compromised. Also, in the second case, the malformed messages must be sent from gNBs, which are generally inaccessible to attackers. Hence, testing only gNB and 5G-C is considered in thesis work. This testing is performed by sending malformed RRC messages from UE. As RRC messages operate in a layer below NAS layer, they carry NAS protocol messages in either encrypted or clear text formats. By assuming no knowledge on NAS protocol and its procedures, fuzzing RRC messages allows partial fuzzing of NAS layer implementation as well. To create a truly adaptable fuzzer for RRC protocol, the fuzzer, would have to build knowledge about ongoing RRC messages following 3GPP standards. The fuzzer should interpret different fields and structures inside the input RRC message. As the RRC messages follow ASN.1 UPER rules for encoding and decoding, any UPER ASN.1 decoder can identify different fields and structures inside the message. UPER encoders and decoders need the knowledge of RRC messages as defined in ASN.1 schema from 3GPP. Using knowledge from such schematics, a binary formatted message can be encoded or decoded into programming environments. Similarly, the fuzzer would require knowledge from 3GPP’s RRC ASN.1 schema to encode and decode RRC messages from binary format into its programming environment. Existing ASN.1 parsers provide a facility of translating schemas in ASN.1 format to common programming languages like C/C++, C#, Java, Python. Ob- jective Systems provides a proprietary ASN.1 to C/C++, C# and Java parser [28]. Similarly, asn1c by Lev Walkin translates ASN.1 language based structures into C/C++ based data structures [27]. Other such tools can be found at [46]. asn1c by Lev Walkin provides an open-source encoder and decoder for converting the a binary UPER encoded message into C/C++ programming environment with individual fields identifiable for content and data types. The decoded structure can be used by a fuzzer to mutate existing fields before encoding the fuzzed message to be sent to gNB. With little to no prior knowledge about the ongoing messages, the fuzzer could leverage asn1c to transparently integrate the functionality into its fuzzing framework. The transparent integration of asn1c into a fuzzer could enable 26 CHAPTER 2. BACKGROUND

testing of all network protocols using ASN.1 as its description language and UPER rules for encoding, decoding of the messages. Also, testers using such a fuzzer would need minimal eﬀort to couple it with existing telecommunication or networking systems before beginning their testing processes.

2.8 Similarities between 5G and LTE

gNB/ng-eNB/ UE AMF/MME eNB NAS NAS

RRC RRC

PDCP PDCP

RLC RLC

MAC MAC

PHY PHY

Figure 2.12: Networking layers involved in 5G and LTE control plane messages.

As there are no open source 5G implementations to test with the fuzzer developed, this thesis identiﬁes existing open-source implementations for LTE, given the similarity between both the versions of telecommunication systems. 5G evolved from LTE maintaining the separation between control and data plane. 5G also uses the same layers in control plane interaction between UE and gNB as shown in Figure 2.12. EUTRA (RAT in LTE) will continue to be in use through initial phases of 5G deployment in non-standalone (NSA) option of 5G. Also, EUTRA is proposed to co-exist with 5G NR as a dominant air interface between 5G UE and NG-RAN. UE can talk to a next generation evolved base station (ng-eNB) using EUTRA, where ng-eNB is part of NG-RAN. 5G NR is created with conceptual similarities from EUTRA. 5G NR uses OFDM CHAPTER 2. BACKGROUND 27

symbols and sub-carrier spacing for identifying time and frequency resources in radio spectrum. Hence, it becomes relevant to test LTE implementations as well. In RRC specifications for LTE and 5G, 3GPP proposes use of primitive data types (INTEGER, OCTET STRING, BIT STRING, ENUMERATED, BOOLEAN, NULL) with data and structured data types (SEQUENCE, SE- QUENCE OF and CHOICE) that contain both primitive and structured data types. This thesis work considers only these eight data types when traversing and fuzzing the RRC messages. In future, if necessary, there is a provision for increasing support to more data types used in ASN.1 for RRC and other network protocols. srsLTE This thesis uses srsLTE as an emulated telecommunication network with access to UE’s control plane stack. srsLTE is an open-source platform developed by Software Radio Systems (srs) that emulates an actual LTE system with a light-weight core network (srsEPC), a base-station (srsENB) and a User Equipment (srsUE). It provides an EUTRA radio access technology stack (Fig- ure 2.12) implementation in UE as well as in eNB. srsLTE supports software defined radios (SDRs) like USRP, Soapy, Lime SDR and a no RF front-end option to simulate radio interface in a computer. It is a common evaluation tool among researchers for an LTE system. As of February 15, 2021, srsLTE is 3GPP Release 10 aligned with radio stack working towards Release 15 5G NR [47]. It is built over an existing open-source implementation of LTE called openLTE [48]. srsLTE uses many functions and structure of code related to RRC and NAS message handling from openLTE. This way some vulnerabilities found through this evaluation process could be applicable to systems already using openLTE. 1 One of the radio options in srsLTE is a no RF front-end option. This allows a user to send PHY layer messages between UE and eNB over IP interfaces instead of actual radio devices. Both srsUE and srsENB use ZeroMQ driver with no Radio Frontend option by srsLTE to emulate a radio interface between them. It also allows all three LTE nodes (srsUE, srsENB and srsEPC) to run in the same computer, provided necessary configurations are set. srsUE can send

1The author of this thesis only suggests there could be a vulnerability when using openLTE and does not investigate the root cause for any vulnerabilities identiﬁed (out of scope for this thesis) 28 CHAPTER 2. BACKGROUND

srsEPC

Application IP request MME HSS

IP based IP srsUE srsENB S/P-GW networks

no RF front IP based no RF front end with end with zeroMQ zeroMQ

Figure 2.13: srsLTE nodes no RF front-end. and receive calls, web traﬃc through a dedicated interface similar to an actual handset. The srsEPC is lightweight in nature with interfaces towards IP networks through software gateways (S/P-GWs) and stores UE data for authentication, authorization through MME and HSS modules. Figure 2.13 shows the three nodes of srsLTE in no RF front-end operation mode. All three nodes produce system logs that which can be used for identifying any unexpected behavior or a crash in any of the application nodes.

2.9 Summary

This chapter provided necessary background information for understanding telecommunications systems in general and the necessity for testing network equipment for robustness. It then identiﬁed previous works relevant to fuzzing, fuzz testing and usage of fuzzing in telecommunications. The gaps in relevant work motivated towards designing the adaptive fuzzer in later chapters. Chapter 3

Design and Methodology

This chapter will present an approach that can be taken to create an adaptive fuzzer for testing RRC and other ASN.1 language based communication protocols. First it identiﬁes the requirements in understanding the grammar rules of RRC messages. This chapter then introduces the design framework for operation of such an adaptive fuzzer. In subsection 3.2.1, it also provides pseudo code that will be used in future chapters for designing the fuzzer.

3.1 Design Requirements

The following requirements are identified to be fulfilled by this thesis work and the adaptive fuzzer for testing 5G and LTE systems: 1. Identify an open source translator or parser to produce C/C++ based structures for EUTRA RRC ASN.1 schema 2. Implement a mutation-based fuzzer to mutate existing fields and structures with different strategies 3. Identify an open source implementation of LTE system to divert ASN.1 encoded uplink RRC messages 4. Automate the process to trigger new RRC messages in the 5G or LTE implementation and monitor the response of SUT under fuzzed message

3.2 The adaptive fuzzer

This thesis proposes a framework for the adaptive fuzzer as shown in Fig- ure 3.1 to satisfy the design requirements identiﬁed. It consists of a fuzzer,

29 30 CHAPTER 3. DESIGN AND METHODOLOGY

FUZZER (UE) RRC ASN.1 encoder/decoder producer

RRC ASN.1 ASN.1 specification compiler

RRC models Fuzzing parameters

RRC ASN.1 encoder/decoder

RRC message mutator Decode Mutate Encode RRC message Mutated RRC the encoded the decoded the mutated message (ASN.1 SUT (ASN.1 encoded ) message message message encoded ) (RAN)

OBSERVER

Figure 3.1: Adaptive fuzzing framework for an ASN.1 based network protocol. an observer and a SUT. The adaptive fuzzer follows pseudo code provided at algorithm 1. Rather than embedding the fuzzer with message structures of RRC, the adaptive fuzzer uses C models generated by asn1c to fuzz fields of the message. Fuzzing is performed by taking advantage of a general RRC message structure in generated C models. The adaptive fuzzer developed in this thesis can be paired with an existing 5G and 5G NR system to identify where UL-CCCH or UL-DCCH messages are sent to the lower layers. Mutation instead of generation as the method of fuzzing provides greater control to the tester. In mutation-based fuzzing, existing messages are used as inputs to the fuzzer for changing (mutating) content in some fields of the message. As mutated message maintain the original structure, SUT decodes the mutated fields similar to processing of an original message. This leads to greater penetration of fault identification in the SUT as well. The greater control comes from choosing which fields or datatypes to fuzz and which messages to fuzz in a handshake or sequence of messages being sent. This approach allows testers to maximize the possible values to test gNB/ng-eNB/eNB and 5G-C/EPC without feeding the many combinations possible with ASN.1 language. As shown in Figure 3.1, the adaptive fuzzer consists of two parts:

1. Fuzzer: uses RRC ASN.1 ﬁle for translating ASN.1 schema knowledge to its programming environment. Decode and encode uplink RRC messages before and after mutation CHAPTER 3. DESIGN AND METHODOLOGY 31

2. Observer: Monitors system logs for identifying crash after triggering RRC message

3.2.1 Fuzzer

Algorithm 1: Pseudo code for fuzzer in ASN.1 based adaptive fuzzing framework Input: Intercept uplink RRC messages if fuzzer turned on then Decode with UPER rules to fill C program structure; if RRC message selected for fuzzing then for All sub fields and sub structures in C structure of RRC message do if field matches strategy related parameters then Generate random content for the field and/or instantiate optional fields according to the strategy; else ignore the field; end end if Message fuzzed then Encode with UPER rules to be sent by UE; else Send original message; end else Do not fuzz and send original message; end else Send original message; end

The fuzzer follows pseudo code provided in algorithm 1. It diverts, decodes an ASN.1 encoded binary uplink RRC message, and after fuzzing some or all ﬁelds, it encodes back into binary ASN.1 message using asn1c’s encoder and decoder. The fuzzer relies on mutation-based fuzzing. Hence it changes (mutates) content of input RRC messages. When integrated with an 5G or LTE system by diverting system generated uplink RRC messages, the fuzzer will mutate the input uplink message. Using asn1c translated RRC model ﬁles (in C 32 CHAPTER 3. DESIGN AND METHODOLOGY

language), the decoder extracts contents of uplink RRC messages of the LTE environment (SUT) conforming to a particular RRC specification. The extracted contents are stored in C programmable data structures which are used by the adaptive fuzzer to mutate fields as per requirement. asn1c provides a general structure for all ASN.1 messages while translating ASN.1 files, as shown in Figure 2.10. This generic structure consists of a C data structure that stores knowledge from RRC ASN.1 specification and a programmable memory identified by pointers. The C model (data structure) dictates position of a field or sub structure through offsets in the programmable memory. This generic organization of RRC messages in C programming environment allows the fuzzer to mutate existing contents after decoding. As both EUTRA and 5G NR specifications mention the uplink RRC messages through logical channels CCCH and DCCH, this thesis work considers the mutation of only UL-CCCH and UL-DCCH messages. The amount of mutation of fuzzing is controlled through fuzz strategy parameters file. It contains user programmable controls to fuzz specific data types (OCTET STRING, BIT STRING, INTEGER, etc.), fuzz specific fields and initialize optional fields. The new content created for the selected fields conform to constraints as specified in 3GPP technical specifications. The information related to constraints is stored in translated C models by asn1c. By conforming to constraints, SUT processes all mutated content created by adaptive fuzzer. The adaptive fuzzer allows repeatable experiments to replay same content by setting a user-controlled seed in the beginning of randomization process of C program. By tracking the seed, iteration number and fuzz strategy parameters, any message mutated by adaptive fuzzer can be easily recreated and trigger the observed SUT behavior (both crash and normal operation). Once an RRC message is mutated, the encoder repacks new contents into UPER encoded binary format for transportation to SUT.

3.2.2 Observer Having an Observer allows monitoring of SUT for any unexpected behavior. A common method to identify unexpected behavior is by reading system generated logs. Many fuzzers adopt this method to identify crashes and buﬀer overﬂow messages. It is also possible to identify unexpected behavior by embedding the knowledge of a state transition procedures of SUT in fuzzer. The continuous monitoring for expected state creates a possible observation point for unexpected behavior. Monitoring state machine is considered in this thesis CHAPTER 3. DESIGN AND METHODOLOGY 33

Connection establishment/ Release RRC_IDLE RRC_CONNECTED

Figure 3.2: RRC State Machine in EUTRA [49]. work provides trigger for new RRC messages. This is diﬀerent from stateful fuzzers which can fuzz the sequence of messages in a handshake and state transition. Unlike the fuzzer, an Observer is dependent on SUT as log generation varies with 5G and LTE implementations. The observer performs dual operation of observing SUT’s behavior and driving new uplink RRC messages for fuzzing. The Observer in this thesis work is built for srsLTE’s LTE implementation which is discussed in more detail in section 4.2. RRC in LTE and EUTRA radio access technology follow state machine as shown in Figure 3.2. Bulk of RRC messages are passed between UE and ENB in transition of UE from RRC_IDLE to RRC_CONNECTED during connection (re)establishment. By identifying which RRC messages are sent from UE in uplink, users can select which RRC messages to fuzz and the necessary strategy parameters that can be applied during fuzzing. Observing the additional delay due to decoding, mutation and encoding of RRC messages helps in identifying eﬀects to performance of LTE system due to such a fuzzer. Starting from the interception of uplink RRC messages to repacking of mutated messages, this thesis work measures time taken for the tasks of fuzzer and logs the measured time for future analysis.

3.3 Summary

This chapter presented the design requirements and steps involved for realis- ing an adaptive fuzzer to test RRC protocol and ENB/EPC implementations of LTE networks. It provided the algorithm used by the adaptive fuzzer for mutating an ongoing uplink RRC message in any UE to divert, decode, mutate, encode, and replace the original. This chapter also presents a methodology that can be used for designing an Observer to work with LTE implementations while monitoring for unexpected behavior and crashes. Chapter 4

Implementation

This chapter will provide the implementation details involved in realizing the adaptive fuzzer and an observer (based on srsLTE). For fuzzer, the fuzzing strategies and parameters that can be set by a user are given in subsection 4.1.1. Section 4.2 will present the pseudo code that can be applicable for testing any 5G and LTE implementations.

4.1 Fuzzer

As mentioned in subsection 3.2.1, the adaptive fuzzer uses generic nature of ASN.1 based messages for mutating the values of an input RRC message. This thesis work uses asn1c for storing knowledge from ASN.1 schema and programmable memory structures for mutating the values. asn1c parses any provided ASN.1 schema in "asn_DEF" data structures that store information related to size, value range, sub-fields, data type, etc. of each abstract data type. asn_DEF_UL_CCCH_Message, asn_DEF_UL_DCCH_Message data structures store the information related to uplink logical channels of UL-CCCH and UL-DCCH respectively. At the same time, the user programmable structures containing actual values for UL-CCCH and UL-DCCH are identifiable by UL_CCCH_Message_t and UL_DCCH_Message_t data structures respectively. For a provided UPER encoded message in binary format, the fuzzer decodes it using asn_DEF structures and populates all fields in the user programmable memory for fuzzing. As this thesis work is concerned with RRC uplink messages in 5G-NR and EUTRA radio access technologies, the fuzzer is provided with the capability of decoding UL-CCCH and UL-DCCH mes-

34 CHAPTER 4. IMPLEMENTATION 35

sages. asn_DEF_UL_CCCH_Message and asn_DEF_UL_DCCH_Message structures can be traversed for individual fields following the tree structure as shown in Figure 2.10. Figure 4.1 shows the various components and actions taken by the adaptive fuzzer starting from decoding input RRC message to sending the mutated RRC message. The fuzz strategy parameters from users control the amount of fuzzing on each uplink RRC message (described in subsection 4.1.1). The data types of fields in RRC messages can be either primitive (OCTET STRING, BIT STRING, INTEGER, ENUMERATED, BOOLEAN or NULL) or structured (SEQUENCE, SEQUENCE OF or CHOICE). RRC messages in 5G NR and EUTRA use only these eight data types as identified from 3GPP RRC specifications [25, 49]. Hence the adaptive fuzzer considers mutating only these data types (though it can be noted that the adaptive fuzzer can be easily extended to other data types used in ASN.1). OCTET STRING is a byte sequence and can have constraints related to length (for example, Dedicated- InfoNAS is an unbounded string with no constraints as shown in Figure 4.2). Similarly, BIT STRING is a sequence of bits. INTEGER data type in ASN.1 can be either a long, short, or normal integer depending on the use. ENUMER- ATED is commonly used to choose among multiple options (like choosing a flag in a variable). BOOLEAN can be either True or False while NULL data type does not contain any data. At the same time, the structured data types do not contain any actual content but consist of other primitive or structured data types. SEQUENCE is a list of fields and SEQUENCE OF is a list of items of same data type. CHOICE provides an option to choose among all sub-fields (both primitive and structured data types). The root node in tree structure of uplink RRC messages is always either asn_DEF_UL_CCCH_Message or asn_DEF_UL_DCCH_Message. Both UL- CCCH and UL-DCCH messages are of SEQUENCE type. Different RRC messages are identifiable through the nodes in tree structures of UL-CCCH and UL-DCCH messages. Adaptive fuzzer traverses the tree structure and looks for any RRC message to fuzz and depending on fuzz strategy parameters for each field, the adaptive fuzzer either mutates, deletes, extends, or initializes new values into it. The adaptive fuzzer controls amount of mutation (fuzzing) in an ongoing RRC message through fuzz strategy parameters. The parameters can be controlled by user and are provided through programmable variables. The following sections describe different fuzzing and mutation strategies developed 36 CHAPTER 4. IMPLEMENTATION

FUZZER 3GPP(UE) TS 36.331 version 15.8.0 Release 15 RRC ASN.1 encoder/decoder649 ETSI TS 136 331 V15.8.0 (2020-01) producer

RRC ASN.1 ASN.1 – DedicatedInfoCDMA2000specification compiler The DedicatedInfoCDMA2000 is used to transfer UE specific CDMA2000 information between the network and the RRC models UE. The RRC layerFuzzing is parameterstransparent for this information.

DedicatedInfoCDMA2000RRC ASN.1 information element encoder/decoder

RRC message mutator Decode Mutate Encode RRC message Mutated RRC the encoded the decoded the mutated message (ASN.1 (ASN.1 encoded ) message message message encoded ) – DedicatedInfoNAS

The IE DedicatedInfoNAS is used to transfer UE specific NAS layer information between the network and the UE. The RRC Figurelayer is transparent 4.1: Componentsfor this information. of the mutation based adaptive fuzzer. DedicatedInfoNAS information element

Figure– 4.2:FilterCoefficient ASN.1 description of DedicatedInfoNAS in 3GPP TS [49].

The IE FilterCoefficient specifies the measurement filtering coefficient. Value fc0 corresponds to k = 0, fc1 corresponds to k = 1, and so on. in this thesis based on ASN.1 language and RRC protocol. FilterCoefficient information element

4.1.1 Fuzzing Strategies Each fuzz parameter creates a fuzzing strategy for network protocol or SUT that can be tested with the adaptive fuzzer. This section describes how the parameters– canFlightPathInfoReportConfig be used to create random content in a selected RRC message. The IE FlightPathInfoReportConfig speficies flight path information report configuration.

Primitive data types FlightPathInfoReportConfig information element • fuzz bit string: When enabled, the adaptive fuzzer fuzzes sub-fields of BIT STRING type it comes across. The fuzzer deletes existing BIT STRING and creates a new random BIT STRING in its place, based on specified constraints. UPER has strict and concise encoding rules. When the specified length of BIT STRING is not a multiple of 8, the resultant content will be a random byte string with some unused bits (8- size%8) towards the end. The fuzzing engine identifies such constraints and generates new byte sequence with no data generated for unused por- tion. BIT STRINGs can have a variable length randomly chosen in pos-

ETSI CHAPTER 4. IMPLEMENTATION 37

sible range or can be unbounded as well depending on its constraints. If the size is in a range, the new BIT STRING will be of random length within the range. When unbounded, the new BIT STRING will be of same length as the original and can have a random bit string appended to it

• fuzz octet string: Similar to fuzzing bit string, the adaptive fuzzer can fuzz sub-ﬁelds of OCTET STRING type. The fuzzing engine deletes existing OCTET STRING and creates a new one in its place. Like fuzzing BIT STRING, the length of new random OCTET STRING is dependent on constraints. And when length is unbounded, the new OCTET STRING will be of same length as the original with an option to append random bytes to the original

• fuzz integer: ASN.1 supports long integers 264, short and unsigned integers as well. The specifications can also define for integer to be in a specific range. The fuzzing engine identifies lower and upper bound if applicable and creates new value for the integer within range. Else a random integer of long type (64-bit integer) will be created for the field

• fuzz enum: ENUMs or enumerated types are used commonly for choosing one value among multiple options. asn1c produced C models and memory structures store ENUM data types as integers (with each available choice identiﬁed in a range of numbers to choose from). asn_DEF structures contain range of ENUM ﬁelds (generally starting from 1). The adaptive fuzzer selects a new choice within the range randomly

• fuzz bool: BOOLEAN variables are used when choosing between true or false. The adaptive fuzzer can randomly choose between true and false for the boolean field The adaptive fuzzer is capable of fuzzing multiple fields of same data type in the same message. Hence users can choose to fuzz only one or multiple data types in the same message. For structured data types (SEQUENCE, SEQUENCE OF and CHOICE), the adaptive fuzzer traverses through them to identify fields of primitive type before fuzzing them depending on user’s choice of parameters.

Fuzzing by name • fields to fuzz: This parameter lets user fuzz specific fields based on name. Users can mention multiple fields to fuzz in the same message as well. 38 CHAPTER 4. IMPLEMENTATION

When a name is mentioned, the adaptive fuzzer acts independent of fuzzing primitive data types and creates random content for the matched ﬁeld name. For e.g. in RRCConnectionRequest, there are multiple bit strings (called mmec and m-TMSI or randomValue) in each message. By choosing to fuzz only "mmec" and selecting fuzz bit string to false, only mmec is fuzzed and m-TMSI is not fuzzed. This provides greater control to users for trying multiple paths in same RRC message

• messages to fuzz: By choosing to traverse only the selected RRC message, this thesis work provides automation capabilities and ability to fuzz RRC messages of different names during same fuzzing session. When a RRC message name is provided, the adaptive traverses through it to find individual primitive data type fields before fuzzing them based on other fuzz strategy parameters

Additional fuzz strategies • append string: When set, the adaptive fuzzer appends long random sequence of bytes to unbounded BIT and OCTET strings. In this thesis, the adaptive fuzzer appends random bytes until the string length is 1000 bytes (limited by empirical observations in size of srsLTE uplink RRC messages). The user can choose to retain original string while appending or choose to mutate the original as well

• fuzz optional fields: Some fields (both primitive and structured) in each RRC message can be of optional in nature (can be identified from technical specifications). When selected, for all optional fields the adaptive fuzzer comes across, it initializes if not previously present and removes if they are already present. If it is of structured type, the fuzzing engine initializes all underlying fields of both optional as well as mandatory nature

• seed for randomization: It is an integer that can be provided by user before beginning the fuzzing process. As computers and programmable systems can generate only a pseudo random numbers as part of their randomization processes, setting a seed helps in creating a repeatable and predictable sequence with same seed when performing same number of random calls. This control over randomization allows the adaptive fuzzer to create deterministic test cases and still provide a randomization as part of its process. By tracking the number of messages that are created after setting a seed will allow the observer to track each message CHAPTER 4. IMPLEMENTATION 39

Figure 4.3: Wireshark packet capture of UECapabilityInformation generated by srsUE (UE implementation in srsLTE).

that is fuzzed and provide unique identiﬁcation for the ASN.1 encoded binary messages

Before beginning the fuzzing process, the adaptive fuzzer loads seed from fuzz strategy parameters file. This thesis work uses libconfig, a popular configuration file parser, for loading all strategy related parameters [50]. For each RRC message name matched by lookup, the fuzzer performs necessary fuzzing actions and stores the resultant ASN.1 encoded binary with a file name as temp___.bin which signify information regarding seed used and the iteration of fuzzing for creating the fuzzed message. Storing the binaries help in replaying and verifying the behavior for future analysis. Figure 4.3 and Figure 4.4 show an example of fuzzing by comparing srsLTE generated UECapabilityInformation (an uplink RRC message) and the same message after mutating by the adaptive fuzzer respectively. Here, one of fields called ueCapabilityRAT-container (an unbounded OCTET STRING) is fuzzed by appending 989 random bytes to the original 11 bytes generated by srsLTE. The additional strategy related parameters allow users to explore many hidden paths not found in traditional fuzzers. Possible combinations of all fuzz strategy parameters allow users to come up with various fuzzing strategies based on the need of network protocol under test (SUT). For evaluation pur- 40 CHAPTER 4. IMPLEMENTATION

Figure 4.4: Wireshark packet capture of UECapabilityInformation with fuzz_append_string set to true. poses, this work considers few combinations possible in the srsLTE system as described in chapter 5. As asn1c translates all RRC messages available in an ASN.1 file and stores as model C language files, the test cases generated are dynamic in nature by not depending on embedding of knowledge about the message. The fuzzing engine does not retain any information related to the message generated earlier and assumes that each message is independent. This results in a truly dynamic fuzzer adaptable to any ASN.1 file sent through asn1c parser. The model C files conform to the version of RRC specification sent through asn1c and allow users to use this adaptive fuzzer for any version of RRC and any implementation of 5G or LTE system.

4.2 Observer

As mentioned earlier, the observer is dependent on 5G and LTE implementations. An observer actively monitors various nodes involved in 5G/LTE system and looks for unexpected behavior before reporting back to fuzzer or store CHAPTER 4. IMPLEMENTATION 41

them in logs (for future analysis). This thesis work is concerned only with one open-source implementation of LTE system called srsLTE [51]. Currently there are no open-source 5G systems available to evaluate the adaptive fuzzer developed in this thesis. And given the similarities between 5G and LTE systems with common layered structure of radio interfaces (refer section 2.8), this thesis work assumes that evaluation of an LTE system would also be applicable to a 5G system (both open-source and proprietary).

Pseudo code for observer In an LTE system, either a UE or core network initiates the communication. When powering up or initiating both web and call traffic, the UE scans prepro- grammed RF space for identifying an LTE network and proceeds accordingly. When in IDLE mode, the core network can try to reach the UE (for example, incoming calls to UE, paging for SMS, etc.). In either case, both UE and ENB transmit multiple RRC messages for successful handshake connection. By triggering UE initiated traffic, the user can control the fuzz initiation process. This thesis work considers triggering RRC messages when UE is in RRC_IDLE mode to use srsLTE generated RRC messages. The observer is responsible for triggering new messages and monitoring the response of SUT. The SUT consists of either gNB & 5G-C or eNB & EPC. It is possible to test various combinations of gNB, eNB, ng-eNB as 5G network when deployed will still use eNB and EUTRA as a primary access technology. Also, with non stand alone implementation of 5G NR, it is possible to send fuzzed messages with 5G NR specifications to EPC. In this thesis both srsENB and srsEPC become part of SUT. The fuzzed RRC messages reach srsENB first that could trigger some unexpected behavior. Information from fields like dedicatedIn- foNAS, when fuzzed, reach srsEPC and in turn perform some level of testing on the core network, thus making it part of SUT. Algorithm 2 contains pseudo code followed by the observer in this thesis work for srsLTE. In LTE system, on expiry of RRC inactivity timer, the eNB triggers change of state from RRC_CONNECTED to RRC_IDLE (state with little to no information of UE at eNB and vice versa). This timer is generally in the order of 10s of seconds and is used when there is no data traffic between UE and eNB. For simplicity and faster testing of srsLTE system, the inactivity timer is set to 5 seconds during evaluation. It allows easier automation and repeated new RRC message triggers in srsLTE. Also, the time limit to unresponsive UE is set to be 60 seconds for this particular implementation of observer 42 CHAPTER 4. IMPLEMENTATION

Algorithm 2: Pseudo code for Observer Input: Initial seed, ping request limit and fuzz strategy parameters Start SUT and UE for context setup and successful connection; while seed less than RAND_MAX do for ping requests less than the limit do if UE in RRC_IDLE then Send an IP ping request from UE; Monitor SUT for response and crashes; if crash found then Track seed and instance of ping request; Kill UE, SUT for restart; else continue; end else Wait for previous RRC messages to be sent; Monitor SUT for response and crashes; if crash found then Track seed and instance of ping request; Kill UE, SUT for restart; else if UE unresponsive for more than 60 sec then Kill UE, SUT for restart; else continue; end end end if UE and SUT killed then Increment seed and restart fuzzing; else continue; end end end and can be changed according to need of users. srsLTE outputs the following line - ’srsLTE crashed... backtrace saved in ’./srsLTE.backtrace.crash’...’ into the system log from the srsLTE node that crashed. Using this as an identi- CHAPTER 4. IMPLEMENTATION 43

fier, the observer implements pseudo code shown in algorithm 2 for this thesis work to identify crashes. The same pseudo code can be adapted to any implementation of 5G or LTE system. By driving an IP request from UE application (srsUE), the observer can trigger new uplink RRC messages for fuzzing. The observer uses ping request as an IP packet and traffic driver in the evaluation setup. The seed and count of ping requests allows the observer to track which instance of RRC fuzzing is responsible for observed unexpected behavior. This tracking provides the adaptive fuzzer to recreate the identified unexpected behavior. Whenever the UE or SUT becomes unresponsive or crashes, all nodes in srsLTE are restarted after increasing seed. Also, this tracking allows adaptive fuzzer to skip random calls already performed in future and begin the fuzzing process from the last seed value it used. RAND_MAX is the maximum possible value that can be output by the pseudo random generator. By limiting the seed values from 0 to RAND_MAX, this thesis assumes most possible random combinations would be achieved for fuzzing and testing SUT. To limit the number of messages fuzzed with same seed, the observer would limit the number of ping requests to a maximum limit set by user.

4.3 Summary

This chapter presented steps involved in implementing the adaptive fuzzer proposed in previous chapter and an accompanying observer that suits srsLTE. It also provides information any such observer could use when designing the testing apparatus based on 5G and LTE system. Chapter 5

Evaluation

This chapter will provide the evaluation tools and configurations chosen to test srsLTE. Section 5.2 discusses different components involved when integrating srsLTE with the adaptive fuzzer and observer for testing. Section 5.3 will present the various fuzzing strategies with which srsLTE has been tested in this thesis. Later sections discuss the automation tools one can employ to automate fuzzing in srsLTE and filtering out false positives.

5.1 Evaluation tools

As mentioned in earlier sections, this thesis work tests EPC and eNB implementation of srsLTE. Accordingly, across all tests, srsLTE’s release 20.04.1 with commit tag c892ae56be5302eaee5ca00e270efc7a5ce6fbb2 (committed on May 9th, 2020) is used for SUT and UE. The observer and srsLTE used consider a single conﬁguration for the LTE system with one UE, one eNB and EPC using ZeroMQ no RF driver. As the ZeroMQ driver allowed all srsLTE nodes (UE, eNB and EPC) to run in a single computer, the entire evaluation setup has been built around it in a single computer. Messages between UE, eNB and between eNB and EPC are sent over virtual IP interfaces within the same computer. To maximize the number of messages fuzzed and to parallelize the testing process, four virtual machines running on 64-bit Intel x86 CPUs and vCPUs with Ubuntu 18.04 LTS Operating System have been used. srsLTE, asn1c as well as the adaptive fuzzer are written almost entirely in C/C++ language. Hence, to compile the adaptive fuzzer (implemented in C), asn1c and srsLTE, the common C/C++ compiler gcc is used (version 7.5.0).

44 CHAPTER 5. EVALUATION 45

Even though the adaptive fuzzer can work with any version of RRC standard, this thesis work tests only 3GPP release 15 version 4 of TS 36.331. This is because srsLTE release 20.04.1 uses the RRC version mentioned before. Also, up to srsLTE release 20.04.1, the ZeroMQ driver option is available only for 3GPP release 15 version 4 of RRC standards. Hence, only RRC ASN.1 specification TS 36.331 v15.04 is considered in the thesis work. The ASN.1 description for all RRC messages and fields is extracted from 3GPP specification, TS 36.331 v15.4.0 [49], using an internal tool set at Erics- son. This tool crawls through any given 3GPP specification, in Microsoft Word format, and produces a single file containing all ASN.1 descriptions of RRC messages and fields. It is a common procedure used across telecommunication industry and supported by 3GPP for creation of ASN.1 description file from specifications [52]. The extracted ASN.1 file is fed to asn1c, as shown in Fig- ure 4.1 to create C language data structures with knowledge from 3GPP standard. asn1c, with commit tag 00fa516f3c6ab247c263df6828143c34b1fbffa4 (committed on July 7th, 2020), is used across the tests and machines in this thesis work.

5.2 Integrating adaptive fuzzer with srsLTE

Figure 5.1 shows the test bed, as a block diagram identifying different components from srsLTE, the adaptive fuzzer and observer. The modified and new components are shown in gray and white, while the SUT, which is not modified is shown in yellow color. To integrate the adaptive fuzzer with srsUE, the binary format messages formed by srsUE are diverted before being sent to srsENB. This diversion is possible by identifying the formation of binary messages in one of the source files of srsUE (src/stack/rrc/rrc.cc). Similarly, after fuzzing, the adaptive fuzzer places the new binary ASN.1 encoded message back in the buffer from which it is diverted from. To srsUE, it would appear as if nothing changed. To assess the performance deviation, on srsLTE overall, due to the diversion and getting the new message, the adaptive fuzzer measures time taken for each such instance. The measured time is also presented as a result in chapter 6. The observer is embedded with knowledge about processes of srsLTE. sr- sUE, srsENB and srsENB run as separate process in the computer. As the observer monitors for the crash message ’srsLTE crashed... backtrace saved in ’./srsLTE.backtrace.crash’...’ periodically in srsLTE logs, it will identify the 46 CHAPTER 5. EVALUATION

FUZZER Fuzz strategy parameters

Mutated RRC message asn1c, RRC message (ASN.1 encoded ) RRC mutator (ASN.1 encoded )

Uplink RRC

UE srsUE log

Ping eNB srsENB log Request

Track EPC srsEPC Events log srsLTE logs logs

srsLTE logs SUT Observer

Figure 5.1: Integrating the adaptive fuzzer with srsLTE. crashed instance and stores the configuration, fuzzing parameters responsible for this instance in events log. srsLTE lets user generate traffic from srsUE. In a computer, by initiating web traffic from UE process, observer controls the RRC message creation in srsUE (which is diverted by adaptive fuzzer).

5.3 Identifying testing strategies

The uplink RRC messages from UE are sent during initial connection setup or when there is a state change (as shown in Figure 3.2). The state changes can be UE or network triggered depending on call and data traﬃc. During initial AS activation, UE transits into RRC_CONNECTED mode from RRC_IDLE after a successful UL-CCCH message. Remaining RRC messages in the handshake are sent in RRC_CONNECTED mode (refer to Figure 5.2). The NAS layer messages (Attach request, authentication request, authentication response, security mode command and security mode complete) are sent through dedicate- dInfoNAS ﬁelds in various RRC messages. As mentioned before, the adaptive fuzzer fuzzes dedicatedInfoNAS and in turn is capable of testing core network. When no activity is present in UE, ENB triggers transition of UE into CHAPTER 5. EVALUATION 47

UE (RRC/ gNB/ eNB 5G-C/ EPC NAS) (RRC) (NAS) RRCConnectionRequest

RRCConnectionSetup

RRC RRC CONNECTED CONNECTED RRCConnectionSetupComplete NAS: Attach Request

DLInformationTransfer NAS: Authentication Request

ULInformationTransfer NAS: Authentication Response

DLInformationTransfer NAS: Security Mode Command

ULInformationTransfer NAS: Security Mode Complete

SecurityModeCommand

SecurityModeComplete

UECapabilityEnquiry

UECapabilityInformation

RRCConnectionReconfiguration NAS: Attach Accept

RRCConnectionReconfigurationComplete

ULInformationTransfer NAS: Attach Complete

DLInformationTransfer NAS: EMM Information

RRCConnectionRelease Inactivity Timer

RRC IDLE RRC IDLE

Figure 5.2: RRC messages sent between UE and network during initial activation in 5G and LTE system.

RRC_IDLE mode. srsLTE lets us configure the inactivity timer for transition of UE from RRC_CONNECTED to RRC_IDLE state through the parameter rrc_inactivity_timer in eNB (is set to 5 seconds in current evaluation). By triggering an IP ping request from srsUE in RRC_IDLE state, UE can send or receive RRC messages to or from srsENB. For each RRC message triggered, the adaptive fuzzer mutates and sends new ASN.1 encoded binary format message to srsENB. In srsLTE ZeroMQ no RF option with one UE - one eNB - EPC configuration, srsUE could generate following RRC messages - RRCConnectionRe- quest, RRCConnectionSetupComplete, ULInformationTransfer, SecurityMod- eComplete, UECapabilityInformation and RRCConnectionReconfigurationC- 48 CHAPTER 5. EVALUATION

omplete. RRCConnectionRequest is sent through UL-CCCH logical channel while the rest are sent through UL-DCCH logical channel. In this thesis work, fuzzing of RRC is limited to only the above six messages. Various strategies based on contents of individual message are considered and shown in Table 5.1. Each strategy either fuzzes existing field(s), appends to unbounded bit (byte) strings and/or initializes optional fields in an RRC message. As the fuzz space is quite large for any given message, this thesis work limits the fuzzing to few possible binaries. For each row shown in Table 5.1, fuzz parameters are created and fed into fuzzing engine as shown in Figure 4.1. For e.g., to fuzz UECapabilityInformation by appending random bytes to ueCapabilityRAT-Container (an unbounded OCTET STRING) while including optional fields in the RRC message, the user needs to specify RRC message name to fuzz, field to fuzz (here ueCapabilityRAT-Container) and set strategy parameters to appending string, fuzz optional fields. The testing process be- gins with seed set to 0 and it is incremented on either identifying a crash, when nodes in srsLTE are unresponsive or after the number of ping requests exceed set limit.

5.4 Collecting Results

As mentioned in subsection 4.1.1, the evaluation of each strategy is performed by storing binaries messages created due to each selected strategy. With help of automated scripts, this thesis work tests all fuzzing strategies as shown in Table 5.1 and stores the binaries into separate folders (for future analysis and repeatability). For example, consider the scenario of initializing optional fields and fuzzing, appending to ueCapability_RAT_Container in ueCa- pabilityInformation with randomization seed as ’75’. The folder will contain binaries created with this strategy only. The names of binaries begin with temp_dcch_75_1.bin for seed set to ’75’. If a crash occurs at either EPC or ENB, the observer notes seed and the instance of ping request that resulted in crash. Generally, each ping corresponds to a specific binary file. However, sometimes, the UE can reattempt to connect to network on unsuccessful attach in first attempt. This would create a mismatch between ping count and fuzzed message count. Such scenarios are tracked on a case by case basis for any identified unexpected behavior. Other- CHAPTER 5. EVALUATION 49

Fuzzing strategies with field names, data types and RRC message additional strategies randomValue mmec m-TMSI RRCConnectionRequest ng-5G-S-TMSI-Part1 ENUM BIT STRING INTEGER OCTET STRING Append to dedicatedInfoNAS RRCConnectionSetupComplete Append to dedicatedInfoNAS and include optional fields Include optional fields Fuzz existing and append to dedicatedInfoNAS, include optional fields INTEGER and OCTET STRING OCTET STRING Append to dedicatedInfoNAS ULInformationTransfer Append to dedicatedInfoNAS and include optional fields Include optional fields Fuzz existing and append to dedicatedInfoNAS, include optional fields INTEGER SecurityModeComplete Include Optional fields INTEGER ENUM OCTET STRING Append to ueCapabilityRAT-Container UECapabilityInformation Append to ueCapabilityRAT-Container and include optional fields Fuzz existing and append to ueCapabilityRAT- Container, include optional fields Include optional fields INTEGER and ENUM RRCConnectionReconfiguration INTEGER Complete Include Optional fields Table 5.1: Different fuzzing strategies identified for RRC messages in srsLTE wise, such scenarios are ignored. Figure 5.3 shows the steps followed for testing all strategies identified. It follows the pseudo code of Observer (refer algorithm 2). For repeated ping requests, srsUE needs to receive an IP address from srsEPC. This allocation can happen only with initial AS activation where srsEPC authenticates and 50 CHAPTER 5. EVALUATION

1 2 3 Select RRC Identify fuzz Create fuzz parameters msg to fuzz strategies for fuzz strategy

Next fuzzing 4 19 Tried all 18 strategy Create directory and log files fuzzing strategies END fuzzing END strategy 5 seed set to 0 No 8/9 7 seed < Start Yes 6 RAND seed++ srsLTE _MAX

9/8 10 11 Turn fuzzer RRC Yes Ping EPC from ON IDLE UE n times

No 17 No 16 12 No UE Wait for connection If SUT response complete No crash 13 Yes Yes Track fuzz strategy seed, ping_count 14 15 Turn fuzzer kill all OFF

Figure 5.3: Automated toolchain for continuous testing (dashed lines indicate fuzzing during initial AS activation). authorizes srsUE node. With this in consideration, the testing process does not fuzz the first RRC messages being sent for initial AS activation (step 8 in the figure). For later RRC messages, fuzzing can begin by turning on the adaptive fuzzer after initial AS activation. When the number of ping requests exceed proposed limit, the testing moves on to next seed. Similarly, after all seed values are tried, the testing moves to next strategy. Some fields and RRC messages are not part of every handshake. For example, randomValue in RRCConnectionRequest is sent when there is no security and network context at UE. randomValue is useful during initial AS activation of UE in the network. Similarly, the RRC message ulInformationTransfer is also sent only during initial NAS setup. The fuzzer is turned on in such cases before starting any srsLTE processes (as indicated by dashed lines in Figure 5.3). To maximize number of RRC messages fuzzed in such instances, CHAPTER 5. EVALUATION 51

1 2 3 Identify fuzz parameters, seed, Set fuzz parameters, path Set replay_crash_msg fuzz iteration from test logs of binary in config file to TRUE

6/5 5/6 4 Turn fuzzer Start Set seed, fuzz iteration ON srsLTE in config file

7 8 9 RRC Yes Ping EPC from UE If SUT No IDLE to trigger RRC crash

No 13 11 10 Yes Turn fuzzer TRUE SUT kill all OFF crash

14 12 FALSE SUT END crash

Figure 5.4: Flowchart for replaying RRC messages to verify a TRUE crash (dashed lines indicate fuzzing in initial AS activation). the toolchain lets srsUE try to attempt to connect as many times as possible by sending same RRC message types.

5.5 Filtering out false positives

The observer could detect untimely crashes and other unexpected behavior of SUT through unresponsive nodes or printing of crash message in logs. Some of the crashes and unexpected behavior could be because of how the test bed is setup or other unknown reasons. Such instances could be falsely identified as a vulnerability in the SUT (here srsLTE). Hence to filter such instances and recognize truly positive vulnerability, a tester can use flowchart provided in Figure 5.4 to replay the fuzzed message responsible for the classification. It shows different steps involved while replaying a specific binary file of the fuzzed RRC message. Also, the naming convention for fuzzed message binaries (temp___.bin) helps in identifying each binary responsible for either false or true positive. Similar to continuous testing toolchain, the RRC messages involved in initial AS activation are highlighted with dashed line in Figure 5.4. For such cases, the adaptive fuzzer is turned on before initial AS activation to send 52 CHAPTER 5. EVALUATION

the fuzzed message binary ﬁle. For verifying that a message resulted in false positive it is replayed multiple times to ensure a reliable true positive and a potential vulnerability.

5.6 Summary

This chapter identified tools to evaluate the adaptive fuzzer developed in this thesis. With steps provided to integrate the adaptive fuzzer with srsLTE, the tests can be easily recreated by any users. Various fuzzing strategies are identified for testing srsENB and srsEPC across different RRC messages. To collect the results by observer and filtering out false positives, automation toolchains were presented for easily reproducible results. Chapter 6

Results and Analysis

This chapter presents results from this thesis work obtained after conducting tests with the adaptive fuzzer on srsLTE. It also presents a speciﬁc message of interest for srsLTE. The eﬀect of fuzzing on srsLTE is measured and presented in section 6.3.

6.1 Results

This thesis work limited the scope of testing RRC to only 3GPP TS 36.331 Re- lease 15 version 4 implemented by srsLTE (even though it can test any release of RRC). For each strategy identified in subsection 4.1.1, the adaptive fuzzer performs fuzzing of selected RRC message with a particular combination of fuzz strategy parameters. The range of seeds used is also limited in testing of srsLTE depending on fuzzing strategy. As all the machines conducting tests use the same 64-bit architecture and the randomization libraries remain deterministic across machines, the results observed are truly reproducible and have been verified by conducting the same tests across different machines. This enables the adaptive fuzzer to be reliable for multiple users and machines conducting the tests. Table 6.1 presents results observed while using the adaptive fuzzer. It contains information related to range of seeds used in fuzzing process of each strategy, running time of test bed to execute the number of test cases sent, time taken to fuzz each diverted message (shown as a range) and the number of messages fuzzed with each strategy. As mentioned earlier, to limit on the total testing time in each strategy, the range of seeds is limited to 0 to 100. For some strategies like fuzzing only one enumerated or an integer with range of 0

53 54 CHAPTER 6. RESULTS AND ANALYSIS

to 4, the testing is limited to seeds 0 to 10. Hence the seeds are limited to 0-10 assuming that the fuzzer would try maximum possible values for establish- mentCause. Although trying the small range does not guarantee all possible values will be tried, by trying seeds from 0 to RAND_MAX, users can maximize the number of messages as well as possible values while fuzzing each field. At the same time, the limit on number of ping requests is set to 100 during the course of evaluation in this thesis. Limits have been put in place due to the limited availability of resources to test and very long expected times to try all possible mutations. As fuzzing is a brute-force testing technique (for example, virtually unlimited combinations for 1000-byte OCTET STRING and 8000-bit BIT STRING), the limits help to ensure measurable results can be obtained during this thesis. At the same time, by measuring the time taken during diversion of message for fuzzing (identified by Time taken to fuzz), the evaluation setup is monitored for any deviation in performance due to the delayed RRC message arrival at SUT. Across all strategies, a total of 44,383 unique fuzzed RRC messages have been sent to srsENB. The tests have been conducted over a cumulative run time of 13 days, 7 hours, and 41 minutes in all four machines combined. As of sending the 44,383 fuzzed messages, no fault or vulnerability was identified in srsLTE’s implementation of eNB (srsENB).

Time Added No. of taken time Fuzzing strategies with RRC to test for ﬁeld names, data types Seeds RRC message PDUs (days, fuzzing and additional used mu- hours, (mil- strategies tated min- lisec- utes) onds) RRCConnection- 0.35- randomValue 507 9:26 0-500 Request 4.33 1 day 0.29- mmec 7575 0-100 4:40 5.32 2 days 0.28- m-TMSI 5787 0-100 4:35 4.09 ng-5G-S-TMSI-Part1 N/A* 0.29- ENUM 112 00:26 0-10 2.68 1 day 0.35- BIT STRING 4787 0-100 21:53 4.03 RRCConnectionSetup- 0.29- INTEGER 110 00:23 0-10 Complete 3.17 continues next page CHAPTER 6. RESULTS AND ANALYSIS 55

0.21- OCTET STRING 107 2:34 0-100 2.05 Append to 0.23- 99 2:31 0-100 dedicatedInfoNAS 1.62 Append to 0.51- dedicatedInfoNAS and 100 2:31 0-100 12.49 include optional fields 1 day 0.64- Include optional fields 1740 0-100 8:48 29.60 Fuzz existing and append to 0.57- 98 2:41 0-100 dedicatedInfoNAS, 3.30 include optional fields INTEGER and OCTET 0.23- 50 1:16 0-50 STRING 2.47 ULInformation- 0.21- OCTET STRING 257 2:58 0-100 Transfer 5.34 Append to 0.30- 437 2:47 0-100 dedicatedInfoNAS 4.92 Append to 0.30- dedicatedInfoNAS and 164 5:47 0-100 6.92 include optional fields 0.24- Include optional fields 156 6:38 0-100 2.60 Fuzz existing and append to 0.34- 256 3:07 0-100 dedicatedInfoNAS, 12.78 include optional fields SecurityMode- 0.26- INTEGER 101 0:23 0-10 Complete 2.65 1 day 0.29- Include Optional fields 6049 0-100 1:30 2.06 UECapability- 0.29- INTEGER 67 0:19 0-10 Information 2.08 0.33- ENUM 72 0:18 0-10 2.03 0.23- OCTET STRING 81 2:28 0-100 3.23 Append to 0.32- ueCapabilityRAT- 6431 20:58 0-100 4.14 Container Append to ueCapabilityRAT- 0.46- 2905 16:40 0-100 Container and include 5.01 optional fields continues next page 56 CHAPTER 6. RESULTS AND ANALYSIS

Fuzz existing and append to 0.41- ueCapabilityRAT- 93 2:31 0-100 3.66 Container, include optional fields 0.35- Include optional fields 3098 19:10 0-100 4.59 0.34- INTEGER and ENUM 1431 6:27 0-50 3.77 0.56- RRCConnection INTEGER 121 0:47 0-10 4.17 Reconfiguration 0.67- Complete Include Optional fields 1592 20:55 0-100 41.14 Notes: N/A* - Not available in the srsLTE evaluation setup Table 6.1: Number of RRC messages from srsLTE fuzzed by the adaptive fuzzer and the range of seed values used

6.2 Crash in EPC

It was observed that one fuzzed RRC message crashed the core network implementation of srsLTE (srsEPC). This has been verified by replaying the message multiple times and across various machines. The message responsible for the crash is created during fuzzing of an existing content in dedicatedInfoNAS field that is being forwarded by ENB to EPC during initial AS activation. On a closer look, the crash is triggered by a safety mechanism of gcc compiler because of buffer overflow in srsEPC. This was identified by analyzing EPC logs, which show the following message in its output - ’*** stack smashing detected ***: terminated’ on crash. In section 4.2 it is mentioned that srsLTE uses part of code from another open-source LTE implementation called openLTE. On digging deeper into the cause for crash, it is identified that the EPC mishandles uplink NAS transport message sent from srsENB (for this dedicatedInfoNAS value). The lines of code used by srsLTE for NAS message handling are also found in openLTE. Hence it is an assumption that even openLTE’s LTE implementation would crash on sending the byte sequence identified here. On further examination, by sending the same dedicatedInfoNAS to openLTE’s base station implementation (LTE_fdd_enodeb), the base station is crashing with the same output message (’*** stack smashing detected ***: terminated’). openLTE is a lightweight LTE implementation with LTE_fdd_enodeb fulfilling both a CHAPTER 6. RESULTS AND ANALYSIS 57

base station’s and the core networks functionality. Hence it is assumed that crashing LTE_fdd_enodeb is sufficient to conclude it is the same vulnerability that carried over into srsLTE. Having identified a serious vulnerability in srsLTE, the thesis contributes by disclosing the crash with related information to developers of srsLTE1. openLTE is currently not under active maintenance for immediate rectification. Through Ericsson, for wider disclosure, the vulnerability in both srsLTE and openLTE has been informed to a national CERT. Crashing EPC or core network is a major fault in any telecommunication system as that would bring down the entire or majority of the network. Using such an adaptive fuzzer would lead to early identification of such vulnerabilities and make way for safer telecommunication systems.

6.3 Impact on performance of srsLTE due to fuzzing

0 1 2 3 4 5 milliseconds

Figure 6.1: Boxplot distribution of measured latency for 44,383 fuzzed uplink RRC messages.

1To the knowledge of the author, srsLTE is yet to rectify the vulnerability 58 CHAPTER 6. RESULTS AND ANALYSIS

Figure 6.1 presents the distribution of time measured for fuzzing of uplink messages. Most messages when fuzzed have taken just 3.1 milliseconds on average and do not aﬀect the performance of SUT and srsLTE in any way due to the delayed RRC message delivery. The time taken is measured from the instance of uplink message creation by srsUE to the point before sending the fuzzed message by srsLTE. With a few exceptions, values lie in the boxplot shown. Also, according to Clause 11.2 of 3GPP TS 36.331, RRC messages conform to timing requirements during RRC procedures. As the adaptive fuzzer created diversion falls below the timing requirements for most fuzzed messages, it can be assumed that when integrated with existing LTE systems, the message is likely to be processed by lower layers for transportation.

6.4 Summary

This chapter presented results from various tests conducted using the adaptive fuzzer developed in this thesis. It also analyzed the crash identified by Observer in srsLTE (an open-source LTE implementation) and classified it as a true vulnerability. In addition, the effect in performance to srsLTE due to fuzzing is monitored by measuring the time taken to fuzz each message while performing the test. Chapter 7

Conclusions and Future Work

In this thesis a new methodology is proposed to test telecommunication networks and one of its protocol (RRC). This helps achieve secure and reliable communication infrastructure. With increasing dependence on mobiles for internet and call traﬃc, it is important for the telecommunication operator side infrastructure to be robust and reliable in the event of attacks. Security testing of core network and radio base stations help in achieving the trusted resources mobile devices interact with frequently. In the next generation of telecommunication networks (5G) there is a need for high uptime or availability of the system and needs rigorous testing of the equipment before deployment. This thesis also contributes by identifying a previously unidentiﬁed vulnerability in srsLTE and openLTE (two open-source LTE implementations).

7.1 Conclusions

Fuzzing allows testing of software and network protocols alike by mimicking an expected message. To plug the research the gap of an adaptive fuzzer to work with any version of RRC specifications, a mutation based fuzzing tool based on ASN.1 language is developed in this thesis. It can test any RRC network protocol’s implementation as well as test telecom network components like base stations and core network. 3GPP specifies the structure and types of contents in any RRC protocol message through 3GPP specifications released often that must be followed by developers and manufacturers of telecom equipment. The tool is built over asn1c, an open-source parser for ASN.1 definition that also provides encoders and decoders for various ASN.1 encoding rules. It ex-

59 60 CHAPTER 7. CONCLUSIONS AND FUTURE WORK

tracts knowledge regarding 3GPP specifications (provided it is sent in ASN.1 format) and identifies underlying fields, structures in an ongoing RRC message. At the same time this tool can adapt to any version of 3GPP specification considering the continuous evolution in standards from 3GPP for 5G and LTE. A specific implementation of RRC in LTE communication by srsLTE’s testbed was evaluated using the adaptive fuzzer with various fuzzing strategies. In each strategy multiple fuzzed RRC messages are sent and tracked for the response in SUT, here srsENB and srsEPC. With srsLTE, the following uplink RRC messages were fuzzed - RRCConnectionRequest, RRCConnec- tionSetupComplete, SecurityModeComplete, ULInformationTransfer, UECa- pabilityInformation and RRCConnectionReconfigurationComplete. In total 44,383 mutated messages were sent to SUT to test it under the malformed input. An observer that suits srsLTE’s nodes was implemented to monitor the response of SUT under each fuzzed message. One such fuzzed RRC message caused a crash in the EPC implementation of srsLTE (srsEPC) and openLTE (LTE_fdd_enodeb). The vulnerability was reported to developers of srsLTE for rectification. Because of lack of active maintenance of openLTE and for wider responsible disclosure of the vulnerability, through Ericsson, a national CERT was informed. Ericsson, the host company for this thesis, appreciated the deliverables from this thesis and the testing tool for its capabilities.

7.2 Future Work

Given the limited amount of time, resources for a thesis work and quite large fuzzing space for any network protocol, this thesis tested only a part of the possible fuzzing space for RRC protocol. By running it for longer periods with dedicated hardware, one could try all paths possible by this mutation based adaptive fuzzer and identify other vulnerabilities in LTE & 5G implementations, and possibly the protocol specifications. Fuzz space reduction techniques could be used for testing with specific strategies while fuzzing any RRC message (similar to the techniques employed by AFL). The strategies can consist of trying corner cases, flipping specific bits & bytes, reordering of messages in a sequence, etc. The adaptive fuzzer was created in an abstract manner, taking into consideration only the generic appearance of a protocol message using ASN.1. This CHAPTER 7. CONCLUSIONS AND FUTURE WORK 61

level of abstraction with ASN.1 allows easy adaptation to other network protocols using ASN.1 as its description language. With minor modifications to software, the adaptive fuzzer can begin testing of any version of the network protocol with minimal effort from the users. The observer only monitors logs generated by srsLTE for identifying errors. Additional methods like monitoring of system resources (memory, CPU) could be added in future work that provide new insights. Another direction could be to add knowledge related to NAS messages tunneled through RRC. This knowledge could be in relation to NAS procedures and its messages. As the adaptive fuzzer is created using ASN.1 language, it can be modified to test UEs in downlink as well. Detecting vulnerabilities also help in reducing potential threats from attackers who try to compromise networks and software in general. Having such an adaptive fuzzer allows product owners to produce reliable and robust equipment that are used across the world. References

[1] John Moteff, Claudia Copeland, and John Fischer. “Critical Infrastruc- tures: What Makes an Infrastructure Critical?” In: Library of Congress Washington DC Congressional Research Service. 2003. [2] “Communication from the European commission to the council, the Eu- ropean parliament, the economic and social committee and committee of the regions”. In: Science and Engineering Ethics 8 (2002), pp. 113– 117. [3] Jim Gray and Daniel P. Siewiorek. “High-availability computer systems”. In: Computer 24.9 (1991), pp. 39–48. [4] Peter Linder. How cloud and networks achieve 99.999% availability in different ways. Available at https://www.ericsson.com/en/ blog / 2016 / 9 / how - cloud - and - networks - achieve - 99.999-availability-in-different-ways. The Ericsson Blog, 2016. [5] Tomas Novickis, Erik Poll, and Kadir Altan. “Protocol state fuzzing of an OpenVPN”. PhD thesis. MS thesis, Faculty of Science Master Kerckhoffs Computer Security, Radboud University, 2016. [6] Congxi Song et al. “SPFuzz: A Hierarchical Scheduling Framework for Stateful Network Protocol Fuzzing”. In: IEEE Access 7 (2019), pp. 18490– 18499. [7] Serge Gorbunov and Arnold Rosenbloom. “AutoFuzz: Automated Net- work Protocol Fuzzing Framework”. In: IJCSNS 10.8 (2010), p. 239. [8] Google. OSS-Fuzz. Available at https://google.github.io/ oss-fuzz. [9] William Johansson et al. “T-Fuzz: Model-Based Fuzzing for Robust- ness Testing of Telecommunication Protocols”. In: 2014 IEEE Seventh International Conference on Software Testing, Verification and Valida- tion. IEEE. 2014, pp. 323–332.

62 REFERENCES 63

[10] Luo Xu, Ji Wu, and Chao Liu. “T3FAH: A TTCN-3 Based Fuzzer with Attack Heuristics”. In: 2009 WRI World Congress on Computer Science and Information Engineering. Vol. 7. IEEE. 2009, pp. 744–749. [11] ITU. Key ICT indicators for developed and developing countries and the world (totals and penetration rates). Available at https://www. itu.int/en/ITU-D/Statistics/Documents/statistics/ 2019/ITU_Key_2005- 2019_ICT_data_with%20LDCs_ 28Oct2019_Final.xls. Oct. 2019. [12] Arne Holst. Total data volume worldwide 2010-2024. Available at https: //www.statista.com/statistics/871513/worldwide- data-created. Dec. 2020. [13] 3GPP. 3GPP Releases. Available at https://www.3gpp.org/ specifications/67-releases. [14] Electronics Notes. 3GPP Speciﬁcation Release Numbers. Available at https : / / www . electronics - notes . com / articles / connectivity/3gpp/standards-releases.php. [15] 3GPP. 3GPP Release-16. Available at https://www.3gpp.org/ release-16. [16] 3GPP. NR; NR and NG-RAN Overall Description; Stage 2. TS 38.300. Available at https://portal.3gpp.org/desktopmodules/ Specifications/SpecificationDetails.aspx?specificationId= 3191. [17] John D Day and Hubert Zimmermann. “The OSI reference model”. In: Proceedings of the IEEE 71.12 (1983), pp. 1334–1340. [18] 3GPP. NR; Physical channels and modulation. TS 38.211. Available at https://portal.3gpp.org/desktopmodules/Specifications/ SpecificationDetails.aspx?specificationId=3213. [19] Erik Dahlman, Stefan Parkvall, and Johan Skold. 5G NR: The Next Gen- eration Wireless Access Technology. Academic Press, 2020. [20] 3GPP. NR; Services provided by the physical layer. TS 38.202. Avail- able at https : / / portal . 3gpp . org / desktopmodules / Specifications/SpecificationDetails.aspx?specificationId= 3212. 64 REFERENCES

[21] 3GPP. NR; Medium Access Control (MAC) protocol specification. TS 38.321. Available at https://portal.3gpp.org/desktopmodules/ Specifications/SpecificationDetails.aspx?specificationId= 3194. [22] 3GPP. NR; Radio Link Control (RLC) protocol specification. TS 38.322. Available at https://portal.3gpp.org/desktopmodules/ Specifications/SpecificationDetails.aspx?specificationId= 3195. [23] 3GPP. NR; Packet Data Convergence Protocol (PDCP) specification. TS 38.323. Available at https://portal.3gpp.org/desktopmodules/ Specifications/SpecificationDetails.aspx?specificationId= 3196. [24] 3GPP. E-UTRA and NR; Service Data Adaptation Protocol (SDAP) specification. TS 37.324. Available at https://portal.3gpp. org/desktopmodules/Specifications/SpecificationDetails. aspx?specificationId=3282. [25] 3GPP. NR; Radio Resource Control (RRC); Protocol specification. TS 38.331. Available at https://portal.3gpp.org/desktopmodules/ Specifications/SpecificationDetails.aspx?specificationId= 3197. [26] OSS Nokalva. ASN.1 Applications and Standards. Available at https: / / www . oss . com / asn1 / resources / standards - use - asn1.html. [27] Lev Walkin. asn1c: Open Source ASN.1 Compiler. Available at http: //lionet.info/asn1c/compiler.html. [28] Inc. Objective Systems. ASN1C ASN.1 Compiler. Available at https: //www.obj-sys.com/products/asn1c/index.php. [29] ITU. “Recommendation ITU-T X.691 International Standard 8825-2: Information technology – ASN.1 encoding rules: Specification of Packed Encoding Rules (PER)”. In: (Aug. 2015). [30] Jun Li, Bodong Zhao, and Chao Zhang. “Fuzzing: a survey”. In: Cyber- security 1.1 (2018), pp. 1–13. [31] Ari Takanen. “Fuzzing : the Past , the Present and the Future”. In: Actes du 7ème symposium sur la sécurité des technologies de l’information et des communications (SSTIC). 2009, pp. 202–212. REFERENCES 65

[32] Hugo Gascon et al. “Pulsar: Stateful Black-Box Fuzzing of Proprietary Network Protocols”. In: International Conference on Security and Pri- vacy in Communication Systems. Springer. 2015, pp. 330–347. [33] Hyunguk Yoo and Taeshik Shon. “Grammar-based adaptive fuzzing: Evaluation on SCADA modbus protocol”. In: 2016 IEEE International Conference on Smart Grid Communications (SmartGridComm). IEEE. 2016, pp. 557–563. [34] Sang Kil Cha, Maverick Woo, and David Brumley. “Program-Adaptive Mutational Fuzzing”. In: 2015 IEEE Symposium on Security and Pri- vacy. IEEE. 2015, pp. 725–741. [35] Michal Zalewski. American Fuzzy Lop. Available at https://github. com/google/AFL. [36] immunitysec. SPIKE. Available at https://github.com/guilhermeferreira/ spikepp. [37] Sam Hocevar. zzuf - multi-purpose fuzzer. Available at https : / / github.com/samhocevar/zzuf. [38] Joshua Pereyda. boofuzz. Available at https : / / github . com / jtpereyda/boofuzz. [39] OpenRCE. Sulley. Available at https://github.com/OpenRCE/ sulley. [40] Yating Hsu, Guoqiang Shu, and David Lee. “A model-based approach to security ﬂaw detection of network protocol implementations”. In: 2008 IEEE International Conference on Network Protocols. IEEE. 2008, pp. 114–123. [41] Michael Eddington. “Peach fuzzing platform”. In: Peach Fuzzer 34 (2011). [42] Greg Banks et al. “SNOOZE: Toward a Stateful NetwOrk prOtocol fuzZEr”. In: International conference on information security. Springer. 2006, pp. 343–358. [43] Hongil Kim et al. “Touching the Untouchables: Dynamic Security Anal- ysis of the LTE Control Plane”. In: Proceedings of the IEEE Symposium on Security & Privacy (SP). IEEE, May 2019. [44] Defensics Fuzz Testing. Available at https://www.synopsys. com/software- integrity/security- testing/fuzz- testing.html. 66 REFERENCES

[45] P1 Telecom Fuzzer (PTF). Available at https : / / www . p1sec . com/corp/products/p1-telecom-fuzzer-ptf. [46] ITU-T. ASN.1 Project Tools. Available at https://www.itu.int/ en/ITU-T/asn1/Pages/Tools.aspx. [47] Software Radio Systems. srsLTE. Available at https://github. com/srsLTE/srsLTE. [48] openLTE. openLTE. Available at https://sourceforge.net/ projects/openlte. [49] 3GPP. “Evolved Universal Terrestrial Radio Access (E-UTRA); Ra- dio Resource Control (RRC); Protocol specification. TS 36.331”. In: (). Available at https://portal.3gpp.org/desktopmodules/ Specifications/SpecificationDetails.aspx?specificationId= 2440. [50] Mark Lindner. libconfig - C/C++ library for processing configuration files. Available at https://github.com/hyperrealm/libconfig. [51] Ismael Gomez-Miguelez et al. “srsLTE: An open-source platform for LTE evolution and experimentation”. In: Proceedings of the Tenth ACM International Workshop on Wireless Network Testbeds, Experimental Evaluation, and Characterization. 2016, pp. 25–32. [52] OAI. ASN.1 extractor from 3GPP specifications. Available at https: / / gitlab . eurecom . fr / oai / openairinterface5g/ - /blob/master/openair2/RRC/LTE/MESSAGES/asn1c/ ASN1_files/extract_asn1_from_spec.pl. For DIVA

{ "Author1": { "name": "Srinath Potnuru"}, "Degree": {"Educational program": "Master’s in Computer Science and Engineering with specialization in ICT Innovation, 120 credits"}, "Title": { "Main title": "Fuzzing Radio Resource Control messages in 5G and LTE systems", "Subtitle": "To test telecommunication systems with ASN.1 grammar rules based adaptive fuzzer", "Language": "eng" }, "Alternative title": { "Main title": "Fuzzing Radio Resource Control-meddelanden i 5G- och LTE-system", "Subtitle": "", "Language": "swe" }, "Supervisor1": { "name": "Prajwol Kumar Nakarmi" }, "Supervisor2": { "name": "Ezzeldin Zaki" }, "Examiner": { "name": "György Dán", "organisation": {"L1": "School of Electrical Engineering and Computer Science" } }, "Cooperation": { "Partner_name": "Ericsson AB"}, "Other information": { "Year": "2021", "Number of pages": "xvi,67"} }

TRITA-EECS-EX-2021:125