Detailed information of Vulnerabilities

Specification: TS 24.301 v9.1.0

Weakness Description:

The conflict description between subclause 4.4.2.3 and 4.4.4 related to the integrity protection of NAS messages may mislead developers that NAS messages specified in subclause 4.4.4 and 4.4.5 can be sent not integrity protected even though the secure exchange of NAS messages has been established by the network. These messages include Identity Request, Authentication Request, Authentication Reject, Attach Reject, Detach Accept, Tracking Area Update Reject, Service Reject, Attach Request, Identity Response, Authentication Response, Authentication Failure, Security Mode Command Reject, Detach Request, Tracking Area Update Request.

Mitigation:

Correct the misleading descriptions in TS 24.301.

Verification:

This weakness is verified through a prior research work of Kim et al.[1].

Kim et al. found an implementation vulnerability that Tier-1 commercial carrier networks receive the crafted plain NAS Attach Request messages after EPS security context is exchanged, which further leads to victim UEs being out of connections (see Section V-B[1]). This implementation error is exactly what the SR-CR (C1-101168) is going to avoid. The SR-CR (C1-101168) was released on 2010/03/31. However, the confirmation on the commercial carrier networks happened around 2019, which is estimated by the paper publishing time. So through it, we verified that after the SR-CR was released, the vulnerability the SR-CR (C1-101168) fixing still existed in the real world for about 8.7 years.

Specification: TS 33.401 v8.5.0

Weakness Description:

Partial native EPS security context existing too long would lead to security problems. For example, when UE shares a current EPS security context with MME and a non-current partial native security context:

1) if the NAS Security Mode Command for a partial native EPS NAS security context fails, the partial context is still kept in UE and MME. According to the current specification, the value of the NAS COUNTs of this partial context is 0;

2) then UE mobility to UTRAN and HO to EUTRAN again, now the current security context is the mapped EPS security context, and MME decides to activate the partial native EPS security context;

3) MME sends a NAS SMC to activate the partial native security context, the NAS downlink COUNT value of this NAS SMC would repeat (e.g., is 0). If an attacker intercepts the last NAS SMC for the same partial native security context, and apply a replay attack, then it would make the UE and MME use different security context.

Mitigation:

After the NAS SMC message is sent for that partial native security context, the NAS COUNTs for that partial native context are increased for each following sent NAS message.

Verification:

This weakness is verified by an academic paper of Hussain et al.[2].

In the academic paper[2], Hussain et al. found that none of the four major US carriers make the NAS SMC message replay-protected, which is exactly what the SR-CR (S3-091802) is going to fix. Exploiting the weakness, Hussain et al. further designed an attack to locate a target UE (see Section IV-A[2]). Such discovery on commercial carriers happened around 2018 year, which is estimated by the paper publishing date, as well as the SR-CR (S3-091802) was released on 2009/12/18. Through it, we verified the weakness described in the SR-CR (S3-091802) was still existing in the real world, even after the SR-CR was released for about 8 years.

Specification: TS 24.301 v9.1.0

Weakness Description:

This is an inconsistency between Rel 8 UE and Rel 9 UE behaviors.

Rel 8 only requires that the UE shall reset the uplink NAS COUNT counter, not mentioned resetting the downlink NAS COUNT counter. However, Rel 9 requires resetting both uplink and downlink counters, which may lead to a replay attack: the network (or an attacker) can replay the SMC messages within the first SMC and the UE will accept them, which is against Stage 2 security requirement (accepting an integrity-protected SMC with a given DL NAS COUNT only once).

Mitigation:

Remove the reset of the DL NAS COUNT to align with Rel 8 UE behavior.

Verification:

This weakness is verified through a prior work of Hussain et al.[2].

Here we use the discovery of Hussain et al. to verify this weakness in the real world. This SR-CR (released on 2010/03/31) fixed a misalignment weakness in the specification, that would lead UEs to re-accept a NAS SMC with the same DL NAS COUNT. And in the 2018 year (which is estimated by the paper publishing time), Hussain et al. discovered that four major US carriers would accept the replay NAS SMC messages (see Section IV-A[2]), which is exactly what the SR-CR is going to avoid. So, through the vulnerability confirmation on real carriers reported by Hussain et al., we verified the weakness existed in the real world for about 7.7 years after the SR-CR was published.

Specification: TS 24.301 v12.2.0

Weakness Description:

There is an attack going as follows: a rogue mobile (or a small set of such mobiles) listens to all Paging requests in a location/tracking area and responds more quickly than the intended recipient. This will prevent the latter from receiving the Paging for the following reason: when the rogue mobile responds before the intended recipient, the MME will consider the Paging procedure completed, and the incoming call is lost. And even if the MME repeated a Paging request, the rogue mobile could do the same trick again. In this way, a whole tracking area could be prevented from receiving Paging as long as the rogue mobiles were active.

When the MME pages the UE with the GUTI, then the UE is expected to respond with an integrity-protected Service Request. However, the rogue mobile is unable to provide the correct integrity protection. So, the attack could therefore be thwarted if the MME just kept the paging timer running, when an incorrectly protected Service Request was received and continued waiting for a correct response.

Currently, when Service Request and Extended Service Request fail the integrity checking or are not integrity protected, the only MME handling is to drop the message and reject the message. So the above attacks would be successful.

Mitigation:

Modify the MME reaction to check the integrity protection of the received response prior to stopping the timer. Specifically, clarify that the reject message MME sending means SERVICE REJECT message, and in this case UE context is unchanged.

Verification:

This weakness is verified through a proir work of Chen et al.[3].

Chen et al. reported that they performed the attack successfully on a commercial carrier called China Unicom (see Section IV-B), and the attack is exactly what the SR-CR (C1-135219) described. And this paper[3] was published in 2021 while the SR-CR (C1-135219) was released on 2013/12/20. So, through the vulnerability reports from Chen et al., we verified that the vulnerability the SR-CR (C1-101252) fixing still existed about 7 years later in the real world after the SR-CR was published.

Specification: TS 24.301 v12.4.0

Weakness Description:

In some situations, it could happen that the real UE is sending a Service Request that is not properly integrity protected due to the security context mismatch between the network and the UE. In such cases, MME will send Service Reject to the UE but it may not have stopped the timer waiting for the valid paging response. Real UE may resort to sending an Attach Request as a result. So if the MME hasn't stopped the paging timer, there is a possibility for collisions between Attach Request and timer T3413. The current specification lacks the description to it, which may cause unexpected implementations.

Mitigation:

Clarify MME behavior when there is a collision between T3413 and Attach Request message. Specifically, the MME should progress the AAttach procedure and stop timer T3413 only if the Attach Request is successfully integrity protected.

Verification:

This weakness is verified through a prior work of Chen et al.[3].

In 2021, Chen et al. found a DoS vulnerability in a commercial network called China Unicom: when a malicious UE issues a crafted plain Attach Request message within the victim UE's ID to MME once sniffing a target Paging message before the intended UE (victim UE) replies, the victim UE will lose the network connection (see Section IV-B). If the network implementation follows the specification updated by SR-CR (C1-141405), the attack would not be performed successfully. And this vulnerability confirmation date (2021, which is estimated by the paper publishing time) is much later than the SR-CR (C1-141405) releasing time (2014/06/27). So through it, we verified the vulnerability was existing in the real commercial carrier after the SR-CR was released for around 6.5 years long.

Specification: TS 24.301 v8.3.0

Weakness Description:

This is a design issue. The current specification allows UE to receive a Detach Request message from MME without integrity protection, which is incorrect because 3GPP found that there is no scenario in which Detach Request is sent by the network without integrity protection. So, if the developer implementation follows the specification design, the UE would be vulnerable to a DoS attack where a malicious eNB can detach the UE from the network by sending a not integrity protection Detach Request message.

Mitigation:

Remove the Detach Request message from the list of NAS messages which the UE is allowed to process without integrity checking.

Verification:

We verify this vulnerability through both a prior work of Chen et al.[3] and our experiment.

In 2021, Chen et al. found that a Detach Request message without integrity protection from a rouge eNB would interrupt the service of the UE (Google Nexus 6P) (see Section IV-B), which is the vulnerability introduced by the SR-CR (C1-094446) exactly. However, the vulnerability has been fixed by the SR-CR (C1-094446) on 2009/12/17 already. So, by the report from Chen et al. that the vulnerability existed on Google Nexus 6P, which was released on 2015/09/29 at first, we verified the vulnerability was still existing for about 5.7 years long after the SR-CR was released in the real world.

Furthermore, we updated our testing mobile phone (Google Nexus 6P) to the latest version and performed the attack again on 2021/10/01. And we found the attack still could be exploited successfully, which revealed a longer attack window (11.7 years) for this vulnerability.

Specification: TS 24.301 v8.3.0

Weakness Description:

SA3 decided that a reject message, which causes the CSG list on the UE to be modified, shall only be sent after the start of NAS security. The UE shall discard any message modifying the CSG list if it is not integrity protected. However, the TS 24.301 is not consistent with it, which allows UE to receive a reject message with EMM Cause #25 without integrity protection. This cause will remove the CSG ID of the cell where the UE has sent the Attach Request message from the allowed CSG list. So, if developers follow the TS 24.301 description, the implementation will violate the SA3 security requirement.

Mitigation:

Clarify that the reject message with EMM cause value #25, which might remove entries from the allowed CSG list, must be received integrity protected. The network only sends a reject message that contains the EMM cause value #25 after the network has activated the integrity protection.

Verification:

We verify this vulnerability through both a prior work of Yu et al.[4] and our experiment.

Yu et al. found that when a malicious eNB sent TAU Reject with EMM cause #25 without integrity protection to iPhone 6sp, the iPhone 6sp would accept it and would not try to connect the network until the device rebooted or the USIM card reinserted (see Section V-C), which is exactly the vulnerability fixed by SR-CR (C1-095712). The first version of iPhone 6sp was released on 2015/09/19 while the SR-CR (C1-095712) was published on 2009/12/17 early. So through it, we verified that the vulnerability fixed by SR-CR (C1-095712) still existed for 5.7 years after the SR-CR was published in the real world.

Moreover, we updated our testing phones (Samsung Galaxy S10, Google Pixel 3, Google Nexus 6P) on 2021/10/01 to their latest versions. And we performed the above attacks on the three phones successfully, which revealed a longer attack window (11.7 years) for the vulnerability.

Specification: TS 24.301 v10.3.0

Weakness Description:

There is a design issue that when the UE receives a reject message with EMM cause #35, the UE shall not consider the USIM as invalid, instead, the UE shall perform PLMN selection. This issue will lead the UE to be out of service for an unnecessary long time.

Mitigation:

Clarify that if a UE receives the EMM cause #35, it shall perform a PLMN reselection.

Verification:

We verified the weakness through the work of Yu et al.[4] and our experiment.

Yu et al. found that the reject message with EMM cause #35 from a malicious eNB will lead UEs (including Honor 9, M5 Note, iPhone 6sp) to be out of service for a long time, which is exactly exploiting the vulnerability fixed by SR-CR (C1-112809). And the three phones' first release dates are 2017/06/16 (Honor 9), 2016/12/01 (M5 Note), and 2015/09/10 (iPhone 6sp) respectively, which are all much later than the date the SR-CR publishing (2011/09/28). So through it, we verified that the vulnerability fixed by the SR-CR still existed in the real world after the SR-CR was released for a long time.

Furthermore, we updated the Google Pixel 3 to its latest version on 2021/10/01. And we performed the above-mentioned attack successfully too, which verified the vulnerability again and revealed a longer attack window (10 years).

Specification: TS 36.331 v9.2.0

Weakness Description:

Since the UEInformationResponse message carries the sensitive information RLF report, the message should not be sent by the UE before the activation of AS security context. However, this was not clarified in the specification. So if the developer does not implement the security protection, the sensitive information will be compromised.

Mitigation:

Clarify the UEInformationResponse message can not be sent prior to security activation nor unprotected after security activation.

Verification:

We verified the weakness through a prior work of Shaik et al.[5].

In 2006, Shaik et al. reported that major LTE baseband vendors failed to implement the security protection, which is exactly the SR-CR (R2-103442) provided, and by exploiting the vulnerability attackers could determine a subscriber's precise location. The SR-CR (R2-103442) was released on 2010/06/18, which is about 5.5 years earlier than the discovery date on the commercial vendors (2006, estimated by the paper publishing time). So through it, we verified the vulnerability fixed by the SR-CR (R2-103442) still existed after the SR-CR was released for a long time.

Specification: TS 24.301 v12.0.0

Weakness Description:

There is a design issue. When a reject cause #25 is received for registration update reject message or service reject messages, the mobile has first to decide if that reject message is integrity protected or not integrity protected. If that reject message is not integrity protected, the mobile shall discard that message. However, in the specification, the corresponding guard timer for the mobility management procedure is stopped immediately upon receipt of such reject messages before checking if it is a reject cause #25 and if such a reject message is integrity protected. So, if developers follow the specification, they may wrongly stop the guard timer and strop the procedures incorrectly.

Mitigation:

Clarify in the specification that if a registration update reject or a service reject is received that is not integrity protected and if such a reject message is of reject cause #25, then the guard timer for that mobility management procedure is not stopped.

Verification:

We verify this vulnerability through both a prior research work of Yu et al.[4] and our experiment.

Here the discovery of Yu et al. that a TAU Reject with EMM cause #25 without integrity protection from a rogue eNB would lead iPhone 6sp to be out of service until the device has been restarted or the USIM card has been reinserted (see Section V-C), was utilized by us to verify the weakness of the SR-CR (C1-132662). If the developers implemented following the SR-CR (C1-132662) suggesting, the attack would not be performed successfully. And the iPhone 6sp was released on 2015/09/19 for the first time while the SR-CR (C1-132662) was published on 2013/06/27. So through the reports from Yu et.al, we verified the vulnerability fixed by SR-CR (C1-132662) was existing after the SR-CR was published in the real-world commercial phone.

Moreover, we updated our testing phones (Samsung Galaxy S10, Google Pixel 3, Google Nexus 6P) on 2021/10/01 to their latest versions. And we performed the above attacks on the three phones successfully, which verified the vulnerability again and revealed a longer attack window (8.2 years).

Specification: TS 24.301 v14.3.0

Weakness Description:

Previously, 3GPP ignored repairing the weakness that an attacker can interrupt a target victim UE's service by spoofing the victim to send Detach Request message to MME without integrity protection. At that time, 3GPP believed that it did not appear very likely that someone would take the efforts to listen in on the NAS signaling in a cell and operate a manipulated UE just for the purpose of detaching other subscribers. Moreover, in the worst case, this kind of DoS attack would be detected and alleviated when the UE performed the next normal or periodic TAU or when the UE requested some MO service.

However, the situation has changed, because it may take longer to detect and repair the issue when the UE is used for MTC/CIoT. The periodic update timer values are up to 14 days between the UE and the network. Some of the devices may send MO user data with a low frequency of only once every few weeks. But on the other hand, the UE may be required to stay attached in order to be reachable for the application server. Additionally, due to the higher density of devices per cell, it has become easier to perform the attack successfully even by picking the S-TMSI values at random.

Hence, 3GPP decided to fix the weakness.

Mitigation:

Establish the rules for the handling of a Detach Request message failing the integrity check when a current EPS security context exists and the secure exchange of NAS message has not yet been established.

Verification:

We verified the weakness through a prior research work of Kim et al.[1].

In 2019, Kim et al. found an implementation vulnerability that Tier-1 commercial carrier networks receive the crafted plain NAS Detach Request without integrity protection, which further causes the victim UEs to be de-registered (see Section V-B). The vulnerability is exactly what the SR-CR (C1-172658) was going to fix. However, the vulnerability confirmation date (2019, estimated by the paper publishing time) is much later than the SR-CR releasing time (2017/06/16). So from it, we verified that the vulnerability fixed by the SR-CR (C1-172658) existed in the commercial carrier networks after the SR-CR was released.

Specification: TS 24.301 v13.3.0

Weakness Description:

Timer T3245 is used to reconnect the network. When the T3245 expires, the "forbidden PLMN list" has to be deleted. However, it was not mentioned at the starting of the T3245 when a PLMN id is added to the forbidden PLMN list in the TS 24.301. This unclear specification will cause the UE to lose the service for a longer time than it would be necessary.

Mitigation:

Clarify the T3245 requirements in cases when a new value is added in the forbidden PLMN lists.

Verification:

We verified the weakness by both a previous work of Yu et al.[4] and our experiment.

Yu et al. found a vulnerability in Honor 9 that an Attach Reject with EMM cause #14 would cause the UE to be out of service for a long time until it switches back from the airplane mode, which indicates that the UE does not start the T3245 after receiving the reject message as the SR-CR (C1-154699) requires. And the Honor 9 was published on 2017/06/16 for the first time while the SR-CR was published on 2015/12/18. So through it, we verified that the vulnerability existed for 1.4 years in the commercial mobile after the SR-CR was released.

Specification: TS24.301 v13.4.0

Weakness Description:

This is a technical vulnerability that can cause DoS attacks against UEs with high impact.

The current UE behavior of processing NAS reject messages without protection can result in DoS attacks caused by malicious networks. One of the examples is as follows: the UE can send a TAU Request message, which is integrity-protected using the existing NAS security context but not encrypted. As a result, a rogue eNB can decode it and respond with a TAU Reject message including the EMM cause #7 without integrity protection. According to the current specification, this reject message will be processed by the UE, which reacts on the indicated rejection cause by deleting all existing EPS context. Furthermore, the UE updates the status to EU3 ROAMING NOT ALLOWED and considers the USIM as invalid for EPS services until it is rebooted or USIM is reinserted.

Mitigation:

Add a clarification that when the UE receives the reject messages without integrity protection, the UE shall start a timer and act depending on the received EMM cause code value.

Verification:

We verified the vulnerability through both a prior work of Yu et al.[4] and our experiment.

In 2019, Yu et al. found the vulnerability fixed by the SR-CR (C1-161448) on real devices Honor 9 and M5 Note, which were released on 2017/06/16 and 2016/12/01 for the first time respectively. However, the date of patching the vulnerability by the SR-CR (C1-161448) is earlier than the mobile releasing time, which is 2016/03/18. So through the vulnerability confirmation on real devices of Yu et al., we verified that the vulnerability fixed by SR-CR (C1-161448) still existed in the real world after the SR-CR was released.

Moreover, we updated our testing mobile phones (Samsung Galaxy S10, Google Pixel 3) to their latest version on 2021/10/01 and performed the attack successfully too, which again confirmed the vulnerability fixed by the SR-CR (C1-161448) as well as revealed a longer attack window (5.5 years) of the vulnerability.

Specification: 33.401 v13.3.0

Weakness Description:

This is a design issue. Some attacks have been discovered on LTE that allow an attacker to modify IEs of Attach Requests (that do not pass the integrity check at the MME). This may result in a UE attached to the network in a way it was not requesting, e.g. attached for SMS only. In another word, this may lead to a bidding-down attack.

Mitigation:

Add a mitigation method in the specification. Specifically, the UE will calculate a hash of any Attach or TAU Request that it sends to the network. If the Attach or TAU Request fails integrity check, then the MME calculates the hash of the message it received and sends the hash to the UE in the SMC message. If the SMC message successfully checks at the UE, the UE then compares the hash it calculated against the hash it received. If these are different, the UE can identify the attack.

Verification:

We verified the weakness through our experiment.

Due to the ethical constraints, we could not exploit the weakness in the commercial carrier's network to verify the presence of the vulnerability. So we used a non-intrusive approach, by inspecting the downlink traffic from the core network to the UE. Specifically, if the carriers fix the vulnerability introduced in the SR-CR (S3-161217), a HASH_MME value should be included in the downlink SMC messages after the network receives a plain Attach Request. However, in our experiment, we found three major commercial carriers do not perform the protection. When we sent an Attach Request without integrity protection to them, we could not find the hash value in the SMC from all of them. This experiment results implicitly indicated that the vulnerability still existed in the real commercial carrier networks.