Extracted Text

Touching the Untouchables: Dynamic Security
Analysis of the LTE Control Plane
Hongil Kim
KAIST
hongilk@kaist.ac.kr
Jiho Lee
KAIST
jiholee@kaist.ac.kr
Eunkyu Lee
KAIST
ekleez@kaist.ac.kr
Yongdae Kim
KAIST
yongdaek@kaist.ac.kr
Abstract—This paper presents our extensive investigation
of the security aspects of control plane procedures based on
dynamic testing of the control components in operational Long
Term Evolution (LTE) networks. For dynamic testing in LTE
networks, we implemented a semi-automated testing tool, named
LTEFuzz, by using open-source LTE software over which the
user has full control. We systematically generated test cases by
dening three basic security properties by closely analyzing the
standards. Based on the security property, LTEFuzz generates
and sends the test cases to a target network, and classies the
problematic behavior by only monitoring the device-side logs.
Accordingly, we uncovered 36 vulnerabilities, which have not
been disclosed previously. These ndings are categorized into ve
types: Improper handling of (1) unprotected initial procedure,
(2) crafted plain requests, (3) messages with invalid integrity
protection, (4) replayed messages, and (5) security procedure
bypass. We conrmed those vulnerabilities by demonstrating
proof-of-concept attacks against operational LTE networks. The
impact of the attacks is to either deny LTE services to legitimate
users, spoof SMS messages, or eavesdrop/manipulate user data
trafc. Precise root cause analysis and potential countermeasures
to address these problems are presented as well. Cellular carriers
were partially involved to maintain ethical standards as well as
verify our ndings in commercial LTE networks.
I. INTRODUCTION
Long Term Evolution (LTE) is the most advanced telecom-
munication technology thus far. It not only provides faster data
transmission with low latency but also ensures high reliability
and robustness against unexpected failures compared to older
generation networks such as Global System for Mobile com-
munication (GSM), and Universal Mobile Telecommunication
System (UMTS). Mobile network operators are aggressively
deploying LTE infrastructure; as of 2018, 600 carriers in 200
countries have deployed LTE networks, having more than 3.2
billion subscribers worldwide [1], [2].
In addition to facilitating traditional telecommunication ser-
vices such as data and voice call, LTE is considered a key en-
abler for providing always-on mobile connectivity in both the
emerging industries (e.g., autonomous vehicles and the Internet
of Things) and nation-wide communication infrastructure (e.g.,
Public Safety LTE and LTE-R for railway communication).
Typically, these applications are safety-critical and require high
availability and robustness. This means that users could face
a signicant threat to their safety if these applications were to
malfunction by the accidental disconnection of LTE services.
It is therefore pivotal to investigate the potential threats to the
LTE service procedures that can cause unexpected failures as
a result of accidents or adversaries.
The 3rd Generation Partnership Project (3GPP), a de facto
standard for LTE, denes the behavior of all network compo-
nents including security features, which have been signicantly
improved compared to earlier networks (e.g., stronger encryp-
tion and integrity protection algorithms, mandatory use of
integrity protection in control plane protocols) [3]. Moreover, it
provides conformance test suites for commercial LTE chipsets
to ensure compliance with the specication.
In spite of these efforts to eliminate the risks of unexpected
errors, recent studies have uncovered various security vulner-
abilities in the control plane procedures of LTE networks. For
example, an active adversary can relay an LTE communication
between a mobile device and a network to hijack the location
of the device [4] or redirect the DNS request of the device [5].
Attacks using rogue base stations can either track the location
of a user device or deny the LTE service by exploiting
both device side design aws and implementation bugs [6]–
[8]. However, none of these studies focused on analyzing
network-side problems in operational LTE networks although
vulnerabilities of this nature can inuence a number of their
subscribers once exploited.
Motivated by the fact that the control plane components
in LTE are still under-explored, we investigated potential
problems of the control plane procedures in operational LTE
networks by dynamically analyzing the core network responses
resulting from carefully crafted malicious inputs. In general,
dynamically testing network behavior is challenging because:
¶Exploiting the control plane protocols with a commercial
smartphone is quite difcult. This is because commercial
devices implement the control plane protocols on a baseband
chipset, from which generation of arbitrary messages is dif-
cult.·The deployed carrier networks are closed systems.
Their congurations are proprietary and the control plane logs
are unavailable to devices. Thus, it is difcult to correctly
determine the root causes of the identied problems on the
device side.¸Transmitting signals to an operational network
using an uncertied device may not be allowed depending on
the regulations for carriers and countries.
We overcome these challenges by utilizing open source
LTE implementations [9]–[11] for testing purposes. To this
end, we implemented a semi-automated testing tool, named
LTEFuzz, by using fully controllable LTE open source soft-
ware, which 1) dynamically generates and sends the test cases
to a target network or a device [9], and further, 2) classies
problematic behavior by only inspecting the responses in the
tester and victim device from the target. Second, we collab-
orated with carriers to avoid ethical issues. For each of the

critical test cases, we interviewed carriers to establish whether
it would interfere with the LTE network. Suspicious cases that
could interfere with other users were handled independently.
Regarding the regulations on using licensed bands, our tester
device acts as if it were a single LTE device and executes
test messages individually. Therefore, nearby legitimate users
do not experience any interference, performance degradation,
and failure of their LTE services. In addition, we sent spoofed
messages by using the identity of our LTE phone. Thus, only
our phone might experience the intended failure in case our
test case is accepted by the target networks. Lastly, we reason
out the root causes based on 1) a review of 3GPP standards
and 2) interview with the carriers to conrm our ndings.
To generate the test cases systematically, we rst cre-
ated three security properties by extensively analyzing the
correct behavior of network components and their security
requirements mandated in the 3GPP specications. Using these
security properties, we determined the scope of the target
messages and generated rules for specic test cases. Then,
the test case generator mutated the random inputs among the
datasets of the control plane logs of a commercial network,
which we collected globally for approximately one year. The
reason for only considering the inputs in the commercial
logs is to prevent unexpected crashes in the receiving nodes
due to parsing errors. Total test cases cover 13 messages for
inspecting the behavior of network nodes and 29 messages for
inspecting the behavior of commercial devices.
By conducting tests against the operational network, we
found 51 vulnerabilities (36 new and 15 previously known),
which are mainly caused by the improper handling ofÀ
unprotected initial procedures,Ácrafted plain requests,Â
messages with invalid integrity protection,Ãreplayed mes-
sages, andÄsecurity procedure bypass. We also demonstrate
all the attacks by exploiting the vulnerabilities we found in
the operational network while strictly following the ethics. Our
attacks can¶deny various LTE services to either a target user
or arbitrary users,·spoof control plane messages for privacy
leaks,¸send spoofed Short Message Service (SMS), and¹
eavesdrop and manipulate data communication. A complete
list of vulnerabilities is given in the Table IV in the Appendix.
To summarize, our contributions are as follows:
We propose a systematic approach to expose vulnerabilities
in the control plane procedures of LTE networks. Our method
can examine various security aspects in several control plane
protocols by simply creating concrete security properties and
test cases.
To the best of our knowledge, we are the rst to analyze the
security problems caused by incorrect behavior in the control
plane nodes in commercial networks such asRadio Resource
Control (RRC)andNon Access Stratum (NAS)by executing
crafted uplink test cases in both theRRCand theNASlayer.
We demonstrated that most of our ndings are exploitable
by an adversary who would be able to launch critical attacks
such as the denial of LTE services, spoong of both control
and data plane messages, eavesdropping user data trafc, and
conducting phishing attacks on legitimate users.
The remainder of the paper is organized as follows. Sec-
tion II presents an overview of LTE technology with the
network architecture and key control plane procedures. In4G Core Network
S-GW
HSS
MME Billing
Domain
Internet
IMS
4G Access Network
eNB
P-GW
Tracking
Area
Cell
UE
Fig. 1. LTE network architecture
Section III, we introduce our approach to systematically nd
existing vulnerabilities in commercial network environments.
Section IV provides a detailed implementation and experimen-
tal setup of our proposed approach. We present the results of
our test and root cause analysis of each nding in Section V.
The attacks that exploit the identied vulnerabilities are pre-
sented in Sections VI, VII, and VIII. Section IX discusses
potential countermeasures and Section X presents related work.
We conclude our paper and present future work in Section XI.
II. BACKGROUND
This section presents the basic concepts of standard LTE
technology along with network architecture and essential con-
trol plane procedures [12]–[19].
A. LTE network architecture
Fig. 1 illustrates the LTE network architecture, which
consists of User Equipment (UE), evolved Node B (eNB), and
Evolved Packet Core (EPC) components.
UErefers to a mobile device, which can provide a legitimate
user with subscribed services such as data and voice call by
connecting to a base station. The UE is uniquely identied by
an International Mobile Station Equipment Identity (IMEI).
One distinctive feature of the UE is the use of a Universal
Subscriber Identity Module (USIM), a smart card that can be
physically inserted into the UE, which includes the subscriber
identier known as the International Mobile Subscriber Iden-
tity (IMSI), cryptographic keys, and algorithms.
AneNBis the Base Transceiver Station (BTS) in LTE, which
enables the UE to establish a wireless connection to the LTE
network. A typical eNB has a Baseband Unit (BBU) that
is responsible for processing the baseband signals, and it is
connected to multiple Remote Radio Units (RRUs), which
directly process the transmission and reception of RF signals.
Each RRU covers a sector (also known as a cell), thus, one
eNB can cover multiple cell sites as shown in Fig. 1
1
. The
eNB is connected to a Mobility Management Entity (MME)
for control-plane communication and 4G Gateways (GWs) for
both control-plane and user-plane data transmission.
TheMMEis the key control-node in the LTE network. It
authenticates the UE and manages the mobility status of
subscribers and Evolved Packet System (EPS) bearers. The
cryptographic keys for authenticating and protecting the UE
are contained in the Home Subscriber Server (HSS). The
MME performs UE authentication through an authentication
protocol known as Evolved Packet System-Authentication and
Key Agreement (EPS-AKA) with the key information received
from the HSS. The MME is also involved in the activa-
tion/deactivation process of the EPS bearer, a logical tunnel
1
The number of cells in one eNB can range from 1 to 256 in the specication
and, in practice, this depends on the operators' cell planning.
2

RRC
Radio setup
1
RRC Connection request
RRC Connection setup
NAS Authentication request/response
NAS Attach accept/complete
NAS Security mode command/complete
RRC Security mode command/complete
RRC Connection complete +NAS Attach request
(Random or UE’s S-TMSI)
(UE’s IMSI, GUTI or IMEI)
Authentication vector
Encryption/Integrity algorithm: EEAx/EIAx
RRC Connection reconf.
6
5
Signaling/Data radio bearerNew GUTI or reuse old GUTI
RRC
NAS
NAS
S1AP
S1APMME
eNB UE
+
2 3 4 78 Fig. 2. UE attach procedure with our target control plane protocol stack
created during a session between the UE and GW to service
the Internet connection. Thus, it manages user network access
by setting up and terminating the session. User mobility is
managed by tracking each user's states, stored in the MME
(e.g., whether the UE is attached to the network) and it tracks
the location of the UE in cell units. These cells are grouped
into a Tracking Area (TA).
4G GWsconsist of two types of LTE gateways: a Serving
Gateway (S-GW) and a PDN Gateway (P-GW). These GWs
ensure mobility of the UE and provide Internet service. The
S-GW becomes an anchor point when the UE moves from one
base station to another, which is known as handover, and the
P-GW allocates the IP addresses and manages the accounting
data of the UE. It also connects the UE to the Internet.
B. LTE service procedures
1) UE attach procedure:The initial procedure whereby the
UE attaches to the network (as shown in Fig. 2) is related with
both connecting the RAN (eNB) and the EPC network (MME).
The UE has to establish a radio connection with the eNB rst,
after which it attaches to the EPC network for a full connection
to the Internet through the LTE network.
Connection between the UE and eNB.When the UE is turned
on, it rst nds a suitable cell by listening to broadcasting mes-
sages from nearby base stations according to the settings (e.g.,
operator specic codes, LTE bands, and channels) congured
in the USIM card and the device modem. Once the UE nds a
suitable cell, (1) it initiates the Random Access (RA) procedure
to obtain uplink resource allocation and timing information.
Then, it saves the assigned identity known as a Temporary Cell
Radio Network Temporary Identier (Temporary C-RNTI)
from the selected cell. With this Temporary C-RNTI and the
uplink assignments, (2) the UE attempts to establish aRadio
Resource Control (RRC) Connectionby transmitting anRRC
Connection request. (3) On receiving the request, the eNB
replies with theRRC Connection setupincluding information
about the dedicated radio resource allocation and the C-RNTI
value to be used to distinguish the UE for subsequent radio
communication. (4) Lastly, the UE completes the connection
setup by sending anRRC Connection setup completemes-
sage to the cell. Once all these steps have been performed,
the UE is synchronized with the cell in both the uplink and
downlink. In addition, both the UE and eNB change their
RRCstate fromIDLEtoCONNECTEDas dened in the
3GPP standard [19]. In theRRC CONNECTEDstate, the UE
communicates with the connected cell using theRRCprotocol
for control-plane procedures. In Section V-A, we show that
no security measures are typically adopted in these initial
procedures, thereby causing serious problems in target eNBs.
Connection between UE and MME.Once the UE is success-
fully connected to a nearby eNB, it has to attach to the EPC
network to obtain LTE services. First, (4) the UE piggybacks
theNAS Attach requestto theRRC Connection completeand
sends it to an MME. Upon receiving this message, (5) the
MME starts the Authentication and Key Agreement (AKA)
procedure by replying to theNAS Authentication request
from the UE with anAuthentication vectorgenerated from the
HSS. The UE then authenticates the MME through the contents
in theNAS Authentication requestand replies by sending
anNAS Authentication responseto the MME. At this stage,
both the UE and the MME are mutually authenticated. Next, in
terms of key agreement, (6) the MME selects the encryption
and integrity protection algorithms to use, and sends aNAS
Security mode commandto the UE to inform it about the
selected algorithms. Upon the receipt of this message, the
UE generates security keys for theNASlayer. Likewise,
(7) the eNB proceedsRRC Security mode commandto inform
the security algorithms forRRClayer and user plane data
security. After these steps, all the control plane messages
that should be protected according to the standards [15], [19]
are encrypted and integrity protected using the negotiated
security algorithms. Lastly, after optional congurations are
exchanged in theNASandRRClayer, (8) the MME allocates
a Globally Unique Temporary Identity (GUTI)
2
to substitute
the permanent identity (IMSI in LTE) and sends the GUTI
and other connection information by transmitting anAttach
acceptto the UE. The attach procedure is nally completed
when the UE sends anAttach completemessage to the MME.
2) UE mobility management:As shown in Fig. 1, each
MME manages its own Tracking Areas (TAs), each of which
is identied by a Tracking Area Code (TAC). Each TA contains
several eNBs, which operate several cells to efciently cover
the geographical regions with no signal interference according
to the operating policy of the carrier. Upon arrival of an
incoming service request to a specic UE, the MME rst
checks whether the UE isRRC CONNECTEDorRRC IDLE. If
the UE is in theRRC IDLEstate, the MME has to wake up the
UE to make theRRC Connectionand the other radio bearers
of data trafc. This procedure is known asPagingin LTE
terminology. As the MME only has information about the TA
that previously served the UE, thePagingmessage is broadcast
to all the eNBs in that TA. If the UE is not found in the
particular TA, the MME can broadcast thePagingto the other
TAs. Note that the specicPagingpolicy to nd UEs might
be different across carriers depending on the relative priority
allocated to QoS, the signaling load, and other operating issues.
III. THEPROPOSEDAPPROACH
This section presents LTEFuzz, the proposed approach
to systematically conduct dynamic security analysis in op-
erational LTE networks in a semi-automated way. LTEFuzz
consists of three main steps (as shown in Fig. 3):
(1) Extracting security properties:First, we extensively
analyze the LTE standards of the control plane procedures by
2
The GUTI value consists of MME group id and S-TMSI.
3

2.Generating
& Executing test cases
3.Classifying
problematic behavior and construct attack scenar ios
eNB
Operational LTE network
MME
Commercial devices
Tester
Decision tree
Case 1 Case 2 Case 4Case 3
Attack scenario 1 Attack scenario 2 Attack scenario 3
Problematic
behavior
Test results
(UE side logs)
Test case
Properties
Commercial logs
Test cases
P1
P2
P3
Key agreement
Authentication
Invalid Seq
Plain by
adversary
Plain by
design Invalid MAC
1.Extracting
security pro
perties Fig. 3. Overview of LTEFuzz
focusing on the security aspects. Based on the analysis, we
create three security properties the network and the mobile
devices need to follow to ensure they are protected against
unknown security threats.
(2) Generating test cases:Next, we generate test cases to
identify situations in which the target control plane component
violates the security properties. The test cases are generated
based on the specied rules of target protocol messages and
its elds for each property.
(3) Classifying problematic behavior:When executing the
test cases, we need to determine which responses and state
changes on the side of the UE are considered as problematic
behavior. To this end, we build a simple decision tree logic
to classify the problematic cases. Our model only considers
the control plane logs and states on the UE side when the test
case is executed. This model, therefore, enables LTEFuzz to
identify problematic cases in an automatic way.
The remainder of this section considers each of these steps.
A. Extracting security properties from standards
A thorough analysis of the specications regarding the
control plane procedures and security requirements enabled
us to identify potential security holes that might cause the
condentiality and integrity protection of control plane pro-
cedures be circumvented depending on the implementation
and conguration policies of carriers. First, initial procedures
before establishing a security context might be exploited by
adversaries who are able to eavesdrop and manipulate LTE sig-
nals. Second, quite a few exceptional situations exist in which
the receiving entity would accept the received control plane
message without integrity protection (Section 4.4.4 in [15]
and Appendix 6 in [19]). Third, although the specication
adopts counters for the control plane protocol (such as NAS
and RRC), it species the use of a sequence number (partial
bits of the counter) in the received message when verifying the
message integrity. Therefore, message replay might be allowed.
From these observations, we created the three basic security
properties listed in Table I, each of which focuses on the ability
of the responsible entities to correctly respond to malicious
behavior by an adversary. We assume that the adversary has
minimal privilege: the adversary neither owns valid keys to
register with the LTE network nor do they have information
about other legitimate users' keys. In addition, as each property
focuses on different security aspects (i.e., incorrect handling of
unprotected procedures, invalid security protected messages,
and mandatory AKA procedures), the test scenarios and the
rules of selecting target messages vary from one property to
another. Note that, when considering the security properties,
we only targeted theNASand theRRCprotocol among the
various control plane protocols because (1) these protocols
are used to perform critical control plane procedures between
the UE and the network (e.g., UE attach procedure, mobility
management, and authentication), (2) we were able to capture
and analyze these procedures at the UE, and (3) the identied
vulnerabilities in these protocols directly affect both the UE
and the network.
Each of these properties is explained in more detail below.
1) Property 1:It conrms whether the receiving entity (the
eNB or MME for an uplink and the UE for a downlink)
appropriately handles unexpected inputs when an adversary
sends crafted plain messages during the initial procedures.
To validate this property, we consider two situations when
selecting the target messages: (1) crafted plain messages that
can be sent before security is activated, and (2) messages
that should not be sent unprotected after security activation
according to the standard. For the rst case, we mainly inspect
the potential threats of initial plain messages that cannot be
protected by the nature of the symmetric key cryptography of
LTE. For these unprotected messages, it is hard to distinguish
whether the received message is sent from the adversary
or a benign user. On the other hand, the purpose of the
second situation is to inspect whether the deployed cellular
components are correctly implemented to reject or discard
invalid plain messages that do not comply with the standard.
Messages transmitted after security activation usually adhere
to security critical procedures. Thus, an adversary might affect
the connection state of a UE or expose the private informa-
tion of the UE if the receiving entities incorrectly handle
these security-protected messages. Here we assume that the
adversary neither subscribes to the particular mobile phone
service nor do they have the security keys of the other UE.
Therefore, the adversary would be able to create and send
plain messages with arbitrary contents, but these messages
are not valid ones. During the test, the adversary acts as a
malicious UEwhen investigating the behavior of the eNB and
MME (uplink direction) and as arogue LTE networkwhen
investigating UE behavior (downlink direction).
Example cases.An example of a message representing the rst
situation is anRRC Connection request. Because the initial
RRC Connectionprocedure is not protected by design, an
adversary can spoof any contents while establishing theRRC
Connection. Victim eNBs without proper security measures
would accept these fabricated messages. Another example to
illustrate the second situation could be a plainNAS Attach
requestspoofed with the victim's GUTI. In normal cases,
when UE attempts to perform re-registration with their pre-
vious cryptographic key information (known as thesecurity
contextin 3GPP) and GUTI, an integrity protectedNAS Attach
requestis sent. Upon receiving the message, the MME
allows UE registration without performing an AKA procedure
because the UE is already authenticated by its valid integrity
protected message. Thus, if the MME does not correctly check
whether the received message has to be security protected, an
adversary may disconnect the victim's existing connection by
sending a plainNAS Attach requestspoofed with the victim's
GUTI. A detailed analysis of the consequences of these two
situations is provided in Section V-A and V-B, respectively.
2) Property 2:It validates whether the receiver appro-
priately handles unexpected messages that are incorrectly
4

TABLE I. S ECURITY PROPERTIES FOR SYSTEMATIC SECURITY TESTING
Security property Target procedures/messages Example
P1Invalid plain messages should be properly handled
Messages that are allowed to be sent in plaintextRRC Connection request, IMSI Attach request
Messages that are not allowed to be sent in plaintextGUTI Attach request, Uplink NAS transport
P2Invalid security protected messages should be properly handled
Messages with invalid integrity protection
PDN disconnect request, Service request
Messages with invalid sequence number
P3Mandatory security procedures should not be bypassed
Mutual authentication procedure Authentication request
Key agreement procedure NAS/RRC Security mode command
encapsulated with a security header. According to the spec-
ication [15], allNASmessages after the AKA procedure
should be both encrypted and integrity protected except some
messages, such as anAttach request, aTAU request, and
aSecurity mode command, all of which are only integrity
protected. To this end, when a UE sends anNASmessage after
the AKA procedure, it encrypts the plainNASmessages rst
and then calculates the Message Authentication Code (MAC)
for integrity protection (shown in Fig. 10). We demonstrate
this property by investigating two specic cases to determine
whether the receiving entity appropriately veries (1) the in-
tegrity of the security protected messages and (2) the sequence
number, which consists of the eight least signicant bits of the
32-bit counter value synchronized between the sending and
receiving entities. Intuitively, if the receiving entity does not
verify the integrity of the message, an adversary can spoof
any unencrypted messages. Further, if the sequence number
is not thoroughly veried, the adversary can launch a replay
attack using security-protected messages that were previously
captured from victim UE. Similar to property 1, because the
adversary does not have any cryptographic keys to generate
valid messages, they send invalid messages after establishing
a connection to the eNB. The target messages for each of
the cases constitute every possible message that should be
protected after security activation.
Example cases.An example relating to the rst case could
beNAS Uplink NAS transport, which is used for SMS within
the carriers providingSMS over NAS. If an MME does not
properly verify the integrity of this message, the adversary
can exploit it for an SMS phishing attack by spoong the
contents of theNAS Uplink NAS transportmessage. Another
example representative of the second case is anNAS PDN
disconnect request. The purpose of this message is to release
the establishedPacket Data Network (PDN) Connection; in
particular, when the user turns off their device or switches off
the data service. An adversary could send this message to the
network by pretending to be the victim UE, and the network
would accept this replayed message if it does not correctly
verify the sequence number specied in the message. This
could lead to selective denial of service of legitimate users.
3) Property 3:It conrms whether the security procedures
specied in the 3GPP standards [15], [19] can be bypassed
by malicious UE or a network. The LTE standard adopts
EPS-AKA for mutual authentication between the UE and the
network for protection of both the control and data planes.
This includes theNAS Authenticationprocedure based on
the challenge-response mechanism and theSecurity mode
commandin both theRRCandNASlayers, which are session
key agreement procedures for control plane and data plane
condentiality and integrity. Three types of approaches are
available to inspect whether these security procedures could
be bypassed. The rst is to perform a security analysis of
the cryptographic algorithms adopted in the LTE standard.
However, this situation is out of the scope of this paper.
Second, one could consider situations in which an adversary
manipulates the encryption and integrity protection algorithms
selected in theRRC/NAS Security mode commandand security
header type inNAS protected messages. This was previously
studied [20], but the authors found vulnerabilities in only one
commercial modem. The last situation involves omitting parts
of the mandatory security procedures. If the device allows this
to occur, arogue LTE networkwithout cryptographic keys for
the legitimate devices could even provide manipulated services
without condentiality and integrity protection. Despite the
possibility of these situations causing serious threats if ex-
ploited, the consequences have not yet been investigated and
publicly disclosed. Thus, we limit the scope of this security
property to validate whether the UE correctly handles situa-
tions in which a malicious LTE network omits the mandatory
security procedures such as anAuthentication requestand
aSecurity mode commandin both theRRCandNASlayers.
Example case.An example could be to disregard theNAS
Authentication requestto enable an adversary to continue
following service procedures without authentication and key
agreement, both of which are mandatory procedures [15], [19].
B. Generating test cases for each property
Although we chose the target messages for each property,
several test cases exist if we consider the inputs for all possible
eld values in each message. For example, the generation of
test cases for an invalid plainNAS Attach requestto verify
security property 1 would have to consider that it has 24
elds including an optional one and the available length in this
message could be at least 16 bytes. Obviously, testing all these
possibilities is expensive. To reduce the number of test cases,
yet carry out a sufcient number to investigate the behavior
of the target entity, LTEFuzz utilizes commercial control plane
message logs. In this regard, we collected various control plane
messages by triggering many functionalities in the baseband
chipset by sending AT commands [21]. We then used this log
to build a database in which to store all the values in the
collected logs for each eld, separated by carriers. Thus, when
the generator creates test cases for carrier A, it selects one of
the possible values marked as carrier A. When generating the
test cases to check sequence number verication (second case
in property 2), we generated all the test cases by capturing
packets on the side of the victim UE. When generating test
cases for initial plain messages (property 1) and messages with
invalid MAC (rst case in property 2), only the mandatory
elds are considered as they are security critical for correct
LTE operation. Note that when the test case message contains
the identity eld of the UE, the current identity of the UE
such as the GUTI or IMSI is included to inspect whether the
receiving entity changes the state of the victim UE.
C. Classifying problematic behavior
When each case is tested, LTEFuzz has to identify which of
these cause problematic behavior in the receiving entity. This
5

Accepted by the
receiving entity?
Cause
de-registration?
Cause
de-registration?
YesNo or unknown
Yes YesNo No or unknown
Case 1. Problematic Case 2. Problematic Case 3. ProblematicCase 4. Benign
Denial of Service Message spoofing Denial of Service
Target protocol: RRC or NAS
Victim’s state: Conn. or Idle
Direction: UL or DL
…
Test case Fig. 4. Decision tree based logic for classifying problematic behavior
can easily be achieved if the operation logs of the receiving en-
tity are available to monitor. However, obtaining the operation
logs of cellular networks is not possible for researchers without
support from carriers or equipment vendors. To overcome
this limitation, LTEFuzz classies problematic behavior by
monitoring only the logs in the UE based on a simple decision
tree as shown in Fig. 4. This logic has two decision phases:
(1) whether the test case (invalid message) is accepted, and (2)
whether the test case causes disconnection of the victim UE.
For the rst decision phase, we dene the expected response
when the receiving entity accepts each test case based on the
3GPP standard. Then, LTEFuzz checks whether the expected
response is received by the UE when each test case is sent. For
instance, if a test case is an invalidNAS Identity request, the
expected response should be anNAS Identity responsewith
the desired message contents. Once this expected response
is received, LTEFuzz considers the test case to be accepted
and classies the test case as being abnormal because a test
case with invalid input should not be accepted. At the second
decision phase, it further examines whether the victim UE is
disconnected from the network in response to a test case. If
yes, it is classied as problematic, which can result in denial
of service to the victim UE (case 1). If no or unknown, it
is also classied as problematic because this behavior could
be exploited to conduct a spoong attack (case 2). When
the test case is not accepted in the rst phase, the result is
divided into two different cases in the second phase. If the
victim UE is disconnected from the network although the
test case is not accepted in the receiving entity, it is also
classied as problematic behavior, which might be rooted in
misbehavior of the receiving entity when it recognizes that
the received message is not valid (case 3). Otherwise, the test
case is classied as benign, which means the receiving entity
correctly handled the invalid message (case 4). Based on this
classication, we can easily identify the problems and even
obtain attack scenarios. For example, the crafted messages
classied as case 1 and 3 can be exploited by an adversary
to perform a DoS attack against the victim UE.
D. Ethical considerations
Testing against operational networks.The purpose of our
study was not to identify failures causing crashes or memory
leaks. Instead, we focused on nding semantic failures in LTE
operations. To this end, we generated all possible test cases
that would have been correctly parsed in the receiving entities
as the eld values are created based on the control plane logs
from the operational networks. For instance, our test cases for
carrier A are only created using the eld values found in the
control plane messages of this carrier. In addition, we only
carried out the tests against our subscribed mobile phone to
ensure that the tests did not affect the connection state of other
legitimate users. It might only change the state of our target
device into an unexpected one if our test cases are accepted
by the receiving entity. Control plane overhead was negligible
considering the overhead of a normal situation [22]. The only
test case that may affect other UEs in the victim cell was
conducted by 1) rst testing against a femtocell utilizing the
frequency bands that are not used in operational networks, and
2) testing on the testbed of the carrier.
Testing against commercial phones.A testbed operating in
an LTE licensed band might inuence legitimate users who
are not participating in our experiments. To prevent normal
users from connecting to our testbed network, we only utilized
frequency bands that are not used by operational networks.
In addition, we set the transmission power of our eNB to a
minimum such that only our target UE within a distance of 20
cm was connected to our testbed. As a result, we conrmed that
no legitimate users were attempted to connect to our testbed
network during the experiments.
Legal restriction.Many countries have legal restrictions that
forbid unauthorized signals to be sent to commercial network
systems for the purpose of disrupting their stable operation.
Thus, dynamic testing of a commercial LTE network is also
strictly prohibited without permission. Fortunately, for the
purpose of inspecting and validating the vulnerabilities we un-
covered, two carriers gave us a permission to conduct dynamic
security testing. In addition, similar to carefully generating
the test cases to avoid disrupting the normal LTE services,
we also conrmed that our test cases were not problematic in
terms of the availability and reliability of network components
by cooperating with the carriers. After conducting the tests,
we also responsibly disclosed our ndings to the carriers and
vendors to address any problems immediately. With regard
to vulnerabilities attributed to specication defects, we are
planning to contact the standard bodies soon.
IV. IMPLEMENTATION
Although we explained above that we reduced the number
of test cases, manually conducting this number of test cases
is time-consuming; furthermore, a manual approach might
increase the possibility of introducing mistakes that could
affect the consistency and reliability of the experiments. To this
end, we tried to automate test operations as much as possible
with the help of fully controllable open source LTE stacks [9],
[10] and a control plane logging tool known as SCAT [23].
The experimental setup and implementation of LTEFuzz to
execute the test cases are divided into two types: 1) inspecting
operational network components for uplink test cases, and 2)
inspecting commercial mobile devices for downlink test cases.
1) Inspecting operational networks.In this setup, the tester
acts as malicious UE and sends a crafted message with the
test case input to a target operational network. The tester is
implemented on open source standard UE stack known as
srsLTE [9]. To conrm whether each test case is executed or
triggers a failure on the network side, we utilized a decision
tree to classify the problematic case by only monitoring the
logs on the UE side as described in III-C. To this end, our
tester sends test case messages by pretending to be a victim
UE by spoong the identity of the victim UE in both the
6

RRCandNASlayers
3
. Then, we observed the behavior of the
victim UE by utilizing SCAT whenever our tester executed
a test case. We automated this procedure by establishing a
communication channel between the tester and the victim UE.
ÀWhen the victim UE is ready, the tester executes a test case
and sends a notication to the victim UE.ÁUpon receiving
the notication, the victim UE sends ping requests to a public
website (i.e., www.google.com) and checks the ping response.
If it isNetwork is unreachable, the test case is labeled as
”Caused de-registration”.ÂLastly, we analyze the logs on the
UE side and classify each test case based on our decision tree.
Fig. 11 in the Appendix shows an actual screenshot of running
our uplink test. We carried out uplink tests by considering the
following three cases to validate the effectiveness of each test
case. A victim and a tester are located in (1) the samecell,
(2) differentcellsbut in the sameeNB, and (3) differenteNBs
but in the sameMMEpool.
2) Inspecting commercial mobile devices.Unlike the above
setups, the experimental setup for commercial mobile devices
is simpler. In this case, the tester acts as arogue LTE network
implemented on top of openLTE [10] and the victim UE is
connected to the host PC to capture the control plane logs.
The automated test operation is as follows.ÀOnce a test case
is submitted as input to therogue LTE network, it waits until
the victim tries to connect to our network.ÁWhen the victim
sends anRRC Connection request, ourrogue LTE network
operates as specied in the test case and noties the victim
side that the test has been executed.ÂUpon receiving the
notication, the victim side saves the control plane messages.
In addition, in case the victim falls into an invalid state from
which it cannot recover to the normal state, the host PC forces
the victim UE to reboot by sending an Android Debug Bridge
(ADB) command [24].
Our implementation consists of 3,470 lines of code (LoCs)
identied via in-depth analysis of more than 90K lines in 537
les of open source tools [9], [10], [23]. This includes 1,937
LoCs of C++ for the test input generator, 1,390 LoCs of C++
for the uplink/downlink tester and 143 LoCs of Python for the
communication channel between the tester and the victim UE.
V. TESTRESULTS
We carefully conducted a dynamic test on two Tier-1
carrier networks (with three different MMEs and three eNBs)
and commercial UEs (by including three different baseband
vendors). The test results for each test case (Table IV in the
Appendix) indicate that we uncovered 51 vulnerabilities across
different target network components and device vendors. We
conrmed the validity of most of our ndings in the operational
network by interviewing counterparts from the carriers. For
clarity purposes, we explain the results of our ndings and
their root cause analysis by categorizing them into ve types.
A. Initial RRC procedure is not protected
Test case observation.The test on property 1 in theRRC
layer indicated that theRRC Connectionprocedure is neither
encrypted nor integrity protected; thus, all the messages that
belong to theRRC Connectionprocedure are classied as
case 1 or 2 as listed in Table IV. Therefore, an adversary
3
Detailed spoong techniques for each case are presented in Section V.
could exploit these messages to spoof the contents or deny
the connection of the victim UE during theRRC Connection
procedure. For example, if an adversary changed the contents
of theueIdentityeld in theRRC Connection requestto vic-
tim's S-TMSI, she could deceive the eNB and lead it to believe
that the victim UE is currently in theRRC CONNECTEDstate
despite the victim being in theRRC IDLEstate.
Root cause analysis.According to 3GPP standards [19], the
initial authenticationprocedure between the UE and MME
occurs via theNAS protocol, which is processed after the
RRC Connectionprocedure. Thus, any eNB rst allows the
UE'sRRC Connection requestand leaves the authentication
procedure to an MME. When the authentication procedure fails
due to an invalid response from the UE (e.g., in the case of
an unsubscribed user or illegal UE), the MME sends aUE
Context release requestmessage to the eNB to release the
existingRRC Connectionof the abnormal user. Therefore, by
design, even illegal users who are not legitimately subscribed
to a particular carrier would be able to connect to the eNBs
of this carrier. However, they would be unable to maintain
theRRC Connectionlonger than several seconds because their
device would be unable to respond to theNAS Authentication
requestcorrectly. Despite this limitation, we determined that
an adversary who only has the ability to connect to an
eNB (but cannot proceed with the connection to achieve
full registration), could still perform critical attacks such as
blocking anyRRC Connectionsto a target eNB (Section VI-A),
disconnecting currentRRC Connections(Section VI-B), and
blocking a target user's incoming services (Section VI-B).
These attacks are mainly rooted from the 3GPP standard such
that the initialRRC Connectionprocedure is unprotected and
can be abused by an adversary. Detailed descriptions of each
type of attack are presented in Section VI.
B. Invalid uplink NAS plain messages cause failures
Test case observation.As explained in Section IV, we carried
out the uplink tests for three different cases: A victim UE and
a tester UE
4
are located in (1) the samecell, (2) different
cellsbut in the sameeNB, and (3) differenteNBsbut in the
sameMMEpool. Note that tests relating to these cases are
also described in Section V-C and V-D. The results indicated
that an adversary could send invalid plain requests through an
RRC Connectionspoofed as the victim UE. Interestingly, three
MME types have different problematic behavior upon receiv-
ing our invalid plain requests. For example, when the tester
sends a crafted plainNAS Attach requestto the MME1and
MME3, they removed the connection of the victim UE and sent
a release command to the tester, thereby implicitly detaching
the victim UE from the network (case 3). In this case, the
victim UE does not receive notication of its disconnection
from the service unless it initiates the transmission of uplink
data by sending aNAS Service request. When the victim UE
receivesService rejectwith the causeImplicitly detached, it
has to proceed with an initialAttachprocedure to reconnect to
the LTE network and this results in several seconds of service
disconnection. For another de-registration case, upon receiving
the plainNAS Detach request, all three MMEs immediately
de-registered the victim UE and repliedNAS Detach accept
to the tester UE (case 1). Besides, we also conrmed that
4
Tester could be a UE or a network as explained in Section IV.
7

TABLE II. SUMMARY OFMAJORFINDINGS
PropertyVulnerability/Attack Implications Detection Root cause
P1
RRC Connection manipulation Connection resource depletion on eNB/Cell Case 2 Design aw
RRC connection spoong
(Blindly) Denial of incoming service when a UE is in IDLE
Case 1
Design aw
Disconnection of current radio connection when a UE is in CONNECTED Implementation aw
Improper handling of uplink Implicit de-registration of a UE
Case 1, 2, 3Implementation aw
plain NAS messages SMS phishing due to non-security protection
P2
Improper handling of Implicit de-registration of a UE
Case 1, 2, 3Implementation aw
incorrectly integrity protected SMS phishing due to non-integrity verication
NAS messages Content manipulation for security protected messages
Improper handling of
replayed NAS messages
Implicit de-registration of a UE
SMS phishing due to non-replay protection
Deactivation of selected service (e.g., data or voice)
Fake location update of a UE
P3 Bypass RRC Security mode commandEavesdropping & manipulation of user data Case 2 Implementation aw
MME2processed plainNAS Uplink NAS transportwithout
any protection (case 2). In this case, an adversary could exploit
this MME2to launch an SMS phishing attack to any users
without being charged if they are subscribed to any carriers that
have a roaming agreement with the aforementioned vulnerable
carrier. In Table III, the affected plain initial messages are
identied by(P).
Root cause analysis.According to the 3GPP standard, the UE
sends initial requests without security protection only when
it has no valid security context as in certain cases such as
an expired context timer or unexpected errors. In case the
UE has no valid security context (i.e., a session key for
encryption and integrity protection), the MME needs to create
a new valid security context for further steps to achieve full
registration. The rst step toward creating a victim's new valid
security context is anAuthenticationprocedure between the
UE and the MME. Therefore, upon receiving the spoofed
initial requests without protection from our tester (acting as
a malicious UE), the MME would be required to perform
anNAS Authenticationprocedure to conrm whether this
abnormal message originated from a legitimate user without
processing the message or immediately disconnecting existing
UE connections. Accordingly, as we assume that the adversary
UE has no valid security context, it cannot perform theAuthen-
ticationprocedure correctly, whereby, an existing connection
for legitimate UE would not be affected. Therefore, if this was
implemented correctly in MME, the victim UE should not have
been implicitly detached from the network, as observed in our
test case. In conclusion, we found that all three MMEs did not
handle invalid plain requests correctly.
C. Non-integrity checking makes spoong attack possible
Test case observation.For the validation of the rst case
in property 2, our tester generated security protectedNAS
messageswith an incorrect MAC and sent them to either
the MME or the UE to inspect whether they appropriately
verify the MAC. Accordingly, we observed three different
kinds of inappropriate behavior (case 1, 2 and 3) in different
MMEs upon receiving a message with an invalid MAC. The
MME that belongs to case 1 and 2, did not verify the MAC,
and simply accepted the invalid message. For example, when
the tester sent anUplink NAS transportmessage with an
invalid MAC, the MME accepted this as being valid; hence,
the SMS is sent to the destination UE. On the other hand,
another MME that belongs to case 3 veried the MAC when
it received the message. However, the receipt of a message with
an incorrect MAC value resulted in the MME de-registering
the existing connection of the victim UE regardless of the type
of received message. In this case, theUplink NAS transport
TABLE III. EXPLOITEDNASMESSAGES IN TWO MMETYPES
Exploited Implications
NAS Messages MME1 MME2 MME3
Attach RequestDoS (P,I,R) 5 DoS (P,I,R)
TAU Request DoS (P,I,R) 5
DoS (I),
False location update (R)
Service RequestSpoong (R) 5 Spoong (R)
Uplink NAS DoS (P,I), SMS phishing
-
Transport SMS phishing (R)(P,I,R)
PDN Connectivity
DoS (I) 5 DoS, DosS (R)
Request
PDN Disconnect
DoS (I), DosS (R) 5 DosS (R)
Request
Detach RequestDoS (P,R) DoS (P,I,R)DoS (P,I,R)
DosS:Denial of selective Service,P:Plain,I:Invalid MAC,R:Replay
with incorrect MAC caused de-registration of the victim UE
and did not transmit the SMS message to the destination UE.
Messages affected by an invalid MAC are marked with(I)in
Table III. We present detailed scenarios that exploit improper
handling of messages with an invalid MAC in Section VII.
Root cause analysis.According to the 3GPP standard [15],
both the UE and the MME have to verify the integrity of
theNAS messageonce a valid security context exists between
the UE and the MME. However, we speculate that device
vendors misunderstood the acceptance ofNAS messageswith-
out integrity protection by the MME in certain exceptional
situations (e.g., when the UE sends the message before security
is activated for the initial message. In our test scenario,
because both the victim UE and the serving MME have
the valid security context, the MME should have veried
the integrity of every received message. Failed verication
should have resulted in the MME dropping or rejecting the
received message while maintaining the existing connection
of the victim UE. Therefore, these cases obviously constitute
implementation mistakes for all three MMEs.
D. Replayed messages are accepted
Test case observation.While validating the second case in
property 2, we also inspected whether the receiving entity (the
network component or the UE) veries the sequence number
to prevent a message replay attack. The results conrmed that
some craftedNAS messageswere accepted as being valid by
both the MMEs and the UEs because the tester subsequently
received expected reply messages (case 1). For instance, when
the tester sent a replayedNAS PDN disconnect requestfor
disconnecting a specied existing data bearer, the tester re-
ceived a security protectedNAS message
5
whereas the victim
UE blindly lost the connection of the data bearer (case 1).
5
We could not exactly identify this message as it is encrypted, but it is
assumed to be aNAS Deactivate EPS bearer context requestwhen consid-
ering the message length.
8

In addition, when the tester sent replayedNAS TAU request
to MME3, it repliedNAS TAU acceptto the tester, which
means that MME3falsely updated the Tracking Area (TA)
of the victim UE (case 2). However, when the tester sent the
replayedTAU requestto MME1, it immediately de-registered
the existing connection of the victim UE whereas the tester
received anRRC Connection release(case 3). The uplink
messages affected by a replay attack are marked by(R)in
Table III. For downlinkNAS messages, we conrmed that a
HiSilicon baseband accepted the replayed message, allowing
an adversary to perform a message spoong attack (case 2).
The affected messages are listed in Table IV in the Appendix.
Root cause analysis.The 3GPP standard [15] requires both
the MME and UE to support replay protection for security
protectedNAS messagesand it provides a detailed method
of replay protection for the vendors. However, the same
document requires the receiving entity to use theNASsequence
number included in the received message for eight LSBs of
the counter when verifying the integrity of the receivedNAS
message. Moreover, when the integrity verication succeeds,
the receiving entity should update its local counter with
the value of the received sequence number. In this integrity
verication method, a message replay is possible unless the 28
LSBs of the local counter is different from the counter used
when calculating the message integrity. Therefore, the integrity
verication method specied in the standard contradicts the
security requirement that the replay protection should be
supported for theNAS messages. As a result, all three MMEs
were vulnerable to replay attack at least for oneNAS message
and one of our target basebands accepted replayed messages.
E. Security procedure can be bypassed
Test case observation.In terms of property 3, we checked
three test cases: (1) skip the key agreement procedure in the
RRClayer to nullify the security context ofRRCand user data,
(2) skip the key agreement procedure in both theRRCandNAS
layer to nullify the security context of the entire control plane
and data plane, and (3) skip all the security procedures in
AKA in bothRRCandNAS. Consequently, only the rst case
succeeded for our target mobile devices. If an adversary was to
exploit this case, they would be able to spoof theRRC messages
to obtain the private information of the UE, and eavesdrop the
user's communication. The attack procedures and implications
are described in Section VIII in detail.
Root cause analysis.As noted in the specication, the security
procedure is a mandatory step for protecting the communica-
tion between the UE and the network. However, we conrmed
that some commercial devices (using a Qualcomm baseband)
do not follow the specications; thus, they allow the security
key negotiation in theRRClayer to be omitted. Therefore,
this vulnerability is rooted in the implementation aw in
commercial baseband chipsets.
F. Summary and responses from the carriers
By sending carefully crafted messages, we were able to
uncover 51 vulnerabilities in thedesignandimplementation
of UE, eNB, and MME. From the design perspective, unpro-
tected initial procedures are vulnerable to spoong attacks.
We also conrmed that the behavior of operational MMEs
and commercial devices in response to our test cases differs
across vendors and even message types within one vendor. We
reported all our ndings to the corresponding carriers. Then,
we validated and communicated all network side test cases
with the corresponding vendors together with the carriers. As
a result, we received a response from one vendor (MME3)
conrming that all the vulnerabilities we discovered are valid
and that they are preparing patches for each problematic case.
The following sections describe how our ndings can be
exploited for attacks by categorizing the target entities as eNB,
MME, and UE, in Section VI, VII, and VIII, respectively.
VI. ATTACKS EXPLOITING ENB
A. BTS resource depletion attack
Every commercial eNB has a maximum capacity of
active user connections based on their hardware and
software specications. The purpose of theBTS resource
depletionattack is to deplete this capacity of the activeRRC
Connections, thereby preventing other users from connecting
to the target eNB.
1) Adversary model:This attack targets a commercially
operating eNB. An adversary could obtain the connection
information of the target eNB by passively listening to the
broadcast messages similar to other normal devices.
2) Attack procedure:The adversary repeatedly performs
Random Accessand generatesRRC Connectionsin order to
increase the number of activeRRC Connectionsas depicted
in Fig. 5(a). In a normal situation, immediately after the
RRC Connectionis established, an initialNAS Connection
procedure proceeds through either anNAS Attach request
orNAS Service requestpiggybacked on anRRC Connection
completemessage. In our attack, the adversary sends the
NAS Attach requestwith an arbitrary user IMSI. Unlike
the normal procedure, once the adversary receives theNAS
Authentication request, it restartsRandom Accessto
establish a newRRC Connection. The reason the adversary
does not reply to theNAS Authentication requestfrom the
MME is to sustain the establishedRRC Connectionwhile
the MME waits for a validNAS Authentication response.
If the adversary replies with an invalidNAS Authentication
response, it causes immediateRRC Connection release. One
consideration for the attack to succeed is that the number of
newly establishedRRC Connectionshas to be greater than
the number of existingRRC Connectionsthat are released.
3) Implementation:We used one USRP B210 [25] for
the software radio transceiver, and srsUE [9] to implement
a malicious UE. To repeat theRRC Connectionprocedure
continuously with different C-RNTIs, we modied the
srsUE to restart anotherRandom Accessprocedure whenever
it receives anNAS Authentication requestrather than
replying with anNAS Authentication response. If several
RRC Connection requestsare sent with the same C-RNTI,
the eNB processes this as repeated requests for the sameRRC
Connection, which is not our adversary's goal.
4) Validation:Because attacking commercially operating
eNBs can affect legitimate users, we performed ourBTS
resource depletion attackagainst a COTS femtocell [26]
connected to our testbed EPC network implemented on
OpenAirInterface (OAI) [11]. We mainly attempted to
determine the number of fakeRRC Connectionsthat could
be established using one USRP device. This is accomplished
by verifying activeRRC Connectionsof our femtocell
9

(a) (b)
Fig. 5. Flow diagrams showing the procedure followed by attacks that exploit
eNB: (a)BTS resource depletion attack, (b)Blind DoS attack




     
RIFRQQHFWLRQ
7LPHV
,QLWLDOL]DWLRQ5HVRXUFH'HSOHWLRQDWWDFN 6DWXUDWLRQ
Fig. 6. Number of activeRRC ConnectionsinBTS resource depletion attack.
using an Airscope [27], which provides over-the-air user
information by decoding the communication channels in the
physical layer of LTE. Fig. 6 shows that the number of active
RRC Connectionsincreases until it reaches the maximum
capacity of the femtocell, namely 16 active connections in
the case of our target femtocell. Therefore, once an adversary
has generated 16RRC Connections, the femtocell rejects
all subsequentRRC Connection requestseither from the
adversary or from the legitimate UE, as shown in Fig. 7.
When demonstrating the attack, it took 0.762 s to establish
16RRC Connections, and we could establish 20RRC
Connectionsper second. Therefore, an adversary would be
able to create 200RRC Connectionsin case the operational
eNB was to wait 10 s for inactiveRRC Connectionsto be
released. We conrmed with the carrier that an attack of this
nature would affect an operating eNB. In addition, the carrier
suggested an even more serious scenario. If the adversary
was to include “emergency” as anestablishment causein
anRRC Connection request, it would even release existing
RRC Connections, if no additionalRRCresource was available.
B. Blind DoS attack
Unlike the aforementioned attack that denies multiple users
in an eNB, theBlind DoS attackdenies a targeted UE by
establishingRRC Connectionsspoofed as the victim UE.
1) Attack model:The attacker performs the attack within the
area covered by the victim's serving eNB. The attacker also
Fig. 7. Victim UE receivesRRC Connection rejectduringBTS resource
depletion attack.
knows the victim's S-TMSI that can be obtained in three ways:
An adversary who has knowledge of the victim's phone
number or accounts on social media (such as Facebook and
Whatsapp) could obtain the victim's S-TMSI by performing
a silentPagingattack [7], [28].
An adversary located in the vicinity of the target user could
operate arogue eNBto obtain theNAS TAU requestof the
victim UE. This request contains the S-TMSI of the victim
UE. As soon as this message is received, the adversary turns
off therogue eNBto enable the victim UE to recover the LTE
service by connecting to a carrier network.
The adversary sniffs theRRC Connectionprocedure of the
target UE to obtain the S-TMSI of the target UE as specied
in theRRC Connection setup[5].
2) Attack procedure:The adversary carries out the attack
by establishing anRRC Connectionspoofed as the victim UE
(Fig 5(b)). This can be achieved by inserting the S-TMSI of
a victim UE in theueIdentityeld of theRRC Connection
request. This attack can be launched with no special efforts to
circumvent the deployed security measures because, by design,
theRRC Connectionprocedure has no security mechanisms to
conceal the content or authenticate the message sender.
3) Implementation:We used one USRP B210 [25] for the
software radio transceiver, and srsUE [9] for the software LTE
UE. We slightly modied the srsUE to add the S-TMSI of
the target UE to theueIdentityeld of theRRC Connection
request. In addition, for the same reason as for theBTS
resource depletion attack, the attacker device does not respond
to theNAS Authentication request.
4) Validation:We validated the attack on commercial eNBs
located in the vicinity of our laboratory building. To exclude
innocent victims, we only utilized the S-TMSI of our mobile
phone as the identity of the victim UE. The impact of the
attack was assessed by separating it into two types according
to theRRC Connectionstate of the victim UE.
The victim UE is in theRRC IDLEstate: The UE attempts
to establish anRRC ConnectionwhenPagingnoties the
incoming services or the UE has outgoing service trafc. If
the adversary establishes anRRC Connectionspoofed as the
victim UE, the serving eNB saves theRRCstate of the victim
asRRC CONNECTEDand noties the serving MME of this
change. Thus, the MME does not triggerPagingto any eNBs,
despite the existence of incoming services for the victim. In
this case, the victim is blindly disconnected from the serving
eNB until it attempts to establish a newRRC Connection
for outgoing trafc from the application services. From the
user's perspective, both incoming data and voice are blocked
without any notications of disconnection.
The victim UE is inRRC CONNECTED state: When the
10

Fig. 8.Remote de-registration attackusing either the crafted plain requests,
invalid security protected messages or replayed messages.
adversary establishes a spoofedRRC Connection, the existing
RRC Connectionof the victim UE is released on the eNB
without any notications to the victim. In this case, the UE
continues to communicate with the serving eNB but it fails
because the radio bearer was already released. Once commu-
nication has failed several times, the UE falls into the Radio
Link Failure (RLF) state, thus it sends anRRC Connection
reestablishment request. However, the serving eNB rejects
this request because it is already released. Upon receiving the
reject message, the UE attempts to carry out theNAS TAU
procedure and reestablishes the connection by sending anNAS
Service request. Eventually, the UE is disconnected from
the network during the re-registration procedure explained
above. The time required for re-registration was approx-
imately 0.5 s, thus if the adversary was to continuously
establish the spoofedRRC Connectionevery 0.5 s, the victim
would remain in the disconnected state permanently.
Note that we validated this attack on three different eNB
vendors. When the victim UE is inRRC IDLE, the attack
succeeded for all eNBs. However, when the victim UE is in
RRC CONNECTED, two of our target eNBs were affected by
the attack whereas the other eNB was not. To summarize, a
Blind DoS attackcould block incoming services of a victim
UE inRRC IDLEstate by deceiving a serving eNB, which
believes that the UE is inRRC CONNECTEDstate. In addition,
the victim UE was permanently prevented from using the LTE
service by two vendors because those eNBs only maintain a
singleRRC Connectionfor a single S-TMSI of a UE.
VII. ATTACKS EXPLOITING MME
In this section, we explain the way in which an adversary
could exploit the vulnerabilities in operational MMEs. This
includes remote de-registration of the legitimate UEs, denying
a selective service, and SMS phishing without subscribing to
the service. Note that all attacks described in this section occur
as a consequence of the adversary exploiting a spoofedRRC
Connectionwhen sendingNAS messages.
A. Remote de-registration attack
During our experiments, we discovered that operational
MMEs have several implementation aws that cause them to
unnecessarily de-register the victim UE without notication.
The detailed attack scenario is as below.
1) Adversary model:An adversary should be able to send
maliciousNAS messagesto the MME in which the victim UE
is registered. Typically, an MME manages a number of eNBs
which are distributed throughout large geographical regions.
The adversary also knows the S-TMSI of the victim UE.
Especially, for an attack that exploits message replay, the
adversary would have to capture the corresponding message
before launching the attack. There are two ways to obtain a
control plane message of the victim UE.
An adversary could operate arogue LTE networkto capture
the control plane messages of the victim UE while relaying
these messages between the UE and the network [4], [5].
An adversary could install a malicious app with control plane
message logging functionality [29] on the UE.
We implemented the attack by utilizing arogue LTE network
to capture the control plane messages of the victim UE. In this
case, the adversary cannot decrypt the messages. However, we
could correctly identify the type of encrypted messages by only
checking the order and length of the messages.
2) Attack procedure:As shown in Fig. 8,Àan adversary
rst establishes anRRC Connectionspoofed as the victim UE
(using the UE's S-TMSI).ÁThe adversary sends a crafted
initial plain request, invalid security protected message, or
replayed message to the MME serving the victim
6
. In this case,
once the adversary sends the message through the spoofed
RRC Connection, the serving eNB forwards the message to
the MME serving the victim by checking the S-TMSI.ÂThe
MME processes the message it receives from the adversary
inappropriately. Consequently, the MME de-registers the con-
nection of the victim UE without any notication to them.
3) Implementation:We implemented the adversary using the
srsLTE UE stack [9]. She sends the vulnerableNAS messages
as soon as the spoofedRRC Connectionis established.
4) Validation:We demonstrated theRemote de-register
attackagainst an operational LTE network by exploiting either
invalid plain messages, security protected messages or replayed
messages. We conrmed that an adversary could perform
this attack by connecting to any eNBs able to communicate
with the same MME serving the victim UE. An interview
with a counterpart in the carrier revealed that an eNB might
communicate with any MMEs regardless of the geographical
regions and that this depended on the operational policy of
the particular carrier. In this case, an adversary would be
able to remotely de-register arbitrary users subscribed to the
carrier regardless of the user's location only if the adversary
succeeded in obtaining the valid GUTIs. Note that obtaining
a valid GUTI is not difcult as discussed previously. TheNAS
messagesthat could be used to carry out this attack are listed
in Table II. A notable case for message replay is that, once
the MME accepts replayed aNAS PDN disconnect request,
the adversary can selectively deny the user's service (e.g., the
adversary blindly disconnects the data service of the victim
UE whereas the voice service continues to be available).
B. SMS phishing attack
1) Adversary model:In this scenario, the adversary sends
an SMS message to victim UE1by spoong the message
sender using the phone number of victim UE2. To this end,
the adversary knows the S-TMSI of UE2to spoof the sender.
The phone number of UE1, to which the actual SMS message
is sent, is also known. In addition, we assume that the target
LTE network provides the SMS through theNASlayer.
2) Attack procedure:ÀThe adversary starts by establishing
6
The adversary chooses the messages depending on the vulnerabilities found
for each carrier.
11

a spoofedRRC Connectionusing the S-TMSI of UE2. Then,
ÁSMS content is generated and included on anNAS Uplink
NAS transport.ÂImmediately after theRRC Connectionis
established, the adversary sends the generatedNAS Uplink
NAS transportto the serving MME.ÃUpon receiving the
message, the MME transmits this manipulated SMS to UE1.
3) Implementation:We implemented this attack by modify-
ing the srsLTE implementation. In particular, we simply added
the functionality to supportSMS over NAS.
4) Validation:Our test results conrmed that we successfully
carried out this attack on the carrier as MME1does not
verify the sequence number of theNAS Uplink NAS transport
message, whereas MME2accepts all invalid messages (plain,
invalid MAC, and replay).
VIII. ATTACKS EXPLOITING UE: AKABYPASS ATTACK
1) Adversary model:The adversary is located sufciently
close to the victim UE to trigger handover from an existing
eNB to the adversary'srogue LTE network. To this end,
therogue LTE networktransmits an LTE signal with higher
transmission power than commercial eNBs. Additionally, the
adversary would have to know the list of Tracking Areas (TAs)
to masquerade therogue LTE networkas a commercial one.
A valid TA Code (TAC) can easily be captured in two ways:
If the adversary is subscribed to the same carrier as the victim,
the list of TAs can be obtained by checking control plane
messages such asAttach Accept.
If the adversary only owns arogue LTE network, she rst
chooses a TA randomly. Once the target UE connects to the
rogue LTE network, it sends aTAU requestas the TA of the
connecting network is not on its list of TAs. Upon receiving
theTAU requestfrom the UE, the adversary can obtain the
previous TAC of the UE by parsing the request. Note that the
TAU requestis only integrity protected.
2) Attack procedure:As shown in Fig. 9, the adversary builds
therogue LTE networkand congures its operating parameters
such that they are identical to the victim's operational network.
ÀIf the transmitting power of therogue eNBis higher than the
serving eNBs, the victim in theRRC IDLEstate resynchronizes
to the adversary's eNB. In this case, the UE does not trigger
theNAS TAUprocedure as the TAC of therogue eNBis
contained in the TA list of the victim UE
7
. Thus,Áwhen the
UE is transmitting outgoing data (i.e., by calling someone or
browsing the Web) or is receivingPagingfrom therogue LTE
network, it establishes anRRC Connectionand sends anNAS
Service request. Upon receiving a valid integrity protected
Service requestfrom the UE, the normal eNBs perform an
RRC Security modeprocedure to regenerate the cryptographic
keys for theRRClayer and user data. However,Âourrogue
LTE networkomits this procedure and immediately prepares
to create a radio tunnel (also known as a Data Radio Bearer
(DRB)) by sending a plainRRC Connection reconfiguration.
Upon receiving this request,Ãthe UE creates the DRB and
also replies with a plainRRC Connection reconfiguration
completemessage. Finally,Äthe UE transmits and receives
unprotected user data through this tunnel with therogue LTE
networkwithout receiving any notication.
7
In LTE, the UE receives a TA list that contains adjacent TACs when it
attaches to the network. The UE performs aTracking Area Updateprocedure
when it moves to a new TAC that is not included in its TA list.
Fig. 9. Procedure ofAKA Bypass attack.
3) Implementation:We used one USRP B210 for the radio
transceiver, and openLTE [10] for therogue LTE network.
The adversary'srogue LTE networkdoes not negotiate the
security algorithm for theRRClayer and user data in response
to a connection request from the victim UE. Further, the
RRC Recongurationprocedure is performed without security
protection, which is against the security guidelines noted in
the standard [19].
4) Validation:We validated that theAKA Bypass attack
can nullify the existing encryption of the user data of an
existing UE on multiple smartphone models (e.g., the LG
G2 and Samsung Galaxy S4/S5, all of which use Qualcomm
basebands). Because ourrogue LTE networkcongured the
TAC as in the TA list of the victim UE, this UE did not
trigger aTAU requestwhen it rst synchronized with our
eNB. Interestingly, some models frequently initiated theNAS
TAU requestduring the attack period. However, if therogue
LTE networkdoes not reply upon receiving the request from
the UE, the victim UE reconnects by sending theNAS Service
request. This proves that our attack is still effective even in
that situation.
IX. COUNTERMEASURES
Attacks exploiting eNB.In the case of aBTS resource
depletion attack, it is impossible for an eNB to distinguish
the adversary'sRRC Connection requestsfrom benignRRC
connection requests. A possible mitigation to this attack
could be to reduce theinactivity timervalue to allow an
RRC Connectionthat is unresponsive to theAuthentication
requestto expire. Although it does not constitute a fun-
damental solution, it can weaken the impact of this attack
as it minimizes the number of fakeRRC Connectionsthe
adversary can establish. However, if the carrier congures the
inactivity timerinappropriately short, the UEs may perform
frequentRRC Connectionprocedures. Accordingly, this would
increase the signaling load on both the eNB and MME sides.
On the other hand, a possible mitigation for aBlind DoS
attackmight be to re-assign the S-TMSI when a number
ofRRC Connection requestsusing the same S-TMSI are
received. According to the 3GPP standard, an MME can trigger
reallocation of the S-TMSI in two ways. The rst is to directly
send a security protectedNAS GUTI reallocation commandto
the UE. However, this would not prevent aBlind DoS attack
because the message would not be received by the UE during
the attack. Another approach would be to broadcastPaging
with the IMSI of the UE. As thePagingis broadcast over the
entire area covered by the cell, the UE would receive it and
12

initiate theAttachprocedure with the IMSI upon receiving the
Pagingmessage, which would increase signaling overhead.
Attacks exploiting MME and UE.As discussed in Section V,
both theRemote de-register attackandSMS phishing attack
are rooted from incorrect implementation of the operational
MMEs. Thus, these MMEs should be carefully implemented
by strictly following the 3GPP standard. TheAKA bypass
attackis also rooted in the UE handling the mandatory
security procedure incorrectly. Therefore, the UE should not
proceed with any control plane procedures before completing
the mandatory security procedure successfully.
X. RELATED WORK
A. Identifying unexpected behavior
Several previous studies were conducted to identify unex-
pected failures and performance degradations caused by either
design aws or implementation bugs [30]–[32]. Tu et al. [30]
designed a model with which to analyze logical problems
in inter-layer communication between LTE and 3G. Hong et
al. [31] developed a control plane analysis tool to identify
implementation/conguration aws by conducting comparative
analysis of commercial logs. Jia et al. [32] analyzed perfor-
mance problems in Voice over LTE (VoLTE). However, all
these studies attempted to identify performance problems by
utilizing passively collected commercial logs. In contrast, we
focused on nding security bugs by utilizing malicious input.
B. Security problems
MitM attack.Many previous studies, [7], [33]–[40] employed
arogue BTSin a 2G/3G network. However, the Man in the
Middle (MitM) attack in LTE networks received less atten-
tion [4], [5], [20]. Rupprecht et al. [20] showed that an LTE
dongle could be used for eavesdropping and tampering if the
dongle incorrectly allowsnull integrityto both the control and
data plane. Hussain et al. [4] demonstrated anAuthentication
relay attackto eavesdrop a victim UE's data communication if
the carrier usesnull encryptionto the data plane. In addition,
Rupprecht et al. [5] showed that the IP address the DNS
server includes in a packet could be manipulated when the
counter mode was used for user data encryption in LTE. The
former can be used for eavesdropping only if a carrier allows
null encryption, whereas the latter enables DNS hijacking.
Unlike the above studies, omitting theSecurity mode command
enables the user data to be communicated in plain text and
can even be manipulated regardless of the integrity/encryption
policy of the carrier.
DoS attack.Previous studies introduced DoS attacks that
exploit vulnerabilities in LTE control plane procedures [4],
[7], [41]–[44]. Shaik et al. [7] presented DoS attacks using
plain reject messages (NAS TAU reject, Service rejectand
Attach reject). Raza et al. [41] demonstrated two types of
DoS attacks that were able to detach a user from the network:
the rst uses a plainNAS Detach requestmessage and the
other usesPagingwith the user's IMSI. Both studies showed
that certain unprotected plain messages may cause denial of
service to users. In this paper, we dened the desired security
properties in an LTE network andsystematicallycrafted the
messages that can pose a threat to each property. Consequently,
we tested (almost) allRRCandNASuplink/downlink messages
and showed that DoS attacks are possible with other message
types that were previously unknown. Unlike these two studies,
Hussain et al. [4] formally modeled the control plane pro-
cedures based on the LTE standard and inspected the model
to identify LTE design problems. Among the vulnerabilities
introduced, they presented several DoS attacks using plainNAS
messages. However, as they inspected the LTE standard (fo-
cusing onNAS), their model cannot disclose the vulnerabilities
resulting from design bugs in theRRClayer or incorrect imple-
mentations in operational networks. In contrast, our approach
can be used to uncover the vulnerabilities resulting from both
the design aws and incorrect implementations in the control
plane protocols. Prior to these studies, investigations of DoS
attacks in 2G and 3G networks were reported [45]–[50].
XI. CONCLUDING REMARKS AND FUTURE WORK
In this study, we investigated potential security problems
by dynamically testing the control plane components in an
operational LTE network. The procedure of semi-automated
dynamic testing consists of three steps: creating security prop-
erties based on specication analysis, generating and conduct-
ing test cases that violate the security properties, and classi-
fying a problematic case. As a result, LTEFuzz successfully
identied 15 previously disclosed vulnerabilities and 36 new
vulnerabilities indesignandimplementationamong the differ-
ent carriers and device vendors. The ndings were categorized
into ve vulnerability types. We also demonstrated several
attacks that can be used for denying various LTE services,
sending phishing messages, and eavesdropping/manipulating
data trafc. We performed root cause analysis of the identied
problems by reviewing the related standard and interviewing
collaborators of the carriers.
In conclusion, LTEFuzz is an effective tool to discover
design and implementation vulnerabilities caused by carriers
and device vendors. Our ndings were interesting in two
respects: 1) even within a single carrier, two MMEs (possibly
from different vendors) have different vulnerabilities, and 2)
two MMEs (in two carriers) manufactured by a single device
vendor have different vulnerabilities. This shows that neither
the device vendors nor the carriers have checked the security
of their network components carefully. In addition, LTEFuzz
was able to uncover vulnerabilities in baseband chipsets from
Qualcomm and HiSilicon, who ranked number 1 and 4 in
market share in 2017 [51]. We plan to privately release
LTEFuzz to these carriers and vendors in the near future. A
public release is not planned as LTEFuzz can be used for
malicious purposes. Because of space constraints, we present
the limitations of LTEFuzz and future work in the Appendix.
ACKNOWLEDGMENT
We would like to thank the anonymous reviewers and
our shepherd, Thorsten Holz, for their insightful comments
and suggestions to improve the paper. This research was
supported by the MSIT (Ministry of Science, ICT), Korea,
under the ITRC (Information Technology Research Center)
support program (IITP-2018-2015-0-00403) supervised by the
IITP (Institute for Information & communications Technology
Promotion).
13

REFERENCES
[1]
lte-subscriptions-to-1q-2018-yoy-growth.
[2]
telegeography.com/globalcomms-database-service.
[3]
98-lte, 2017.
[4]
tor: A Systematic Approach for Adversarial Testing of 4G LTE,” in
Proceedings of the Network and Distributed Systems Security (NDSS),
2018.
[5] ¨opper, “Breaking LTE on
Layer Two,” inIEEE Symposium on Security & Privacy (SP). IEEE,
2019.
[6]
Programmers,” inInternational Conference on Mathematical Methods,
Models, and Architectures for Computer Network Security. Springer,
2017.
[7]
“Practical Attacks Against Privacy and Availability in 4G/LTE Mobile
Communication Systems,”Proceedings of the Network and Distributed
System Security Symposium (NDSS), 2016.
[8]
Unsafe Network,” inHack In The Box Security Conference (HITBSec-
Conf), 2016.
[9]
[10]
[11]
org
[12]
[13]
system Aspects; Security related network functions,” 2017. [Online].
Available: http://www.3gpp.org/ftp/Specs/html-info/43020.htm
[14]
network protocols; Stage 3,” 2017.
[15]
Packet System (EPS); Stage 3,” 2017.
[16]
aspects of non-3GPP accesses,” 2017.
[17]
[18]
(E-UTRA) and Evolved Universal Terrestrial Radio Access Network
(E-UTRAN); Overall description; Stage 2,” 2017. [Online]. Available:
http://www.3gpp.org/ftp/Specs/html-info/36300.htm
[19]
UTRA); Radio Resource Control (RRC); Protocol specication,” 2017.
[20] ¨opper, “Putting LTE Security Func-
tions to the Test: A Framework to Evaluate Implementation Correct-
ness,” in10th USENIX Workshop on Offensive Technologies (WOOT),
2016.
[21]
[Online]. Available: http://www.canarysystems.com/nsupport/CDMA
ATCommands.pdf
[22]
Trafc.” [Online]. Available: https://www.nokia.com/enint/blog/
managing-lte-core-network-signaling-trafc
[23]
https://github.com/fgsect/scat
[24]
Available: https://developer.android.com/studio/command-line/adb?hl=
en
[25]
details/UB210-KIT
[26]
https://marksquared.co.uk/s60z/en
[27]
tag/airscope
[28]
the GSM Air Interface,” inProceedings of the Network and Distributed
System Security Symposium (NDSS), 2012.
[29]
Extracting and Analyzing Cellular Network Information on Smart-
phones.” inProceedings of the ACM Annual International Conference
on Mobile Computing & Networking (MobiCom), 2016.
[30]
Protocol Interactions in Cellular Networks,” inProceedings of the 2014
ACM conference on SIGCOMM. ACM, 2014, pp. 223–234.
[31]
S.-J. Lee, and Y. Kim, “Peeking over the Cellular Walled Gardens-A
Method for Closed Network Diagnosis,”IEEE Transactions on Mobile
Computing, 2018.
[32]
S. Kwong, and K. Lau, “Performance Characterization and Call Re-
liability Diagnosis Support for Voice over LTE,” inProceedings of
the 21st Annual International Conference on Mobile Computing and
Networking. ACM, 2015.
[33]
analysis of GSM Encrypted Communication,” inAnnual International
Cryptology Conference. Springer, 2003, pp. 600–616.
[34]
in-the-Middle Attacks on the Security of Interoperating GSM/UMTS
Networks,” inPersonal, Indoor and Mobile Radio Communications,
2004. PIMRC 2004. 15th IEEE International Symposium on, vol. 4.
IEEE, 2004.
[35] Univ.
of London, Royal Holloway, RHUL-MA-2001-3, 2001.
[36] Chair for Communication Security, Ruhr-
Universit¨at Bochum, vol. 14, 2007.
[37]
Proceedings of the 3rd ACM workshop on Wireless security. ACM,
2004.
[38]
Network Access,” inWireless Telecommunications Symposium, 2009.
WTS 2009. IEEE, 2009.
[39]
Authentication and Key Agreement Protocol,”IEEE Transactions on
wireless communications, vol. 4, no. 2, pp. 734–742, 2005.
[40]
The Effect of Rogue Devices on Mobile Telecommunications.” in
Proceedings of the Network and Distributed System Security Symposium
(NDSS), 2012.
[41]
Weaknesses at Protocol Inter-Layer, and Inter-Radio Interactions,” in
International Conference on Security and Privacy in Communication
Systems. Springer, 2017, pp. 312–338.
[42]
and Y. Kim, “Breaking and Fixing VoLTE: Exploiting Hidden Data
Channels and Mis-implementations,” inProceedings of the 22nd
ACM SIGSAC Conference on Computer and Communications Security.
ACM, 2015.
[43]
“Insecurity of Voice Solution VoLTE in LTE Mobile Networks,” in
Proceedings of the 22nd ACM SIGSAC Conference on Computer and
Communications Security. ACM, 2015.
[44] ANSSI
Symposium sur la securite des technologies de l' information et des
communications (SSTIC), 2016.
[45]
Functionality in SMS-capable Cellular Networks,” inProceedings of
the 12th ACM conference on Computer and communications security.
ACM, 2005, pp. 393–404.
[46]
in Internet-connected Cellular Networks,” inProceedings of 16th
USENIX Security Symposium on USENIX Security Symposium, vol. 21.
USENIX Association, 2007, pp. 1–21.
[47]
14

ing to Attacking Mobile Phones on a Large Scale.” inUSENIX Security
Symposium, 2011, p. 99.
[48]
Attacks on 3G Wireless Networks,” inINFOCOM 2007. 26th IEEE
International Conference on Computer Communications. IEEE, 2007,
pp. 1289–1297.
[49]
T. La Porta, “On Cellular Botnets: Measuring the Impact of Malicious
Devices on a Cellular Network Core,” inProceedings of the ACM
SIGSAC Conference on Computer and Communications Security (CCS),
2009.
[50]
Exploiting Broadcast Information in Cellular Networks.” inUSENIX
Security Symposium, 2013.
[51]
able: https://www.businesswire.com/news/home/20180604005896/en/
Strategy-Analytics-2017-Baseband-Market-Share-Intel
[52]
[Online]. Available: https://www.qualcomm.com/news/onq/2017/03/09/
3gpp-agrees-plan-accelerate-5g-nr-global-5g-standard-2019-deployments
[53]
3gpp.org/release-15
[54]
Mobile: Effect of Unsecured Clock Source in Smartphones,” inPro-
ceedings of the 6th Workshop on Security and Privacy in Smartphones
and Mobile Devices. ACM, 2016.
APPENDIXA
LIMITATIONS ANDFUTUREWORK
Stateless Fuzzer:LTEFuzz can be classied as a stateless
fuzzer that does not intend to diagnose memory bugs. Although
we uncovered 51 vulnerabilities using LTEFuzz, potential
vulnerabilities LTEFuzz would be unable to cover do exist.
The attack model of LTEFuzz assumes that an adversary
does not have access to the cryptographic keys of the victim.
Therefore, the adversary sends all crafted messages while
being deregistered. In other words, multi-stage vulnerabilities
8
are currently beyond the scope of LTEFuzz. To diagnose multi-
stage attacks, the tester rst transitions to the target state by
relaying the valid control plane messages between the UE
and the network. When it reaches the target state, it may
send unwanted messages. Cases such as these were previously
demonstrated [5], [20]. The number of possible states as well
as decision tree construction for all possible combinations of
states seems to be the most signicant challenge for stateful
fuzzing. The extension of LTEFuzz to stateful fuzzing remains
a future task. Note that, as discussed in Section III, the
identication of failures responsible for causing crashes or
memory leaks is not currently of concern.
Carriers and Vendors:Because of ethical and legal restric-
tions, we were able to only include two carriers in our tests,
who are collaborating with us. However, as we have shown
in the paper, different vendors and carriers have different
vulnerabilities. We plan to collaborate with other carriers and
vendors to check their security using LTEFuzz. Furthermore,
we could apply our testing method to other control plane
protocols such as the S1 Application Protocol (S1AP) and
X2 Application Protocol (X2AP) which carry control plane
trafc among core network components. However, we need
access to the core network (i.e., eNBs, MMEs, or gateways)
to dynamically inspect the communication of those protocols.
We would be able to conduct dynamic security tests against
8
Multi-stage refers to multiple state changes.
those protocols in future only if the carriers were to grant us
access permission to their core network.
Consideration for 5G:According to the 5G standard de-
velopment and deployment plan, 5G Non-Standalone (NSA)
9
will be deployed as early as 2019 [52]. Subsequently, the 5G
Standalone (SA) standard will be developed by 2020 [53].
In other words, LTEFuzz would remain useful for 5G NSA
as long asopen source LTE implementations such as srsLTE
support 5G in radio communication. Additional development
would be required to support 5G SA, as the core network is
likely to change. Therefore, ensuring that LTEFuzz supports
both 5G NSA and SA remains a future task.
APPENDIXB
ADDITIONAL FIGURES       
6HFXULW\+HDGHU7\SH 3URWRFRO'LVFULPLQDWRU
0HVVDJH$XWKHQWLFDWLRQ&RGH3URWHFWLQJLQWHJULW\RI6HTDQG1$6PVJ
6HTXHQFH1XPEHU/6%VRIFRXQWHU
1$6SODLQPHVVDJH(QFU\SWHGLILWLVVHFXULW\SURWHFWHG
Fig. 10. Format of NAS security protected message Fig. 11. Part of the output when running LTEFuzz (tester side)
9
Initially, 5G will utilize the LTE core network (EPC).
15

APPENDIXC
COMPLETE RESULTS OF LTEFUZZ
TABLE IV. T HE LIST OF TARGET CONTROL PLANE MESSAGES AND THE RESULTS OF DYNAMIC TESTING (PROBLEMATIC CASES IN BOLD)
Classication of behavior upon receiving test cases:Problematic (1, 2, 3), Benign (4)
UL:Uplink,DL:Downlink,P:Plain,I:Invalid MAC,R:Replay
[#]:Reference to problematic cases previously discovered in[#]. All other vulnerabilities are new.
Test messages Direction
PropertyPropertyPropertyProperty
Property 3 Implications
1-1 1-2 (P)2-1 (I)2-2 (R)
NAS
Attach request (IMSI/GUTI) UL 4 1 1 1 - DoS
Detach request (UE originating detach)UL - 1[41] 1 1 - DoS
Service request UL - - 4 2 - Spoong
Tracking area update request UL - 3 3 2and3 - DoS, False location update
Uplink NAS transport UL - 2and32and3 2 - DoS, Spoong
PDN connectivity request UL 4 4 3 3 - DoS
PDN disconnect request UL - 4 3 1 - (selective) DoS
EMM status Both - 4 4 4 -
ESM status Both - 4 4 - -
Attach reject DL 1[8] 1[7] - - - DoS
Authentication reject DL 1[4] - - - - DoS
Authentication request DL 4 - - - 4
Detach request (UE terminated detach)DL - 1[4] - - - DoS
Downlink NAS transport DL - 4 4 4 -
EMM information DL - 1[54] - - - Spoong
GUTI reallocation command DL - 4 4 2 - Spoong
Identity request DL 2[44] 4 4 2 - Information leak
Security mode command DL - 4 4 2[4] - Location tracking
Service reject DL - 1[7] - - - DoS
Tracking area update reject DL - 1[7] - - - DoS
RRC
MeasurementReport UL - 4 4 4 -
RRCConnectionReestablishmentRequestUL - - 4 4 -
RRCConnectionRequest UL 1and2 - - - - DoS, Spoong
RRCConnectionSetupComplete UL 2 - - - - Spoong
CounterCheck DL - 4 - - -
LoggedMeasurementsConguration DL - 4 - - -
MasterInformationBlock DL 2 - - - - Spoong
Paging DL 1[4] and2 - - - - DoS, Spoong
RRCConnectionReconguration DL - 2 3 4 - Spoong, Eavesdropping
RRCConnectionReestablishment DL - 2 - - - Spoong
RRCConnectionReestablishmentRejectDL - 1 - - - DoS
RRCConnectionReject DL 1 - - - - DoS
RRCConnectionRelease DL 1[8] - - - - DoS, Spoong
RRCConnectionSetup DL 2 - - - - Spoong
SecurityModeCommand DL - 4 4 4 2 Eavesdropping
SystemInformationBlockType1 DL 2[4] - - - - Spoong
SystemInformationBlockType10 / 11 DL 2[4] - - - - Spoong (Public warning)
SystemInformationBlockType12 DL 2[4] - - - - Spoong (Public warning)
UECapabilityEnquiry DL 2 - 2 2 - Information leak
UEInformationRequest DL - 4 - - -
16