because the attack affects all users and degrades the overall per-
formance. The adversary has no access to the cellular network in-
frastructure or other devices. It solely exploits the public available
information when launching attacks. The adversary only has full
control over its own smartphone and a remote server. The phone is
a programmable commodity smartphone, e.g., an Android phone.
The server is a commodity one (without super-powerful computa-
tion or communication capabilities), deployed outside the cellular
network. It is also programmable, and can use any available tricks
over the Internet (e.g., using Tor [2] to hide its identity and location)
to cheat the cellular carrier.
We further assume that all other mechanisms in cellular networks
and at other mobile clients work properly. Therefore, the attacker
cannot leverage improper operations in other components to launch
attacks against MDC. All components function normally without
any compromise, misconfiguration, malware, or intrusion.
In reality, the adversary could be more damaging since exploits
in other components are possible, such as SIM/USIM card hack-
ing [1], authentication protocol vulnerability [9, 26], firewalls mis-
configuration [29, 30], mobile malwares (see [11, 13, 17, 37, 39]),
etc.. For example, the malware installed on the victim phone may
permit the attacker to do what he wants (e.g., keep sending junk
data). It does make it easier to launch an attack. However, MDC
may not hold the main responsibility since service requests do
come from the devices. Instead, we focus on a modest threat model
to show that the exploits in MDC vulnerabilities are readily accessi-
ble. Given this model, the identified security loopholes may trans-
late into realistic attacks, thus exposing practical threats to opera-
tional 3G/4G infrastructures and mobile users. Giving more power
to the adversary only aggravates the incurred damage.
2.2 Experimental Methodology
To validate security loopholes and assess their damage in oper-
ational networks, we design experiments in two major US carriers
(OP-I and OP-II) that together cover more than 50% of US sub-
scribers. We run tests at various locations in five US states on the
west coast, east coast, and midwest. We also assess various network
technologies (4G/3G/2.5G) supported by both carriers. We use
several Android phone models, including Samsung S4/S3/S2/Note,
HTC one and LG Optimus E970. Since we have no access to the
internal cellular infrastructure, we learn their operations from the
standard specification and experimental observations. For mobile
data transfer and its charging, we collect traces from the phones
and our deployed server.
Our experiments are designed to be responsible. We realize that
some proposed exploits and their verification tests might be detri-
mental to operators or other users. Our test was thus conducted with
several guidelines: (1) Actual data usage is kept below the data plan
cap, regardless of being charged or not; (2) Attacks are performed
by using our own phone as the victim; (3) Verification experiments
are restricted via small-scale sampling to confirm vulnerabilities in
real networks. No large-scale tests are performed.
3. SECURITY ANALYSIS OF MDC
We now examine each individual security element in MDC.
Given each element, we analyze its current solution, identify its
security loopholes, deduce its causes, sketch showcase attacks, and
validate them in operational 3G/4G networks. Note that our main
goal is to identify vulnerabilities in MDC. The devised attacks
simply illustrate how easy it is to use known attack techniques to
breach the MDC system. Moreover, large-scale attacks are feasi-
ble, e.g., by exploiting Botnets or using multiple malicious servers.
They can be launched from the Internet, which is beyond control of
cellular operators.
3.1 On Authentication
3.1.1 Current Solution
To ensure authentication, the current 3G/4G networks have
adopted mechanisms at multiple layers of the protocol stack. It
adopts user authentication (Step 1) and IP address authentication
(Step 2), which are performed during the initial attach procedure.
Figure 2(a) depicts the attach procedure. The baseline user au-
thentication (Step 1) is ensured through the Authentication and
Key Agreement (AKA) procedure [7]. Each user obtains a unique
and permanent ID, called international mobile subscriber identity
(IMSI). The confidential IMSI and its related key for user authen-
tication are securely stored in both the SIM/USIM card at the user
side and the Home Subscriber Server (HSS, akin to a database)
at the operator side. When the phone initially attaches to cellular
networks, AKA uses challenge-response based mechanisms to ver-
ify whether its local IMSI matches with the record stored in the
database. A temporary identity derived from IMSI is then used
to set up a secure connection against eavesdropping. Once com-
pleted, IP address authentication (Step 2) is performed through this
secure connection during the bearer activation process. A bearer is
for subsequent data transfer. Specifically, the Evolved Packet Sys-
tem (EPS) bearer is established to enable the connection-oriented
transmission in the 4G network. It is further carried by an underly-
ing GTP-U (GPRS Tunneling Protocol-User Plane) tunnel. During
this process, an IP address is allocated by the gateway, to the UE
through this secure connection. Consequently, the IP address is
authenticated with the UE.
Such IP address authentication is mandatory in cellular net-
works. This is a key difference from the Internet, where such au-
thentication is rarely required. From the charging standpoint, MDC
is thus able to map the charging (via the packet header, e.g., IP ad-
dress) into the authentic user.
3.1.2 Vulnerability Analysis
We discover a loophole that allows for bypassing the above au-
thentication scheme. The root cause lies in neither secure cross-
layer binding nor coordination between control and data planes.
As described above, cellular networks indeed perform control-
plane authentication when assigning an IP address. However, for
packet delivery on the data plane, enforcement of the assigned,
authentic IP address may be missing. The prior authentication is
circumvented when a forged IP address is embedded in the data
packet. MDC further associates its charging only based on the
packet header. Moreover, the current solution lacks secure cross-
layer binding. In cellular networks, data communication spans mul-
tiple layers of the protocol stack. A transport-layer flow uses IP
packet delivery (Layer 3, L3), which is further carried by GTP-U
tunnels (Layer 2, L2). In Step 2, a tunnel ID (that identifies the
GTP-U tunnel) is created by the core gateway and made known
to other gateways. Although data delivery to/from the UE is only
allowed over authenticated L2 tunnel, the L3 IP address carried
by the GTP-U payload is not required for verification. This no-
binding operation results in an authentication-bypass loophole for
the charging process which is based on the IP address. For exam-
ple, as shown in Figure 2(b), when an adversary X forges U ’s IP
address in his data transfer, MDC might charge U but not X.
Note that authentication is critical to both upstream and down-
stream packets. However, authentication bypass vulnerability may
not take effects on downstream packets unless the phone does not