Hacking Into IOS’s VOLTE Implementation

Hacking Into IOS’s VOLTE Implementation

Speakers: Rajanish Pathak (KATIM); Hardik Mehta (KATIM)

Conference: HITB Phuket

YouTube: https://www.youtube.com/watch?v=07zYupFwtQ0

Overview

In an insightful presentation at HITB Phuket, Rajanish Pathak and Hardik Mehta from KATIM unveiled a critical design flaw within Apple’s Voice over LTE (VoLTE) implementation, impacting iOS devices prior to version 15.2, as well as iPadOS and watchOS. Their talk, "Hacking Into IOS’s VOLTE Implementation," detailed how a fundamental oversight in adhering to established telecommunications standards allowed for direct, unauthenticated interaction with vulnerable devices, bypassing the secure IP Multimedia Subsystem (IMS) core.

The vulnerability, which had reportedly existed since VoLTE’s introduction in iOS in 2017, enabled attackers to enumerate device details, expose Personally Identifiable Information (PII) such as mobile numbers and International Mobile Equipment Identity (IMEI), execute call spoofing, and perform Denial of Service (DoS) attacks. This widespread issue affected millions of devices globally, presenting significant security and privacy risks to end-users and potential for large-scale disruption. The researchers highlighted that while other signaling protocols like SS7 and Diameter receive considerable attention in telecom security, the Session Initiation Protocol (SIP) interface, directly exposed to end-user devices, was critically overlooked.

Pathak and Mehta's meticulous research journey, from initial discovery on a production network to setting up a dedicated lab environment for reproduction, underscores the importance of scrutinizing even seemingly minor implementation details against industry guidelines. Their findings eventually led to Apple issuing a fix in iOS 15.2 and assigning a CVE, but only after an extensive disclosure timeline spanning over a year. This presentation serves as a stark reminder that foundational design adherence is paramount in securing complex modern telecommunications infrastructure.

Background

▶ Watch: Introduction to iOS VoLTE vulnerability (0:00)

VoLTE represents a significant evolution in mobile communication, enabling voice traffic to be transmitted over the LTE (Long-Term Evolution) data network rather than traditional circuit-switched voice channels. This allows for higher quality voice calls, faster call setup times, and simultaneous voice and data usage. The core of VoLTE relies on the IP Multimedia Subsystem (IMS), an architectural framework that provides a standardized way to deliver multimedia services over IP.

The mobile network architecture supporting VoLTE is complex, comprising several key components. The Radio Access Network (RAN), which includes eNodeBs (for LTE) and gNodeBs (for 5G Non-Standalone), provides the interface for user equipment (UE) to connect to the network. Beyond the RAN lies the Evolved Packet Core (EPC), acting as the backbone for data and mobility management. Key EPC elements include the Mobility Management Entity (MME) for user authentication and session management, the Home Subscriber Server (HSS) as a centralized database for subscriber information, the Serving Gateway (SGW) for data traffic forwarding, and the Packet Gateway (PGW) which connects the UE to external networks like the internet and, crucially, the IMS. Policy and Charging Rules Function (PCRF) nodes manage policies and billing.

Within the IMS, several Call Session Control Functions (CSCFs) orchestrate call signaling: the Proxy-CSCF (P-CSCF) acts as the first point of contact for the UE, the Interrogating-CSCF (I-CSCF) queries the HSS for user location and service profiles, and the Serving-CSCF (S-CSCF) handles session control for registered users. Communication between the UE and the IMS core, especially for VoLTE, typically involves specific Access Point Names (APNs) – one for internet access and another, usually IMS, for VoLTE services.

The primary protocols used in VoLTE signaling are SIP and Session Description Protocol (SDP), while Real-time Transport Protocol (RTP) and Real-time Control Protocol (RTCP) handle the actual media (voice) traffic. A standard VoLTE registration flow involves the device sending a SIP REGISTER request to the P-CSCF. The P-CSCF forwards this through the I-CSCF to the S-CSCF, which validates the user with the HSS. For authentication, a nonce (number used once) challenge-response mechanism is employed, leveraging secrets stored on the SIM card. Upon successful authentication, an IPsec tunnel is established between the user equipment and the IMS core, securing all subsequent VoLTE communication.

Historically, security assessments in telecommunications have heavily focused on core network signaling protocols like SS7, Diameter, and GTP. However, the researchers emphasized that SIP, being directly exposed to the end-user device, often receives less scrutiny despite its critical role in establishing and managing calls. This oversight proved to be the Achilles' heel in iOS's VoLTE implementation, as the vulnerability stemmed from a deviation from 3GPP and GSMA guidelines regarding the proper termination of SIP socket connections once the secure IPsec tunnel is established.

Key Findings

▶ Watch: Focus on end-user device attacks via VoLTE (15:00)

The central discovery of Pathak and Mehta’s research was a significant design flaw in Apple’s VoLTE implementation across iOS, iPadOS, and watchOS devices prior to the 15.2 update. The core issue revolved around the SIP port, 5060, remaining open and responsive to incoming, unauthenticated SIP traffic even after the device had successfully registered with the IMS core and established a secure IPsec tunnel for VoLTE communication.

According to 3GPP and GSMA guidelines, once the IPsec tunnel is established between the user equipment and the IMS core, the device should terminate the direct socket connection on port 5060. This ensures that all subsequent VoLTE signaling and media traffic flows securely through the authenticated and encrypted IPsec tunnel, preventing any direct, unmediated interaction with the device’s telephony stack from the broader network. However, the researchers found that iOS devices failed to adhere to this crucial security measure.

This non-compliance meant that an attacker on the same cellular network, or with access to the IMS network, could directly send crafted SIP packets to a vulnerable iOS device. Such direct interaction bypassed the IMS core's authentication, logging, and policy enforcement mechanisms, effectively allowing the attacker to communicate with the target device’s ComCenter library and its libtelephony_iptelephony component without any legitimate registration or authorization.

The practical implications of this flaw were severe and widespread:

1. Device Enumeration and PII Exposure: Attackers could sweep network IP ranges using tools like nmap and identify millions of active iOS devices. These scans revealed not only the presence of iOS devices but also their specific iOS versions and IP addresses. More critically, by crafting specific SIP packets, the attackers could extract sensitive PII, including the device's mobile number, IMEI, and even the IMSI (International Mobile Subscriber Identity), a unique identifier for the subscriber in the network.
2. Call Spoofing: The ability to directly interact with the device's SIP stack allowed attackers to initiate calls on target iPhones, spoofing the caller ID. This could be used for social engineering attacks, impersonating emergency services (e.g., "911"), or creating widespread panic by making millions of phones ring simultaneously in a specific region.
3. Denial of Service (DoS): By flooding devices with SIP packets, attackers could cause the target device to exhaust its resources, rendering it unable to make or receive legitimate calls. This also had the potential for network congestion, impacting other users and the overall VoLTE service capacity.
4. Absence of Logging and Billing: Because the attacks bypassed the legitimate IMS core, there was no record of the malicious traffic in the operator’s logs, nor any billing associated with these interactions, making detection and forensic analysis extremely challenging.

In contrast to Apple’s implementation, the researchers observed that Android devices from manufacturers like Samsung and Pixel correctly implemented the 3GPP/GSMA guidelines. Their connection managers properly terminated the socket connection to port 5060 once the IPsec tunnel was established, preventing direct, unauthenticated SIP traffic from reaching the device. This stark difference highlighted a fundamental design and implementation oversight on Apple's part.

Technical Deep Dive

▶ Watch: Live POC: Call spoofing and device enumeration (18:40)

The technical core of this vulnerability lies deep within the iOS telephony stack, specifically within the ComCenter library and its underlying libtelephony_iptelephony component. This library is responsible for managing all communication aspects on iOS devices, including VoLTE. When an iOS device is powered on and connects to an LTE network, the PDP_ip1 interface becomes active, initiating the VoLTE registration process. The standard SIP port, 5060, is associated with this interface for signaling.

The initial VoLTE registration flow on an iOS device proceeds as expected:

1. Initial REGISTER Request: The device sends an unauthenticated SIP REGISTER packet to the P-CSCF (Proxy-CSCF), which is the first point of contact in the IMS core. This request contains necessary details for the device to attempt authentication on the IMS network.
2. Authentication Challenge: The P-CSCF, upon receiving the unauthenticated request, rejects it and sends back a nonce challenge. This challenge, along with unique identifiers like SSD (Subscription Session Data) or Auth Key (K) from the SIM card and Home Subscriber Server (HSS), is used to compute an authenticated response.
3. Authenticated REGISTER Response: The device computes the response and sends an authenticated REGISTER packet back through the P-CSCF, I-CSCF, and S-CSCF.
4. Session Establishment and IPsec Tunnel: Once authentication is successful, the IMS core responds with a 200 OK status, and critically, an IPsec tunnel is established between the user equipment and the IMS core. This tunnel is designed to carry all subsequent SIP signaling and RTP media traffic securely.

The critical deviation from standards occurs immediately after this IPsec tunnel is established. According to 3GPP and GSMA guidelines, upon successful registration and IPsec tunnel establishment, the direct socket connection to port 5060 on the user equipment should be terminated. This ensures that all VoLTE communication is exclusively routed through the secure, authenticated IPsec tunnel, preventing any direct interaction with the device's SIP stack from external, untrusted sources.

However, the researchers discovered that on vulnerable iOS devices, the socket connection to port 5060 remained open and actively listening for incoming SIP traffic. This meant that an attacker, even without going through the full IMS registration and authentication process, could directly send crafted SIP packets to the device's assigned IP address on the cellular network.

The methodology for uncovering this flaw was straightforward yet highly effective:

1. Network Sweeping with nmap: The researchers used the network scanning tool nmap to sweep an entire IP range of a cellular network. They configured their test bed with specific Mobile Country Code (MCC) and Mobile Network Code (MNC) parameters, which would reflect in the discovered device identities.
2. Identification of iOS Devices: To their surprise, all devices that responded to their nmap scans on port 5060 were exclusively iOS devices. This initial discovery immediately indicated a significant exposure, as Android devices in similar tests correctly did not respond on this port post-registration. They identified millions of such vulnerable iOS devices, each revealing its iOS version and IP address.
3. Direct SIP Interaction: To confirm direct interaction was possible, the researchers crafted malicious SIP INVITE packets. These packets were sent directly to the discovered IP addresses of target iPhones, bypassing the legitimate IMS core.
4. Observed Impact: The target iPhones immediately responded to these unauthenticated INVITE packets, causing them to ring as if a legitimate call was incoming. Packet traces confirmed the flow: an INVITE packet from the attacker, followed by Session Progress and Ringing indications from the victim device.

This direct communication channel had profound implications. It allowed attackers to interact with the device’s telephony component without any billing, tracking, or logging by the telecom operator's core network. The ComCenter library, being directly exposed, could be queried for further PII, including the mobile number, IMEI, and IMSI. Furthermore, by attaching a crafted RTP packet to the SIP backend, the attacker could even inject spoofed audio, effectively conducting end-to-end voice call spoofing. The vulnerability was a classic example of an implementation flaw, where a specification (3GPP/GSMA guidelines) was not fully or correctly adhered to, leading to a critical security bypass.

Demo / Proof of Concept

▶ Watch: Android's correct implementation vs. Nmap discovery (30:00)

The researchers meticulously recreated the conditions for this vulnerability in a controlled lab environment to demonstrate and validate their findings. Their test bed setup was designed to simulate a complete VoLTE network infrastructure, allowing them precise control over network elements and traffic flows.

The lab setup comprised:

• Open5GS: An open-source implementation used to build the RAN (Radio Access Network) and EPC (Evolved Packet Core) components of the mobile network. This allowed them to simulate elements like the eNodeB (for LTE) and gNodeB (for 5G Non-Standalone).
• Chameleon: This acted as a SIP server and simulated the IMS (IP Multimedia Subsystem) infrastructure, including the P-CSCF, I-CSCF, and S-CSCF functionalities.
• SDRs (Software Defined Radios): USRP and BladeRF devices were used to function as base stations (eNodeB/gNodeB), enabling them to establish the cellular connection with test devices.
• Test SIM Cards: These were utilized in the victim and attacker devices to simulate legitimate network subscriptions.
• iPhone Devices: These served as the vulnerable target devices, running iOS versions prior to 15.2.
• Android Device: This was used as the attacker's device. The Android platform offered greater control over network interfaces, allowing the researchers to set up IP table rules and socket rules to forward raw SIP traffic directly onto the IMS APN of their system, bypassing the standard application layer. This ensured that the attack traffic was specifically directed towards the IMS network segment and not the general internet.

During the demonstration, the researchers showcased a live attack scenario. They hooked the iPhone device to observe its network traffic and, from the Android attacker device, sent a crafted SIP INVITE packet directly to the iPhone's IP address. The video clearly depicted the iPhone receiving this unauthenticated INVITE request and immediately starting to ring, mimicking an incoming call. The nmap scan and subsequent SIP INVITE packets revealed the device's iOS version, its mobile number, and the associated country (derived from the MCC and MNC configured in their test bed).

The researchers emphasized that this capability extended beyond a single device. Their initial scans on a production network had identified "millions of devices" actively connected to the VoLTE infrastructure, complete with their specific iOS version details and IP addresses. This illustrated the large-scale enumeration potential of the vulnerability. They also highlighted that by crafting the SIP packets accordingly, it was possible to extract more sensitive PII, such as the IMEI and IMSI, and even potentially perform location tracking. The demo effectively solidified the practical exploitability of the design flaw and the severity of its potential impact on user privacy and security.

Defensive Implications

▶ Watch: Apple's fix and the disclosure timeline (34:30)

The discovery of this critical design flaw in iOS's VoLTE implementation carries significant defensive implications for various stakeholders, including Apple, mobile network operators, and end-users. The primary lesson learned is the paramount importance of strict adherence to established industry standards and guidelines, such as those published by 3GPP and GSMA.

For Apple (and other device manufacturers):

The most direct defensive measure, which Apple eventually implemented, was to correct the SIP socket handling. Specifically, the ComCenter library (or its equivalent) must be updated to explicitly terminate the socket connection to port 5060 immediately after the IPsec tunnel for VoLTE is successfully established and the device is registered with the IMS core. This ensures that all subsequent VoLTE signaling and media traffic is forced through the authenticated and encrypted IPsec tunnel, preventing any direct, unauthenticated interaction with the device’s telephony stack. This fix was rolled out in iOS 15.2, and users are strongly advised to keep their devices updated to the latest available software version.

For Mobile Network Operators (MNOs):

MNOs play a crucial role in securing the wider cellular ecosystem. While the vulnerability was client-side, operators can implement several measures:

• Strict SIP Traffic Validation: The P-CSCF (Proxy-CSCF) within the IMS core should enforce stringent validation rules on all incoming SIP traffic. This includes verifying the source of the traffic, ensuring it originates from authenticated and legitimate IPsec tunnels, and rejecting any unauthenticated SIP packets directly targeting subscriber devices.
• Network Segmentation and Filtering: While 3GPP and GSMA specify segregation of tunnels, MNOs must ensure that this is robustly implemented. Firewalls and intrusion detection/prevention systems (IDS/IPS) should be configured to detect and block suspicious SIP traffic originating from unexpected sources or bypassing the IMS core.
• Enhanced Monitoring and Logging: MNOs should enhance their monitoring capabilities for SIP traffic, looking for unusual patterns, high volumes of unauthenticated requests, or attempts to interact directly with subscriber devices. Comprehensive logging of all SIP signaling, including source and destination IP addresses, can aid in forensic analysis during security incidents.
• Regular Compliance Audits: Conduct regular audits of their network infrastructure and device implementations against 3GPP/GSMA standards, specifically focusing on SIP handling and tunnel segregation, as oversights can lead to widespread vulnerabilities.

For End-Users:

While end-users cannot directly fix such design flaws, they can take proactive steps:

• Keep Devices Updated: Always install the latest software updates for iOS, iPadOS, and watchOS. The fix for this specific vulnerability was included in iOS 15.2.
• Be Wary of Spoofed Calls: Exercise caution with unexpected calls, especially those claiming to be from emergency services or banks, as caller ID can be spoofed. Verify the caller's identity through alternative, trusted channels if suspicious.

General Security Posture:

This vulnerability highlights a broader point about security audits in telecommunications. While core network protocols like SS7, Diameter, and GTP are often the focus of security assessments due to their critical role, the SIP interface—especially its direct interaction with end-user equipment—must not be overlooked. As devices become more integrated with the network core, any deviation from standards in client-side implementations can expose millions of users to significant risks. The incident underscores that even seemingly minor implementation details, when overlooked, can have widespread and severe security consequences. Furthermore, the lengthy disclosure timeline (over a year) emphasizes the challenges in getting critical vulnerabilities addressed in complex ecosystems.

Key Takeaways

• Critical Design Flaw in iOS VoLTE: Prior to iOS 15.2, iPadOS, and watchOS, Apple's VoLTE implementation failed to terminate the direct SIP socket connection (port 5060) after establishing a secure IPsec tunnel with the IMS core.
• Bypassing Security Controls: This oversight allowed attackers to directly send unauthenticated SIP traffic to vulnerable devices, bypassing the IMS core's authentication, logging, and policy enforcement mechanisms.
• Widespread Impact: The vulnerability enabled extensive device enumeration (revealing iOS versions, IP addresses), exposure of PII (mobile numbers, IMEI, IMSI), large-scale call spoofing, and Denial of Service (DoS) attacks on both individual devices and the network.
• Adherence to Standards is Crucial: The flaw stemmed from a deviation from clear 3GPP and GSMA guidelines regarding SIP socket management, demonstrating the critical importance of strict adherence to industry standards.
• Android Implemented Correctly: In contrast, Android devices (e.g., Samsung, Pixel) correctly terminated the SIP socket after IPsec tunnel establishment, preventing similar attacks.
• Overlooked Attack Surface: The focus on core network protocols (SS7, Diameter, GTP) often leads to the neglect of client-facing interfaces like SIP, which can present significant and easily exploitable vulnerabilities. This issue existed since 2017 but was only discovered in 2021.

About the Speaker(s)

Hardik Mehta is a seasoned professional in the security domain, bringing over a decade of experience to his work. As a speaker at HITB Phuket, he co-presented the findings on the iOS VoLTE vulnerability, contributing his extensive knowledge to the technical explanation of the mobile network infrastructure and attack methodology.

Rajanish Pathak is a security researcher whose primary focus lies in the areas of application and Mobile Security. Alongside Hardik Mehta, he elucidated the intricate details of the iOS internals and the specific implementation flaws that led to the VoLTE vulnerability. Both speakers are part of the KATIM team, a company likely involved in secure communication solutions.