#HITB2023HKT D2T1 - Hacking Into IOS’s VOLTE Implementation

### Overview In this talk, security researchers Hardik and Rajneesh detail an architectural and implementation flaw in Apple's Voice over LTE (VoLTE) stack. The vulnerability affected iOS releases prior to 15.1, as well as iPadOS and watchOS, allowing attackers within a cellular carrier's network to directly reach and attack millions of Apple devices without routing through or being logged by standard telecom billing and call-inspection infrastructure.

### Key Topics - **VoLTE & IMS Architecture**: VoLTE routes voice traffic as data over IP Multimedia Subsystems (IMS) and the Evolved Packet Core (EPC). Handsets establish an Access Point Name (APN) specifically for IMS, initiating registration via SIP over UDP port 5060 before establishing an authenticated IPsec tunnel to the core. - **3GPP/GSMA Specification Deviation**: Standard 3GPP and GSMA guidelines stipulate that once an IPsec tunnel is negotiated between the User Equipment (UE) and the IMS core (P-CSCF), the UE must terminate or close the listening socket on unencrypted port 5060. - **Direct Device Exposure**: In iOS's implementation (specifically within the `CommCenter` framework and `libIPTelephony`), port 5060 remained open and listening on interface `pdp_ip1` even after IPsec establishment. Furthermore, lack of strict traffic segregation at the carrier P-CSCF level allowed arbitrary devices to communicate peer-to-peer over the IMS APN.

### Technical Details - **Test Bed Setup**: The researchers reproduced the issue in a lab environment using Open5GS (simulating RAN/EPC), Kamailio (simulating the IMS SIP server), USRP and BladeRF Software Defined Radios (SDRs) acting as eNodeB/gNodeB base stations, ISIM test cards, Android test devices, and iPhones. - **Reconnaissance & Enumeration**: By scanning IP ranges allocated to the carrier's IMS APN via tools like Nmap, the researchers found that only iOS devices responded on port 5060, revealing millions of vulnerable endpoints. Testing against Android devices (Samsung, Google Pixel) showed that Android correctly closes port 5060 once the IPsec tunnel is active. - **Exploitation & Impact**: - **Caller ID Spoofing & Ringing**: Unauthenticated, crafted SIP `INVITE` packets sent directly to target IP addresses triggered the native incoming call screen and rang devices without legitimate telecom routing or billing records. - **PII Leakage**: Device responses exposed device identities, exact iOS versions, phone numbers (MSISDN), IMEI numbers, and potential IMSI exposure. - **Denial of Service (DoS) & Fuzzing**: Direct SIP traffic floods could tie up the telephony daemon, prevent legitimate incoming and outgoing calls, and expose low-level telephony parsing libraries to direct network-level fuzzing.

### Takeaways & Mitigation Following initial disclosure in March 2021, an early fix attempt by Apple was bypassed, leading to an effective resolution in iOS 15.2 by properly closing socket port 5060 and strictly accepting SIP communication exclusively over the established IPsec tunnel. The researchers emphasized that adhering to core telecom standards is critical, as minor implementation deviations in foundational protocols can leave millions of endpoints exposed to remote, unauthenticated attacks.