This project investigate security implications of mobile data charging, one essential operation to mobile network carriers and users. Our overall research has two main thrusts. The first is to identify security loopholes in the MDC system. We further devise novel attacks that exploit such loopholes and validate them via experiments in operational cellular carriers. The second is to devise defenses that protect from such attacks. These solutions call for concerted effort between the network infrastructure and the mobile device.
A secure MDC should ensure that the right user is charged to the right data volume that (s)he has agreed to consume. That is, it should meet three requirements:
Unfortunately, we identified three vulnerabilities along all three AAA dimensions: authentication bypass, authorization frauds and inaccurate accounting volumes.
L1. authentication bypass : authentication for MDC counts on inherent user authentication and IP address allocation. It indeed ensures that IP address is allocated to an authenticated, specific user. However, the current practice may not ensure its secure binding with its mobile charging ID, so that MDC may use a wrong IP address to determine who should be charged. A specific violation is that IP spoofing was allowed in real 4G/3G networks and some carriers used the spoofable IP address to determine who should be charged.
Figure 1: current authentication solution (a, left) and authentication bypass loophole in MDC (b, right).
As shown in Figure 1(a), the current 3G/4G networks
adopts user authentication (Step 1) and IP address authentication
(Step 2). The baseline user authentication
(Step 1) is ensured through the Authentication and Key Agreement (AKA) procedure. Once completed,
IP address authentication (Step 2) is performed through this
secure connection during the bearer activation process. A bearer is used
for subsequent data transfer. It is carried by an underlying
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 networks.
This is a key difference from the Internet, where such authentication
is rarely required.
However, though cellular networks indeed perform control-plane
authentication when assigning an IP address, enforcement of the assigned,
authentic IP address may be missing in packet delivery on the data plane. The prior authentication is
circumvented when a forged IP address is embedded in the data
packet, as shown in Figure 1(b). A malicious user can spoof the source IP address to fool MDC which further associates its charging only based on the
packet header. In a word, the current solution lacks secure cross-layer binding.
L2. authorization frauds : we find that the current practice did a great job for outbound traffic from the mobile devices, but have limited control on inbound traffic. In fact, the network side deploy firewalls or NATs or border gateways for access control of incoming traffic. However, the current practice leaves the control to the core network only, regardless of whether the connection is tore down or never wanted on the mobile device. By this sense, the network determined whether the traffic should be allowed and push them to the mobile device even without their consent in certain cases.
Figure 2: current authorization solution for inbound traffic (a, left) and authorization frauds in MDC (b, right).
The authorization for MDC concerns charging actions with or
without user content. In 3G/4G networks, it varies for two types of data
transfer: inbound and outbound. The outbound transfer is authorized through implicit user consent
based on authentication. Packets from the authenticated device are sufficient to signify that the UE authorizes the data transfer
and its charging. In inbound data transfer, the UE
is at the last hop to receive data and charging is already performed
upstream. The current practice takes implicit authorization though deploying firewalls and NATs, and even border gateways at the border to the Internet.
The incoming traffic is allowed to pass through only when it matches a valid mapping,
which is set by an outgoing and ?already-authorized? data stream, as shown in Figure 2(a).
However, no proper authorization is in place for the inbound transfer.
The current practice is to invoke onetime
authorization only at the start, but apply soft-state renewal by
data packets during actual transfer. For example, when an inbound
packet arrives at NAT, the mapping between its IP address and the
port number remains valid until timeout (e.g., 5 minutes). However,
once the access is granted, it is largely beyond user control.
By exploit the ?non-expiring authorization,? as illustrated in Figure 2(b), the attacker can inject spamming packets to the victim device.
In this process, we make use of popular mobile applications (e.g., VoIP, MMS) that allow push-based communication model and perform automatic
background operations. This feature can also be exploited to trap the victim.
Here, we disclose two examples using IP spoofing and MMS. More examples can be found in our previous CCS'12 work.
L3. Inaccurate accounting volume : our study revealed that the current practice takes an open-loop view where the core gateway performs data accounting no matter whether the packets have been delivered to the end devices.
As shown in Figure 3, any packets will be "overcharged" if they are counted but not delivered to the end devices. Here, we presents a TTL-based attack. Given a specific TTL, malicious data packets could be able to arrive at the core gateway for data accounting but never arrive at the end devices for data transfer. Mobile users will be charged for data that never been received.
Figure 3: current accounting solution (top) and possible inaccurate accounting with intended or unintended packet loss (bottom)
We have video demos on all the above loopholes and attacks that exploit them.
Due to its threatening damages, other attack demos will be available only upon requests.
Copyright © 2015 MSSN Lab, OSU.
All rights reserved.
Updated on March 24, 2016.