Touching the Untouchables

Dynamic Security Analysis of the LTE Control Plane

Hongil Kim, Jiho Lee, Eunkyu Lee, and Yongdae Kim

KAIST

Overview

Long Term Evolution (LTE) is a standard telecommunication technology adopted by lots of mobile network operators (MNOs) recently. It not only provides faster data transmission with lower latency but also ensures high reliability and robustness against unexpected failures. In this research, we investigate potential problems of the control plane procedures in operational LTE networks based on dynamic testing method in both uplink and downlink direction.

Simply speaking, what we tried to check is whether LTE core networks and baseband chipsets are handling exceptional cases correctly. To do this, we systematically generate LTE messages non-conforming to 3GPP standard, and validate the responses from the test target (core network, baseband). We conclude that unfortunately exception handling has not been correctly for cellular networks. Note that LTE core will be used for 5G NSA (Non Stand Alone). Therefore, our framework can be directly applicable to 5G NSA. In addition, since our framework is general, it can be easily extended to 5G SA (Stand Alone), when 5G SA devices become available.

Testing approach

The proposed approach, named "LTEFuzz", consists of three main steps to systematically conduct dynamic security testing in a semi-automated way.

  1. Extracting security properties: First, we extensively analyze the LTE standards of the control plane procedures by 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 & Executing 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 specified rules of target protocol messages and its fields for each property (see the paper for the details). Then, we send our test cases to the target network components utilizing open source LTE implementations (srsLTE for uplink and openLTE for downlink).
  3. Classifying problematic behavior and construct attack scenarios: When executing the test cases, we need to determine which responses and state changes on the side of the mobile device 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 device side when the test case is executed.

Results

From a dynamic test on two Tier-1 MNOs and commercial mobile devices, we uncovered 51 vulnerabilities (36 new and 15 previously known) across different target network components and device vendors. These findings are categorized into five types as follows:

  • Unprotected initial control plane procedure
  • Improper handling of crafted plain requests
  • Improper handling of incorrectly integrity protected messages
  • Improper handling of replayed messages
  • Mandatory security procedure bypass

Our findings were interesting in two respects: (1) even within a single MNO, two core network components (possibly from different vendors) have different vulnerabilities, and (2) two core network components from a single vendor (but deployed in two different MNOs) have different vulnerabilities.

Following is a summary table of our findings. Note that the findings belong to property 1-1 are specification (standard) problems. Others belong to property 1-2, 2-1, 2-2, and 3 are resulted from implementation and configuration flaws of the affected components.

  • Description of the properties
    • Property 1-1 checks whether the plain messages which are allowed by specification could be exploited by an adversary.
    • Property 1-2 checks whether the messages are accepted in plain although the specification mandates that the integrity protection of those messages are necessary.
    • Property 2-1 checks whether the receiving entity correctly verifies the integrity of the received messages.
    • Property 2-2 checks whether the receiving entity allows messages with previous sequence number.
    • Property 3 checks whether the mandatory security procedure (such as authentication and security mode command procedure) can be bypassed by an adversary.
  • B: Benign case, FLU: False Location Update, P: Plain, I: Invalid MAC, R: Replay
LTEFuzz findings

Attacks

An adversary who has the knowledge of these vulnerabilities can perform following attacks (see the paper for the details) :

  • BTS resource depletion attack: deplete connection resource of a (small) cell
  • Blind DoS attack: deceive user's connection info. to blindly block incoming services
  • Remote deregistration attack: detach legitimate users
  • SMS phishing attack: send spoofed SMS message
  • AKA Bypass attack: eavesdrop and manipulate user data traffic

Note that an adversary does not need any valid smartphones or other users' cryptographic keys to connect to LTE networks. Instead, a Software Defined Radio (SDR) device (for LTE signal transceiver) with some (public) information of configuration in operational LTE networks is required to perform the attacks.

Q&A

Q1. Is dynamic testing of a commercial network allowed to researchers?

Probably not. Researchers should comply with any special legal requirements in their jurisdictions. Fortunately, for the purpose of inspecting and validating the vulnerabilities, two MNOs gave us a permission to conduct dynamic security testing on their testbed.

Q2. Did you responsibly disclose these vulnerabilities?

Yes. We have reported our findings to the corresponding baseband chipset vendors as well as network equipment vendors through the MNOs we conducted our test. For the attacks resulted from specification problem, we have contacted the 3GPP with the Coordinated Vulnerability Discolsure programme and the Fraud and Security Group in GSMA.

Q3. Is there more work to do?

Yes. The vulnerabilities presented in the paper are uncovered from analyzing the responses resulting from crafted malicious inputs in the initial state with no cryptographic keys (i.e. before proper authentication or a complete attach procedure). Therefore, potential vulnerabilities in other states are not covered yet. We are currently working to extend LTEFuzz so that it can uncover potential bugs in multiple state transitions (i.e. stateful fuzzer).

Q4. How to cite this work (paper)?

Please use the following BibTeX entry.

@inproceedings{kim_ltefuzz_sp19,
title={{Touching the Untouchables: Dynamic Security Analysis of the LTE Control Plane}},
author={Kim, Hongil and Lee, Jiho and Lee Eunkyu and Kim, Yongdae},
booktitle = {{Proceedings of the IEEE Symposium on Security \& Privacy (SP)}},
year = {2019},
month = may,
publisher = {IEEE}
}


Paper information