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 - 2019 MSSN Lab, Purdue University. All rights reserved. Updated on Dec 15, 2021.