enabling telephony calls over WiFi networks. An Ericsson report [1] predicted that the number of their subscriptions will reach 6 billion in 2024, accounting for 90 percent of all 4G/5G subscriptions. Hence, it appears that IMS systems will inevitably play a decisive role for future call services.

VoWiFi extends the reach of the IMS call service, but, in doing so, enlarges the attack surface compared to conventional voice solutions. Its software-based framework is barely hardened by existing hardware-based security embedded in the telecom modem, and this has serious implications if an adversary succeeds in gaining full control over the phone OS (e.g., root access). In particular, there is a risk that vulnerabilities in VoWiFi may imperil the entire IMS ecosystem.

The software-based VoWiFi support motivates us to study potential vulnerabilities of the IMS call service; notably, the study is based on a responsible methodology that avoids harming any of IMS systems or users in operational cellular networks. Given the constraint of this methodology, we examine only the vulnerabilities that can be validated by our own phones serving as both the caller and the callee, and that do not impede normal operation of the IMS service for other cellular users. To explore the vulnerabilities with great impact, we focus on those which can cause the most dangerous security threats on the call service. They can be derived from the two major threat models which can be validated under the aforementioned constraint. First, the adversary as a cellular user attacks a specific cellular user on his call service; the most dangerous security threats are caller ID spoofing and call DoS (Denial of Service). Second, malicious caller and callee cooperate to attack their subscribed carrier with their call services; since the carrier's normal operation for other cellular users cannot be affected, the most dangerous security threat is to take advantage of the call services to get any unauthorized benefit (e.g., data service).

To launch the above attacks, the prerequisite is to allow the adversary to send fabricated messages to the IMS system; moreover, they shall be considered as valid messages so that the IMS system can react as normal operation. Since it can be extremely challenging to build security associations with the core network and the IMS system from scratch, the most viable way is to hijack the signaling/voice sessions which have been built by the VoWiFi service. It leads us to identify the first vulnerability, no app-level data-origin authentication, which can be exploited to enable the session hijacking. Alarmingly, this vulnerability allows the adversary to arbitrarily manipulate the IMS call operation, and stems from the fact that the standard simply treats the device as one entity of the security associations in the Internet protocol security (IPsec) protection afforded to IMS services. The security parameters are stored within the phone itself, rather than in the IMS app running the VoWiFi session. Hence, if the attack phone is compromised, the security parameters may be easily leaked, thereby enabling the adversary to hijack the VoWiFi signaling/voice sessions and interact with the IMS system on a per-message basis.

By exploiting the session hijacking, we further explore the possibility of the aforementioned security threats, namely, caller ID spoofing, call DoS, and unauthorized service access.

These security threats are possible and the exploration leads us to identify other four IMS vulnerabilities: caller ID spoofing, abusing reliability of provisional responses, no prohibition of concurrent call attempts, and data smuggling over voice session. Specifically, the first two vulnerabilities can result in the caller ID spoofing and call DoS attacks, respectively. Crucially, these attacks require no malware or network information, and need only a knowledge of the victim's phone number.

Moreover, the damage of the attacks can be aggravated by the vulnerability, no prohibition of concurrent call attempts, which allows a single smartphone to attack multiple cellular users simultaneously. The last vulnerability, data smuggling over voice session, enables unauthorized data service over voice session with free of charge. These vulnerabilities are rooted in either operational flaws of the carrier or design defects of the standard. Table I summarizes all the five vulnerabilities, and the corresponding root causes and attacks. 1Operationally, the call DoS attack works only for VoLTE and VoWiFi users located in the same carrier network as the adversary. Furthermore, for any target phone number, the phone may have been temporarily handed over from 4G/5G to 3G. Under these conditions, the phone may play the ringtone when subjected to a call DoS attack, thereby thwarting the desired stealthy nature of the attack. However, it is shown that a determined adversary can circumvent this obstacle by using a stealthy detection method to remotely detect attackable phones at run time (i.e., before the ringtone plays). In particular, a machine learning (ML) approach can be leveraged to explore the signaling message features available for runtime detection and these features can then be incorporated into the attack. 118 The evaluation results show that such an approach enables the 119 attacker to conduct stealthy attacks on the victim with call 120 DoS up to 99.0% of the time.

The identified vulnerabilities and attacks are validated by 122 performing experimental trials in the operational 4G networks 123 of four top-tier carriers across Asia and North America using 124 seven phone brands. The experiments are conducted in a 125 responsible manner such that no harm or disruption is caused 126 to either carriers or cellular users. Specifically, no attempt is 127 made to overwhelm the IMS system by flooding data traffic, 128 or to crash it using malformed signaling messages. Further-129 more, the researchers' phones are used as the victim devices 130 in every case. Having validated the identified vulnerabilities 131 and attacks, a suite of countermeasures is introduced.

The remainder of this paper is organized as fol-133 lows. Section II presents the attack surface and model. 134 Section III describes the details of the identified vulner-135 abilities. Section IV introduces the corresponding attacks. 136 Sections V, VI, and VII present the proposed countermea-137 sures, discussion, and related work, respectively. Finally, 138 Section VIII concludes the paper.

VoWiFi primer. VoWiFi is a cellular VoIP (Voice over 141 IP) service [2] that enables cellular calls over WiFi networks. 142 As shown in Figure 1, for a 4G LTE network architecture 143 with VoWiFi support, the UE (User Equipment) consumes the 144 VoWiFi service by connecting to the core network through 145 the WiFi AP and Internet, while it consumes other services as 146 normal through the LTE base station. The traffic flows of the 147 two types of services reach the core network at the ePDG 148 (evolved Packet Data Gateway) and S-GW (Serving Gate-149 way), respectively. The ePDG enables untrusted non-3GPP 150 access from the Internet and authenticates the UE through an 151 authentication server before establishing an IPsec tunnel to the 152 UE [3], [4]. Within the core network, the P-GW (Public Data Network Gateway) then forwards the VoWiFi traffic between the ePDG and the IMS core. VoWiFi uses SIP (Session Initial Protocol) as its signaling protocol, but with some 3GPPspecific modifications [5], [6]. Specifically, it requires an IMS app installed at the UE to perform registration and mutual authentication prior to VoWiFi start-up based on the IMS-AKA (IMS Authentication and Key Agreement) protocol [7], [8].

The registration procedure derives IPsec ESP (Encapsulating Security Payload) [9] security associations between the IMS app and the core. While IPsec integrity protection over the SIP signaling is mandatory, the confidentiality is not [7].

VoWiFi has a larger attack surface than conventional cellular voice solutions since, whereas traditional IMS services hide all (e.g., CSbased) or part (e.g., VoLTE [10], [11]) of the operations and security functions within the hardware modem, VoWiFi keeps them in its software (including the IMS app and mobile OS).

As a result, an adversary has the potential to learn the service operations from collected packet traces [12] and steal the security parameters (e.g., the security keys) from the software, or the delivery path from the SIM card to the IMS app using a sniffer such as SIMTrace [13]. These possibilities may allow the adversary to hijack the VoWiFi sessions. Having done so, s(he) can gain fine-grained interaction with the IMS core through the exchange of signaling messages. Any design defects of the call flow procedure or state machine can then be exploited to launch attacks on the IMS call service operations.

In the experiments, the victims were mobile users with VoLTE or VoWiFi services. The attacks required only commodity smartphones without any remote access to the victim devices or malware installed on them. The attack phones carried SIM cards with VoWiFi services, and were rooted for full programmability and system data access.

To maximize the attack impact, the WiFi environment was controlled to provide the attack phones with a strong WiFi signal with no interference. Moreover, the carrier networks were not controlled by the attacker and had no compromised facilities. Responsible methodology. The experiments were conducted in a responsible fashion in order to avoid harming any of the carriers or cellular users. For the carriers, no attempt 211 was made to overwhelm the cellular infrastructure or IMS core 212 by flooding data traffic, or to crash the IMS using malformed 213 SIP messages. The main focus was to validate the identified 214 vulnerabilities, not to attack the carrier or cause any damage. 215 Moreover, our own phones were used as the victim phones 216 in order to avoid disrupting real-world cellular users. Notably, 217 while the present tests focused only on attacks against phone 218 devices, the exposed vulnerabilities may potentially open up 219 even more powerful attacks against the IMS core itself.

In this section, we study the vulnerability of the software-222 based VoWiFi support and examine other IMS vulnerabili-223 ties that can be exposed by malicious manipulation of the 224 IMS call service operation. By following the aforementioned 225 responsible methodology, we explore the vulnerabilities that 226 can be validated by our own phone devices and do not 227 have impact on the IMS normal operation for other cellular 228 users. To gain the ability for the malicious manipulation, we 229 first examine whether the VoWiFi sessions can be hijacked. 230 It leads us to identify the first vulnerability, no app-level data-231 origin authentication (V1), which allows the session hijacking. 232 By hijacking the VoWiFi signaling and voice sessions, the 233 adversary can obtain fine-grained control over the delivery of 234 signaling and voice messages with the IMS system.

235 Furthermore, we focus on the vulnerabilities which can 236 cause the most dangerous security threats on the call service. 237 Given the threat model that the adversary, as a cellular user, 238 attacks another cellular user on his call service, the major 239 security threats are caller ID spoofing and call DoS; thus, 240 two vulnerabilities are discovered to cause those two threats, 241 respectively: caller ID spoofing (V2) and insecure reliability of 242 provisional responses (V3). Since these two vulnerabilities are 243 exploited based on the generation of call attempts, the feasibil-244 ity of concurrent call attempts can aggravate attack damage by 245 attacking multiple cellular users simultaneously from a single 246 smartphone; it motivates us to discover another vulnerability, 247 namely no prohibition of concurrent call attempts (V4).

Given the other threat model that adversaries serving as 249 the caller and the callee in a call cooperate to attack their 250 subscribed carrier; under the constraint of the responsible 251 methodology, the security threat with great impact is to take 252 advantage of the call service to get unauthorized services, 253 where the data service can be the major concern. We then 254 examine the existence of the security threat and identify the 255 last vulnerability, data smuggling over voice session (V5).

In the following, we first present the VoWiFi session hijack-257 ing with the first vulnerability (V1), and then introduce the 258 next three vulnerabilities (V2/V3/V4) and the last one (V5), 259 which are explored from the hijacking of the VoWiFi signaling 260 and voice sessions, respectively.

The IMS call service operates with two sessions: signaling 263 and voice sessions. It relies on the signaling session to carry 264 out the call control operation using SIP messages; during the 265 call setup, the voice session is built for the voice delivery they are delivered to the ePDG through the IPsec tunnel and then forwarded to the IMS core. The IMS associates the voice packets with the voice session based on the IP addresses and ports negotiated through the SDP in the preceding SIP messages, and finally forwards them to the other call end.

Note that since the security manner of the voice session is a subset of that of the signaling session, we focus on the hijacking of the signaling session and its success also indicates the feasibility of the voice session hijacking.

Since the VoWiFi signaling session has no app-level data-origin authentication, access is not restricted solely to the IMS app. Thus, when the IMS app relies on the mobile OS to carry out IPsec transport, it may be possible for an adversary to acquire the parameters of the IPsec security associations from the system, and then use these parameters to fabricate valid IPsec/SIP messages [12]. To hijack the session, two additional steps are required. First, the sequence numbers of the IPsec session should be tracked at run time, together with the corresponding TCP sequence numbers. Second, the default ESP padding algorithm [9] should be applied and the associated authentication data produced using the specified hash algorithm and keys. (Note that the HMAC-SHA-1-96 algorithm [16] is used by the carriers considered in this study.)

Experimental validation. Carriers NA-I and AS-I were indeed found to adopt the IPsec transport mode over VoWiFi signaling sessions. In addition, the initial REGISTER message sent by the IMS app included its capable security methods in the Security-Client field, such as the supported IPsec version IPsec-3gpp, the protocol esp, and the mode transport. However, the other two carriers did not enable this mandatory feature and were thus left unprotected.

The feasibility of VoWiFi session hijacking was examined by attempting to use fabricated SIP messages to make a VoW-iFi call. Figure 4 shows a fabricated INVITE message (with the Session Name set to FORGED SIP), and the subsequent SIP messages. The responses of the Trying and Session Progress messages received from the IMS confirm that the forged INVITE message is considered to be valid. A forged PRACK message was then returned to the IMS. Thereafter, OK and Ringing messages were received and the callee phone started to ring. A similar outcome was obtained for Carrier NA-I. As for Carriers NA-II and AS-II, which do not have that

The experimental results

showed that AS-I did not prohibit caller ID spoofing, but Root causes and lessons.

The caller ID spoofing vulnerability is rooted in an operational flaw of the carriers since it can be prevented based on the existing information at the IMS. In particular, the IMS core maintains an established IPsec session in the transport mode with each VoWiFi user, and hence it knows the user identity and call ID. Consequently, it can, in theory, check whether the actual call ID is consistent with the caller ID claimed in the INVITE message. However, AS-I does not have such a function and simply forwards the INVITE messages without first checking the caller ID.

Importantly, an adversary can exploit this vulnerability to launch caller ID spoofing attacks against any cellular user, irrespective of the carrier to which they belong. For example, when a carrier with such a vulnerability is trusted by other carriers on account of its general reputation and size, they will most likely accept any call attempt originating from it on the assumption that it must be genuine. Notably, AS-I is the largest carrier in the Asia country, and hence if it is vulnerable to V2, it seems probable that other carriers may be vulnerable too.

The establishment of an IMS call may fail in the absence of sufficient resources. However, the callee may have been alerted to the call in the meantime. To eliminate this annoying case, a mechanism known as precondition [17] has been introduced to enable resource reservation during the call setup process [15]. This mechanism relies on SIP provisional responses (e.g., Session Progress) and requires the support of a reliability mechanism that acknowledges the responses in order to confirm the reservation. The precondition mechanism is not widely used in Internet VoIP applications, but the 3GPP standard suggests its support for IMS call services [15] in order to maintain a carrier-grade call quality.

To enable the precondition mechanism, the caller sets an option-tag precondition in the Supported header field of the INVITE message, together with another optiontag, 100rel, which indicates the reliability. As shown in Figure 2(a), the callee replies to the INVITE with a provisional response, Session Progress. In this response, the callee confirms a set of service requirements (e.g., the port and session parameters) that are specified in the INVITE SDP (Session Description Protocol), and sets the precondition option-tag. In addition, it commences resource reservation based on the requirements and waits for a reliable alerting indication (i.e., the PRACK message) to alert the user. On receiving the Session Progress response from the callee, the caller also reserves resource at its side and acknowledges it with a PRACK message. After receiving this message, the callee device starts to ring. However, the reliability mechanism of provisional responses may be abused in order to cause the callee to become stuck in the proceeding state of a call session [18]. In this state, the callee can neither accept other incoming calls, nor leave the session, until the PRACK message, which acknowledges the Session Progress, is received, or the session is canceled from the caller end. Thus, for reliability purpose, the callee retransmits the Session Progress message with an exponential backoff timer. When the number of retransmission attempts reaches a certain maximum number, the IMS cancels the session by sending a CANCEL message to the callee.

Both the maximum number of retransmission attempts and the initial retransmission timeout are carrier-specific.

A caller can abuse this vulnerability to prevent the callee from receiving incoming calls without any awareness. The experimental results reveal two important findings.

First, vulnerability V3 also exists at the VoLTE callee for all of the considered carriers and test phones since VoLTE is supported by the IMS core with a similar call operation.

Second, the callee is prohibited from making any outgoing calls during the DoS duration. For example, when using the GUI to dial a call at the callee, the GUI becomes stuck at the dialing page until the DoS duration ends. This negative impact happens for most test phones and is vendor-specific.

Root causes and lessons. The root cause of this vulnerability is a design defect wherein the standard fails to account for the possible negative impacts of the reliability mechanism.

Nevertheless, it is reasonable to enable such a mechanism for two reasons. First, cellular resource is costly compared with that of the Internet. Second, the essential call service must be carrier-grade for the cellular network, and hence it 494 is unacceptable to allow an invalid call to make the phone 495 ring. It appears that the 3GPP standard [15] does not carefully 496 review it in terms of security, and this security vulnerability 497 is also not disclosed in the IETF standard. [17].

498

A caller is allowed to make successive calls to speak over 500 a call while holding the other(s), or to have a conference 501 call [19]. However, concurrent call attempts are prohibited 502 by the system's GUI or call API. In other words, a new call 503 attempt can be issued only when the current one has been 504 answered. Notably, the caller can have concurrent call sessions 505 in the conference call service, but s(he) must make them one 506 by one, and add each callee separately to the conference call. 507

Seemingly, only one call attempt can be made at a time. 508 However, a closer inspection reveals that this may in fact 509 not be the case. For example, if the prohibition is fulfilled 510 only at the end device (i.e., not at the IMS), once the system 511 fence has been bypassed (via V1, for example), it may be 512 possible to generate concurrent call attempts successfully. That 513 is, the adversary may send out multiple INVITE messages 514 concurrently and maintain a session state for each one.

Experimental validation. An experiment was performed 516 to confirm whether or not carriers do in fact prohibit concur-517 rent call attempts. Two concurrent call attempts were initiated 518 from a single caller towards two different callees. The results 519 showed that the SIP messages were properly handled at the 520 caller and resulted in a Ringing status at both callees. 521 A further test was made to determine the maximum number 522 of possible concurrent call attempts from a caller to differ-523 ent callees for each carrier network. Table II presents the 524 corresponding results. It is seen that the carriers differ not 525 only in terms of the number of INVITE sessions they can 526 maintain, but also the response messages they provide in the 527 case that an INVITE is not accepted. For example, Carriers 528 NA-I, NA-II and AS-I reply to an unaccepted INVITE with a 529 provisional response including a failure status, whereas Carrier 530 AS-II simply does not respond.

Root causes and lessons. Vulnerability V4 stems from 532 an operational flaw of the carriers, and suggests that they 533 not only enable concurrent call sessions in order to support 534 conference calls or other services, but may also set number 535 limits. As a result, concurrent call attempts are permitted 536 at the IMS since the acceptance of a valid call attempt 537 (i.e., an INVITE) leads to the initialization of a call session. 538 Even through such an operation is not actually used in practice, 539 and is even prohibited in the call API of the device, it nonethe-540 less represents a possible opportunity for an adversary to abuse 541 This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.

Authorized licensed use limited to: Michigan State University. Downloaded on September 21,2022 at 15:09:02 UTC from IEEE Xplore. Restrictions apply.

the IMS call service. Thus, to mitigate this vulnerability, the IMS needs to differentiate call attempts from established call sessions, and then set appropriate limits on them. At first glance, there seems little reason for an attacker to exploit this vulnerability to carry out data transmission between two device ends since such a capability is already available within many other Internet applications anyway.

Conventionally, there are two major methods for the data transmission. One is to have an Internet server as an intermediary and require both transmission ends to log on to it, whereas the other is to set up a connection between two device ends based on their IP addresses; the latter method requires public IP addresses for the devices to reach each other, but the devices in most WiFi and cellular networks are assigned private IP addresses, and even for those with public IP addresses in some cellular networks, they cannot be reached due to the firewall deployed at the cellular network gateways.

However, given the above vulnerability, the adversary requires only phone numbers for the data transmission; neither the login of an Internet server nor obtaining public IP addresses is required. Moreover, the IP addresses used by mobile devices may change with locations, but the phone numbers do not change, even when using the VoWiFi service aboard. In addition, some carriers have service plans with free intra-network calls, so the data transmission can be free of charge. This vulnerability can thus offer a more convenient way for free data transmissions between mobile devices.

Experimental validation. The vulnerability was investigated by fabricating voice RTP packets and embedding marks in them. The packets were fabricated using the IP addresses and ports of the voice session and the RTP header information obtained from normal voice packets, as observed immediately after call establishment. The fabricated RTP packets were sent 598 to the IMS VIF at one call end and a check was then made 599 as to whether they were subsequently received at the other 600 call end. The results showed that none of the four carriers 601 prohibited data smuggling over VoWiFi voice sessions.

We here take the result of Carrier AS-I as an example. 603 Figure 6 shows successful data smuggling over a VoWiFi voice 604 session from one call end as the sender to the other end as 605 the receiver. Specifically, it is seen that the sender successfully 606 sends an RTP/AMR-WB packet with INJECT NON-VOICE 607 DATA out to the receiver and subsequently receives another 608 RTP/AMR-WB packet with RECEIVE NON-VOICE DATA 609 as an acknowledgement; only the details of the acknowl-610 edgement packet are shown due to space limit. Notably, the 611 fabricated voice packets are successfully forwarded to the 612 receiver only when the corresponding VoWiFi call is ongoing; 613 moreover, those packets need to be formatted in the RTP 614 format for the AMR speech codec [22].

It was observed that while RTP packets are fixed to several 616 sizes, they vary with different carriers. For example, Carrier 617 AS-I uses RTP packets with a size of 63 and 117 bytes, while 618 Carrier NA-I uses packet sizes of 67 and 93 bytes. Thus, 619 further experiments were performed using fabricated voice 620 packets with sizes ranging from as small as 63 bytes to an 621 MTU size of 1500 bytes. The packets of each size were sent 622 out 5 times during an ongoing call. It was found that not all 623 of the packets could pass through the IMS core. For example, 624 the maximum permitted sizes in Carriers AS-I and NA-I were 625 1296 and 1336 bytes, respectively. It should be noted that 626 these packet sizes (obtained from Wireshark) include the Linux 627 Cooked Capture header with a size of 16 bytes, and hence the 628 maximum permitted sizes of the voice IP packets for the two 629 carriers are actually 1280 and 1320 bytes, respectively.

As vulnerability V1, vul-631 nerability V5 stems from the absence of app-level data-632 origin authentication from the IMS core, i.e., it arises from 633 a fundamental design flaw of the standards. Notably, the voice 634 session is not even protected by the IPsec transport mode at 635 the second security level (see Figure 3) since this protection 636 is not mandatory. Even though the voice session is protected 637 against outside attacks by the IPsec tunnel at the first security 638 level, the voice session can still be hijacked at the call ends 639 to transport non-voice data. Since the content of voice traffic 640 does not affect the call operation, and the IMS core simply 641 forwards the packets between the two call ends, the potential 642 damage of any adversarial attack on the voice session may be 643 considered to be negligible, with the result that no additional 644 security defense is deployed besides IPsec tunnel protection. 645

Validating voice traffic can be considered as a remedy for the weak access control of the voice session, but it can be challenging in differentiating between voice and non-voice

A stealthy call DoS attack was devised against telephony users by generating ghost calls. Given only the victim's phone number, the attack prevented the victim's phone from both receiving incoming calls and making outgoing calls. Moreover, the attack was stealthy and did not cause the device to ring or attract the victim's attention in any other way. The details of the attack are described below.

The attack uses V3 as a building block and works only for callee phones using VoWiFi or VoLTE and subscribing to the same carrier as the attack phone.

For simplicity, it is assumed here that the target phones are always attackable. It is noted that this assumption may not hold in real-world networks. Thus, in practical attack scenarios, the attacker must first detect whether or not the phone is actually attackable. An ML-assisted stealthy detection approach for achieving this is presented below in Section IV-B. (see middle panel in Figure 7). However, the experimental results revealed that the INVITE message sent by a non-701 victim before the attack phone sends out this CANCEL message 702 may still successfully arrive at the victim and prevent the next 703 attack INVITE from the attack phone being forwarded by 704 the IMS core. This finding implies that the IMS core queues 705 INVITE messages for a while before denying them.

Given the existence of INVITE queuing at the IMS core, 707 only the first INVITE arriving within the queuing period prior 708 to the CANCEL arrival is considered to be valid and accepted 709 (as shown in the lower panel of Figure 7). Thus, to ensure 710 the success of the follow-on DoS phase, the attack INVITE 711 must be the first INVITE to arrive. In this case, the non-DoS 712 window becomes the time interval between the start time of 713 queuing and the arrival of the attack INVITE. To minimize the 714 size of this non-DoS window, it is desirable to maximize the 715 attack interval, i.e., the elapsed duration between the sending 716 times of the INVITE and CANCEL messages at the attacker, 717 respectively, given that the INVITE is accepted.

718 Static attack interval. In practice, the maximum valid 719 attack interval that can reliably start a new DoS phase depends 720 on the network conditions of the WiFi network, Internet, and 721 cellular network, since varying wireless channel and network 722 congestion affects the arrival times of the SIP messages. 723 However, we discover that carriers generally prioritize VoWiFi 724 traffic to ensure its low-latency delivery and service quality. 725 They utilize differentiated services code point (DSCP) in IP 726 networks and the 802.11e high-priority access category (AC) 727 in WiFi networks. The resulting low-latency delivery not only 728 minimizes the impact of network dynamics on the message 729 arrival times, but also reduces the attack interval.

Experiments were thus performed to gauge the maximum 731 valid attack intervals for Carriers AS-I and NA-I. For each 732 carrier, the attack interval was varied from 0 ms to 600 ms 733 in intervals of 10 ms. The success ratio of each interval was 734 evaluated over 20 runs. The results showed that the maximum 735 values of the attack intervals with a 100% success rate 736 (i.e., valid attack intervals) were 100 ms in AS-I and 50 ms in 737 NA-I, while the minimum ones of those with a 100% failure 738 rate were 490 ms and 290 ms, respectively. one-hour attack, the attack thus required 120 and 300 rounds of the attack period for Carriers AS-I and NA-I, respectively. The results showed that, based on the always-failure case, the upper bounds of the aggregate non-DoS windows were 1.00% and 1.59% time, respectively. Moreover, comparing the adaptive attack with the static attack, in which only the last-line INVITE message was sent, and applying the upper bounds of the static attack (1.30% and 2.00% time, respectively), the adaptive attack was found to perform better with 23.08% and 20.50% gains on the lengths of the aggregate non-DoS durations, respectively. In other words, the adaptive attack caused the victim phone to suffer from call DoS for at least 99.00% (AS-I) and 98.41% (NA-I) of the time. Note that the victim phone did not ring during the experiment, thereby confirming the stealthy nature of the attack.

A further attack was conducted based on the requirement of only one call attempt at a time. In this case, the attack phone sent out a new INVITE only after the existing call session was canceled. We used the phone to launch this simple attack against multiple victims concurrently, where the maximum number of victims depended on the maximum number of allowable concurrent call attempts in the particular carrier network (see Table II). Table III summarizes the DoS times for the various attack cases.

Before launching the call DoS attacks, the attacker needs to remotely detect attackable phones, i.e., phones that are using VoWiFi or VoLTE and are located in the same carrier network. Accordingly, an ML approach was developed to identify the SIP message features the attacker can use to carry out such a detection process. It was assumed that the attacker would perform ML-based identification for each interested carrier based on the call SIP traces collected before launching the attack, and would then perform detection based on the identified features through the course of the attack. The remote detection process should be stealthy (i.e., not cause the target phones to ring) and should also support real-time operation during attacks. It would allow the attack app to detect when the victim phone underwent handoff from VoWiFi/VoLTE to the 3G call service and, if so, to stop the attack immediately.

In general, the attack app needs to know the result of each attack INVITE such that it can take the appropriate action. The result depends on the call state of the target at the moment the INVITE arrives. Three call states are possible; idle, calling and talking, where these states indicate no proceeding of call setup or talking, proceeding with a call setup, and talking in a call, respectively. The attack INVITE succeeds (i.e., is accepted) in the idle and talking states, but

The support-vector machine (SVM) method [23], [24] was 877 then chosen due to the following two reasons. First, the 878 number of the potential features was as many as more than 10; attempts were collected. The collection process was performed using a semi-automatic tool, which for each callee setting (including the call technology/state and carrier) automatically went through the three states with 10 call attempts each time.

Categorization. The ultimate aim of the trace collection process was to detect attackable phones at run time and to obtain the results of each attack INVITE message at the attack app. It was deemed unnecessary to differentiate among all 18 possible combinations of call technologies (3G/VoWiFi/VoLTE), call states (idle/calling/talking), and carrier cases (intra-carrier/inter-carrier). Thus, we can group two sets of the combinations without affecting the need of our goal achievement. Specifically, all of the inter-carrier cases, for which the call DoS attack is not applicable, were grouped into one category designated as "inter-carrier", while the idle and talking states, both of which allow the INVITE to succeed, for each technology were grouped into the other category "ready". The callee in these two states treats new call attempts as incoming calls without difference. Thus, after the grouping process, only 7 categories remained, namely intercarrier, 3G-ready, 3G-calling, VoWiFi-ready, VoWiFi-calling, VoLTE-ready, and VoLTE-calling.

Methodology. 14 features were empirically considered in the SVM feature space, consisting of 10 features extracted from the SIP message content and 4 features which were defined from the patterns of SIP messages. The former features included P-Early-Media, Allow, Session_Name, Bandwidth, etc., and were mainly carried by the non-100 SIP messages, e.g., Session Progress and Ringing. Meanwhile, the latter set of features comprised Trying-PR interval, Message_Flow, etc. The Trying-PR interval indicates the interval between the arrival time of the Trying message and that of its subsequent provisional response (Session Progress or Ringing) at the caller. The underlying rationale for this feature is that the Trying message is always returned immediately by the IMS, whereas the delivery of the provisional response can be triggered by different entities, e.g., the IMS, the SIP/PSTN translation gateway, and the inter-carrier gateway. It may thus result in different values for different call technologies.

To process the features, we converted string values into numerical values to form an input vector using the methods of one-hot encoding [25] and feature hashing [26], whereas the output was the index of those aforementioned 7 categories. We focused on the analysis of Carriers AS-I and NA-I, which have 2400 and 1600 collected traces, respectively; notably, similar findings can be also observed from the small set of traces from the other two carriers. The traces are split into 60% as the training dataset and 40% as the testing dataset.

Since not all the features were useful for the classification, we sought to find out the dominant ones which can give the highest classification accuracy. We did training and testing on a per-carrier basis, because there could be many carrier-specific parameters and operations. We tried all the different combinations of the possible features. For each combination, we trained an SVM model and tested its classification accuracy. Finally, the feature sets with the highest accuracy can be used for the detection. and thus the call technology can be detected after it ends.

• The combined case of VoWiFi-ready and VoLTE-ready 964 can be distinguished from that of the calling case.

• The 3G-ready case results in much larger Trying-PR 966 values than the other cases (see Figure 9). the different categories slightly. Notably, even though the overlap portion between the VoLTE-ready and 3G-ready cases is not small, the two cases can still be reliably differentiated based on the Allow feature.

The few exceptions in the detection reliability for Carrier NA-I can be avoided by applying a judgement based on multiple trials. For example, the inter-carrier, calling, and 3G-ready cases have 97% data in [0.01, 0.57], 98% data in [0.61, 2.06], and 100% data in [2.21, 5.64], respectively, in terms of the Trying-PR feature. Thus, by assuming that each case has a probability ρ of falling within a given range, a threshold setting of θ can be used to exclude the possibility of one case. In particular, at the nth detection trial with m times not in the range, the case can be excluded when (1 -ρ) m ρ n-m < θ.

Based on the findings above for the call information leakage, a stealthy attack was devised for detecting the status of the target phone by sending an INVITE to the target phone and then observing the response. To be stealthy, the attack must prevent the target phone from ringing during the detection process. The absence of a PRACK message in V3 does not suppress the ringtone in the inter-carrier and 3G-ready cases; however, the inter-carrier callee does not ring when the caller cancels its call attempt right after it receives the provisional response. Similarly, for the 3G-ready callee, the ringtone does not sound if the caller cancels its call attempt before receiving the provisional response since the long Trying-PR interval allows the caller to differentiate it from the other cases. Thus, the following two-phase stealthy detection method was devised: (1) intercarrier determination; and (2) call status classification, which detects one of the other three intra-carrier cases. The first phase allows an attacker to exclude inter-carrier phones from the potential attack targets, while the second phase detects the status of the victims at run time during the attack. The two-phase stealthy detection methods for Carriers AS-I and NA-I are summarized in Table V. 2Evaluation. The stealthy detection performance of the developed app was evaluated for both carriers. In each run, the app sent an INVITE to the target phone and then detected the phone status at run time. Seven scenarios were considered: 3G-ready/calling, VoWiFi-ready/calling, VoLTE-ready/calling, and inter-carrier. For each carrier, 25 runs were conducted for each of the first 6 scenarios. In addition, 25 runs were conducted for each carrier in the inter-carrier case. For each run, both the detection output of the app and the given scenario were collected. The results showed that, for both carriers, the app accurately classified the cases into four categories (VoWiFi/VoLTE-ready, 3G-ready, calling, and inter-carrier) with 50, 25, 75, 100 runs, respectively.

An adversary can apply the two-phase detection method to launch stealthy call DoS attacks against a set of valid phone numbers. For example, given several cellular accounts with Carriers AS-I and NA-I, (s)he can use the first phase of the detection process to identify which phone numbers belong to which carrier. For each phone number belonging to one of the carriers, (s)he can then launch a detection-enabled call DoS attack by applying the second phase of the detection method.

The attack operates in two modes, attack and probing, for each potential victim. In the attack mode, the attack app launches the call DoS attack against the victim while continuing to detect its status. It persists with the attack until the victim status becomes 3G-ready, at which point, it switches to the probing mode and periodically probes the victim's status. If the victim switches back to VoLTE or VoWiFi, the attack returns to the attack mode. Note that the calling state does not trigger the mode switch since the call technology cannot be determined.

For evaluation purposes, the second phase of the detection method was integrated into the call DoS attack. For Carrier AS-I, the detection process can be accomplished by a single call attempt, and hence it was enabled for each attack INVITE. Specifically, any attack INVITE which did not produce a non-100 provisional response within 3.0 s after Trying was canceled, indicating that the victim phone was detected to be in a 3G-ready status. For Carrier NA-I, the detection process relies on multiple call attempts. In particular, for each call DoS phase, the attack app used three INVITE messages to perform detection. As discussed earlier, the adaptive attack involves two different types of attack INVITE messages: dynamic and last-line (see Figure 8). To avoid impeding the attack operation, the attack app sent an additional

Adversaries can exploit vulnerability V2 to launch social engineering attacks through caller ID spoofing, in which they pretend to be officers from government agencies, or employees VoWiFi. Such stealthy data transfer is not only convenient for 1112 the attackers, but also highly secure since the data transfer is 1113 protected by the IPsec tunnel built for the IMS services. Even 1114 through the available throughput of the stealthy data transfer 1115 is not large (i.e., several tens of Kbps), it is still sufficient for 1116 the delivery of important text documents.

The stealthy data transfer process described above differs 1118 from the conventional SMS (Short Messaging Service) and 1119 Internet data/messaging transfer services in two key regards. 1120 First, while SMS also requires only the phone number to effect 1121 data transfer, it allows only one-time unidirectional delivery 1122 with a small amount of text per request and may not be free 1123 of charge. Second, Internet data/messaging transfer requires 1124 an Internet server to make a rendezvous between the two 1125 communication ends and requests them to login with their 1126 user credentials. Moreover, data/messaging transfer proceeds 1127 based on the IP address of the two ends, which may change 1128 over the course of the communication between them, whereas 1129 the call end phone numbers remain always the same.

To explore the stealthy phone-number-based data transfer 1131 attack further, an app was developed which allowed for 1132 the input of a responder's phone number and then selected 1133 a file to be delivered to the responder at that number. Since 1134 the attack has to be launched during an ongoing call, the 1135 app also initiated a VoWiFi call attempt with the responder 1136 using fabricated SIP messages based on vulnerability V1. 1137 The app at the responder end replied to the call attempt by 1138 forging SIP messages and then accepted the call based on a 1139 This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.

Authorized licensed use limited to: Michigan State University. Downloaded on September 21,2022 at 15:09:02 UTC from IEEE Xplore. Restrictions apply. Note that it was observed that the data transfer could cause 1207 normal voice messages to be dropped so that the voice quality 1208 could be affected. However, it should not affect the call 1209 quality of other devices in the same carrier network, since 1210 the bandwidth of each voice session is limited by the IMS.

In this section, we proposed a suite of short-term remedies 1213 to address the vulnerabilities described above, and analyzed 1214 their overhead. The proposed remedies are standard compliant, 1215 so they allow carriers and vendors to deploy them in the 1216 current IMS systems. Note that the proposed solutions are not 1217 intended to be long-term fixes for the identified vulnerabilities; 1218 the development of such solutions requires the concerted effort 1219 of carriers, network/phone vendors, and the cellular standard 1220 community based on their practical concerns.

1221 App-level data-origin authentication. Any entity which 1222 exchanges messages with the IMS shall be a legitimate 1223 IMS app so that vulnerability V1 can be addressed; it can 1224 also address V5 by preventing the voice session from being 1225 hijacked. Such data-origin authentication can be achieved 1226 using the current IPsec transport-mode security mechanism, 1227 which is mandatory for the signaling session and stipulated 1228 in the standard [7]; however, the entity of the IPsec security 1229 associations at the end device shall be the IMS app. Moreover, 1230 to prevent IMS session hijacking, the IMS keys used by the 1231 IPsec shall not be leaked outside the IMS app and SIM card. 1232

This component requires two security measures. First, the 1233 IMS app shall embed the IPsec implementation without relying 1234 on the mobile OS such that it can keep the IMS keys safe inside itself. Second, the IMS app shall be authenticated by the SIM card such that it can securely obtain the IMS keys, which are generated by the ISIM (IMS Subscriber Identity Module) module of the card. Having being authenticated, the app can build security associations with the SIM card to effect secure delivery of the IMS keys, thereby preventing the adversary from extracting them with an SIM card sniffer. Note that the SIM card is assumed to be trusted with hardware-based security, and hence the IMS app can still be authenticated even in the event of a compromised or rooted OS.

The major overhead is that the IMS app builds IPsec transport-mode security associations by itself instead of the mobile OS. Specifically, the proposed security measure deals with the IPsec operation in the user space, whereas the current implementation is in the kernel space; however, the IMS app, a system app deployed by the phone vendor, can be given high priority on the resource usage so that the performance of its IPsec operation cannot be sacrificed. Although new security associations between the IMS app and the SIM card are needed, they are built whenever the IMS app starts to run; thus, the call attempt or establishment would not be delayed.

Notably, the embedded IPsec implementation can increase the size of the IMS app and its memory usage. The major overhead of this component lies in the maintenance of multiple call attempt sessions. For the call setup resource, it is similar to the current call service operation, where only the resource needed for a single call is required at any time. Since the callee reacts to each call attempt session individually, no obvious delay can be observed if the callee 1294 can afford the processing of concurrent sessions. When the 1295 number of concurrent sessions increases to a certain threshold 1296 that can deteriorate the processing delay of the callee, it can 1297 adopt some policies (e.g., randomly dropping a session) to 1298 keep the session number below that threshold.

1299 Call limit decoupling. The limit number of established 1300 call sessions shall be decoupled from that of call attempts 1301 for each phone device. Due to conventional phone design 1302 and usage practice, a phone can only make one call attempt 1303 at a time, though keeping multiple concurrent sessions with 1304 established calls is allowed. Herein, it is proposed that the 1305 IMS should consider them differently, instead of treating them 1306 as the same and causing vulnerability V4. In particular, it is 1307 suggested that the carriers can retain the same limit on the 1308 number of concurrent call sessions as currently used, but 1309 restrict the number of call attempts made by each phone to 1310 just one.

The overhead of this component is lightweight and can have 1312 little impact on the call service performance, since the IMS 1313 just needs to maintain two separate counters to restrict the 1314 numbers of concurrent call attempts and sessions. Notably, 1315 maintaining concurrent call sessions has been allowed in the 1316 current IMS system, so it is not considered as the overhead. 1317

1318 Roaming Impact on IMS Vulnerabilities. Vulnerability 1319 V1 exists only in the VoWiFi call service, so it cannot be 1320 exploited when a mobile device roams to use the other cellular 1321 voice solutions (e.g., VoLTE). However, it is not affected 1322 by the roaming between different WiFi networks, since a 1323 mobile device always connects to its home IMS system no 1324 matter which WiFi network it connects. To exploit another 1325 vulnerabilities V2/V3/V4, the adversary as the caller has to use 1326 the VoWiFi call service, similar to V1. For a roaming callee, 1327 which may roam to a visited network with an IMS system 1328 different from its home IMS or to the legacy CS call system, 1329 V2 and V4 can still take effect, since the IMS system of the 1330 caller, where the vulnerabilities are, can forward malicious 1331 call attempts to any roaming call system of the callee. For 1332 the exploitation of V3, the SIP messages generated by the 1333 adversary need to reach the callee device without conversion 1334 between different IMS systems or between the IMS and the 1335 legacy CS call systems, so the adversary as the caller needs to 1336 connect with the same IMS system as the callee; otherwise, the 1337 V3 cannot be exploited successfully. To use V5, both the caller 1338 and the callee have to connect with the same IMS system using 1339 the VoWiFi call service; they are allowed to roam between 1340 different WiFi networks.

Launching Attacks from VoLTE. There are two poten-1342 tial avenues: one is to hijack the VoLTE sessions established 1343 by the phone modem, whereas the other is to established them 1344 based on a customized UE with the software-defined radio. 1345 For the session hijacking, it is almost impossible from two 1346 aspects. First, if the adversary attempts to do session hijacking 1347 outside the modem, the corresponding security parameters 1348 are required, but they are hidden in the modem and hardly 1349 leaked out. Second, if the adversary seeks to take control 1350 of the modem for the session hijacking, some vulnerabilities 1351 This article has been accepted for inclusion in a future issue of this journal. Content is final as presented, with the exception of pagination.

Authorized licensed use limited to: Michigan State University. Downloaded on September 21,2022 at 15:09:02 UTC from IEEE Xplore. Restrictions apply.

of the modem need to be discovered. For the second avenue 1352 with the customized UE, there shall be an IMS client to be 1353 developed on the UE; it needs to have the implementation mechanism performed in a cover channel accessible to only the call parties, while Deng and Peng [53] established a callback session upon each incoming call and then compared the call states of the outgoing and incoming calls, respectively. Finally, Sheoran et al. [54] leveraged the subscription data shared between the EPC and the IMS to carry out spoofing detection. However, despite the contributions of these studies, they are not used in practice due to their inconvenience. SIP and VoIP security. Various security issues relating to the SIP protocol have been identified [18], [55], [56], [57], including eavesdropping, session hijacking, impersonation, message tampering, and DoS attacks. Most of these issues arise as the result of an absence of adequate authentication, confidentiality, or/and integrity functions. While several VoIP detection systems have been proposed to protect against intrusion [58] and DoS attacks [59], none of them provide defense against the vulnerabilities uncovered in this study.

Carriers have deployed the IMS system ever since the launch of VoLTE. The vulnerability of IMS has seldom been questioned since its access by a phone device is protected by hardware-based security. However, VoWiFi removes this security barrier due to its inherent design. This study has thus examined the vulnerabilities of VoWiFi and the corresponding security implications for IMS. It has been shown that the VoWiFi sessions can be hijacked by an adversary and then used to maliciously manipulate the IMS call operation. For example, the adversary can make ghost calls to launch stealthy call DoS attacks against cellular users given only a knowledge of their phone numbers. It has further been shown that a ML-assisted call DoS attack can be used to detect attackable phones at run time without gaining the attention of either the victim or the unattackable phones. Crucially, the security threats identified in this study apply to four top-tier carriers distributed across North America and Asia, respectively, and seven well-known phone brands. As a result, they call for immediate attention from global carriers, device vendors, and the cellular standard community.