[Bug]: UEs can be context released by a second UE without a valid security context

[linouxis9]

Open5GS Release, Revision, or Tag

v2.7.0

Steps to reproduce

Issue found with PacketRusher using the following parameters: sudo ./packetrusher multi-ue -n 1 --loop --timeBetweenRegistration 5000 --pcap output.pcap

If we try to register two UEs with the same SUPI, the first UE's context is being released after the first unauthenticated Registration Request from the second UE, instead of being released after second UE sends an Registration Request with a security context.

Logs

Open5GS - Unexpected UE Context Release.zip

Observed Behaviour

If we try to register two UEs with the same SUPI, the first UE's context is being released after the first unauthenticated Registration Request from the second UE.

Expected behaviour

Instead, first UE's context should be released after second UE valid authentification response or an Registration Request with a security context, else there is a risk of DoS from unauthenticated parties.

eNodeB/gNodeB

PacketRusher

UE Models and versions

PacketRusher

[acetcom]

@linouxis9

Let me first explain why Open5GS implemented it this way. Suppose the UE initially sends an Integrity Unprotected Registration Request, then turns off and on again to connect to the 5GC, and sends an Integrity Unprotected Registration Request again.

Even if the UE turns off and on, the gNB's RAN_UE_NGAP_ID and MME_UE_NGAP_ID are thought to be maintained because they are the context with the 5GC. Therefore, Open5GS was implemented to send a UEContextReleaseCommand.

If the gNB is implemented to delete the RAN_UE_NGAP_ID/MME_UE_NGAP_ID when the UE turns off and on, Open5GS should be modified not to send the UEContextReleaseCommand. I have modified it in the i2786 branch accordingly.

If the latter is correct, I will merge it into the main branch.

Regarding the security issues of @linouxis9, I don't think there is a perfect solution. Since the 5G has introduced SUCI, I think it would be better to solve it by using encrypted-SUCI rather than plain-IMSI.

Please let me know if you have any different idea.

Thanks a lot!
Sukchan

[linouxis9]

Hi Sukchan,

Thanks a lot for sharing your thoughts! The issue as I see it, is that the AMF sends a UEContextReleaseCommand for the authenticated UE (an UE1 with imsi-999700000000001 for example) after a second UE (UE2 with same imsi-999700000000001) sends an Unprotected Registration Request. You can observe in the pcap the NGAP_ID of the UE being released is not those of UE2, but of UE1.
The correct behavior is that AMF should send a UEContextReleaseCommand for UE1 only if UE2 is able to prove its identity. Otherwise, with a crafted SIM card, you could deregister a target user provided you know its MSIN even if you don't know the opc/k.

You are right that this issue is somehow mitigated when using encrypted-SUCI, however if both encrypted-SUCI and plain-IMSI are allowed on the network, I believe this issue will still occur (first UE which used an encrypted-SUCI of imsi-999700000000001, will still get disconnected by a second UE trying an Unprotected Registration Request with a plain SUPI of imsi-999700000000001?).

If the gNB is implemented to delete the RAN_UE_NGAP_ID/MME_UE_NGAP_ID when the UE turns off and on, Open5GS should be modified not to send the UEContextReleaseCommand. I have modified it in the i2786 branch accordingly.

The issue I'm mentioning is not related to a single UE that turns on and off, you are correct that AMF should send a UEContextReleaseCommand in this case, and this should not be modified. The UEContextReleaseComplete is correctly sent (we can observe it a bit latter in the pcap if you look at it).

Thanks a lot as always!
Valentin

[acetcom]

@linouxis9

It seems like we are on different pages right now. We need to narrow this down first.

Let's say one UE turns off and then turns back on to register with the Core. And, the forged UE you mentioned requests registration with the same IMSI.

Is there a way for the 5G Core to distinguish between these two? The reason I mentioned these two issues simultaneously is because the 5G Core cannot distinguish them.

Please let me know if my understanding is wrong.

Sukchan

[linouxis9]

Thanks for your quick reply 😄

Is there a way for the 5G Core to distinguish between these two?

First UE will successfully complete the Authentication Challenge whereas the forged UE won't be able to. I think that's the key difference between these UEs.
So in an example where we only have a single UE which turns on and off, you would only free the old context when the UE was able to successfully pass the Authentication challenge again.

If you still need to clarify my thoughts, please say so. Thanks a lot :-)!

Valentin

[acetcom]

Is there any other 5G core implemented in that way? Normally, when the NG Context and NAS Context are associated in the InitialUEMessage and Registration Request process, it is natural to delete the OLD NG Context at that point. I'm not sure if maintaining one NAS Context and two NG Contexts until it is confirmed whether it is an authenticated UE is against the standard.

[linouxis9]

I think it makes sense to manage two NG contexts, since at first, the two UEs could very well be distinct (until we can confirm if the two UEs are distinct or not). Also, it's not really two full NG contexts that you are managing as the deletion still happen before the InitialContextSetupRequest.
A proprietary 5GC I'm testing PacketRusher against, is implemented that way (UEContextReleaseCommand is only sent after the AuthentificationResponse). I've not yet checked another OSS 5GC for this behavior.
It seems important to me as it can be a way to DoS users (even if it can somehow be mitigated with proper usage of encrypted-SUCI).
What do you think?
Thanks a lot!

[linouxis9]

(even if it can somehow be mitigated with proper usage of encrypted-SUCI).

Also, I'm not completely sure that encrypted-SUCI mitigates the issue, I think you could very well captures the Initial UE Message with some SDR and replays the message, no?

[acetcom]

Is it sufficient after the Authentication response?

If we want to confirm up to integrity protection, I think we need to receive a security mode complete message and send a UEContextReleaseCommand for the previous NG Context.

What do you think about it?

[linouxis9]

After receiving Authentication Response, we know for sure that the UE is what it claims to be, so I believe anything from Authentication Response to Integrity Protected Registration Request (including Security Mode Complete) should work fine.

Waiting up for an Integrity Protected Security Mode Complete could be better, but I'm not sure if it would be necessary: an Integrity Protected Security Mode Complete means that the UE has the right K/OPC and was able to derivate the correct keys. However, a valid RES in the Authentification Reponse also means the UE has the correct K/OPC and should also be able to derivate the correct keys, which should be enough?

It's probably better to delete the previous context ASAP, but I have no strong feeling towards either option.

[acetcom]

@linouxis9

I think I will probably proceed in security mode complete. I haven't designed the architecture yet on how to implement it, but I'll let you know when it's done.

Thanks a lot!
Sukchan

[linouxis9]

Great Sukchan! Thanks a lot for collaborating on that matter :-)
Feel free to let me know when you have implemented it, and I can test the fix.
Cheers!
Valentin

[acetcom]

@linouxis9

I've modified AMF/MME to send UEContextReleaseCommand after Integrity Protected in i2786 branch.

Please let me know if you get the test results.

Thanks a lot!
Sukchan

[linouxis9]

Hi Sukchan,

It seems the behavior is now perfectly as we discussed!

pcap: Open5GS - i2786 fix.zip
PacketRusher does not currently support 4G (making a NAS encoding/decoding library is a pain 😄), so I was not able to test the MME.

Thanks a lot!
Valentin

[acetcom]

@linouxis9

That sounds great!

Thank you so much for sharing your test.
Sukchan