5G安全-发现的几个小问题

在看协议的时候发现了几个小问题,其实当时也没觉得是什么问题,有个问题是在1月份的左右发现,也没咋关注了,到了6,7月整理内容的时候想着整理一下信息给3GPP报一下,发现给最新的文档竟然给修了. 感觉挺诧异的……分享一下,危害不大,攻击成本太高.

EN-DC UE Capbility Information问题

这个是在看EN-DC,非独立组网的注册流程发现.详细可以参考:

https://www.eventhelix.com/5G/non-standalone-access-en-dc/en-dc-secondary-node-addition.pdf

其中有一个流程是基站给UE发送UE Capability Enquiry来查询UE所能支持的网络类型能力,在TS 36331中有描述:

image-20200924222031320

UE收到后会把自己支持的网络能力发给基站,为了后面正常上网流程.

因为该过程是比较重要的, 比如我们能够中间人修改UECapabilityInformation让基站认为UE只支持GSM的话,那么UE就没法正常用LTE/5G,那么就能够实现降级.

我在看流程的时候,发现该过程竟然在AS Security之前. 这个时候我们只要中间人,就可以随便修改了.

但其实协议文档中其实也没很明确指出来, TS 36331 f80, 5.6.3中的描述中,其实就没有考虑UECapabilityInformation的发送前提限制.相当简单的一句话:

image-20200923153129941

我一直由最新往前找,发现就是在TS 36331 f90 (2020/3/31)中添加了相关修复……

image-20200923153345269

明确强调了必须在AS Security之后才认UE发送过来的UECapabilityInformation.

paging耗电

其实算是一个比较水的问题,其实我们搭建一套伪基站的环境,就能够发送Paging. 主要是把目标放在5G场景下的IoT设备上就有点意思了,因为为了节省用电,一些IoT设备都是IDLE的状态,要是能够paging唤醒的话,就能够消耗电量.

但其实像一些场景下,那些IoT设备也就定期检查一些消息……

其他

……

5gallinone LTE RRCConnectionRelease Redirect问题分析
Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×