打造一款伪基站防御利器（一） – 作者:超雪团队2019-安全小百科

虽然目前国内伪基站相比于前几年来说已经少了很多，但还是有少量流动的，或者一些边境区域会受到影响。以往的打击伪基站手段都是采用大数据分析，发现后出警抓捕。但对于流动的，或者跨境的，就比较难办了。基于这种现状，2017年开始跟某地运营商开始研发有防御伪基站功能的设备。

即设备所在范围内，出现伪基站后，设备对伪基站展开攻击，令伪基站失效。

思路

要实现跟伪基站的空中对抗，早期的实验条件，当然少不了C118和OsmocomBB，C118和OsmocomBB就不多说了。

第一阶段，尝试短时间内发送大量RACH请求去消耗伪基站资源。

首先搭建实验环境，通过BladeRF搭建了一个YateBTS。

YateBTS搭建起来后，把2台手机设置到2G模式下，接入YateBTS，成功的拨通了两台手机后，实验基站即搭建成功。接下来就是利用OsmocomBB，修改它的代码，发起RACH dos攻击。

要观测RACH的效果，少不了Wireshark这个工具。从Wireshark抓包的结果上来看，C118跑起修改过的OsmocomBB后，信令里已经出现了大量IMM REJ，这个时候可以说，YateBTS已经拒绝服务了。

这个时候，其他手机虽然还能检测出YateBTS信号，但已经无法完成位置更新。也就是说，如果这个是一个伪基站，它在我们的RACH攻击下，已经彻底失去吸入用户的能力。

第一阶段，实验环境测试我们已经觉得达到了效果，于是打算找运营商测试。在运营商配合下，找了个实验小区，对该小区频点进行RACH测试，每秒约发起15个RACH请求，发现很快运营商的基站就出现IMM REJECT了，这个结果，我们已经对该方案的可行性已经觉得OK。当天测试了十几分钟后，发现小区关闭了，后来沟通发现，原来监控人员发现小区指标异常，所以关站了。

当时还没有伪基站的设备，在运营商配合下，联系了当地的执法部门，把以前缴获的伪基站设备进行实际测试。当时也是第一次看到了真正的伪基站设备，一台笔记本和一套射频设备。

开启真正的伪基站后，大家的手机关闭4G，手机马上收到了伪基站发来的短信。这个时候，在伪基站上再新建了一条测试短信，开始对伪基站进行RACH攻击，大家再关闭4G。大伙还是挺激动的，因为第一次真正的测试，但当大家手机陆续响起短信声音，就知道情况不妙了。

果然，大家还是收到了伪基站的短信。通过测试程序，C118还是快速发起RACH，但伪基站跟之前测试的不一样，发现并没有IMM REJ的消息，全是ASS的，也就是说，跟之前的测试很不一样。就这样折腾了一个下午，发现这个方法，并不能让伪基站停止工作，问题不知道出现在哪。

没办法，只能继续寻找测试环境。后来在强大的闲鱼上，买到了一块SSRP，和一套程序，回到实验环境继续测试。

东西大概就这样。我一直以为用这些的都是搞伪基站的，后来才发现，人家不是用来做伪基站发短信，而是用来做个伪基站，去检测车里面是否有GPS。我在想，目前还有那么多2G物联网设备，协议可能都没加密，用这种部署个伪基站把物联网设备吸入后抓包会怎样？

硬件和软件都找到后，再进行测试。伪基站程序，都是一套OpenBTS，加一个网页控制端。发现黑产还是存在黑吃黑的情况，就是同一套底层程序，界面换一下，说支持4G，说多线程，好多选项其实只有界面，没有实际用途，就是骗人的。还有就是发送数量，实际发送1条，会随机显示发送了十几条（意思是我这套设备牛啊….）。早期这些发送数量被量刑的，不知道算不算冤了。

开始RACH测试后，通过OpenBTS的控制台，可以看到，SDCCH信道的容量在60，然后当前攻击状态下，用了51条信道。想当然的我打算增加多几台C118来加大1秒内发送RACH数量，但结果，测试手机还是会收到伪基站的短信。思路一下陷入僵局。

大概有1个月的时间没有进展，为了回家晚上也能做测试，SSRP在办公室，晚上就用2台C118做实验环境。其中一台跑OpenBTS当小基站，另外一台当客户端。

当时的思路怀疑，是否PC上跑性能有瓶颈，毕竟usb转串口的速率不高，GSM对时间精度又比较敏感，所以，就打算把攻击代码，从PC上直接移植到layer1的固件里，这样省去了PC上的时间。

正是这样不断的调试，一天凌晨，改了很多次的固件测试失败后，最后一次测试打算上床睡觉。这次测试，发现手机跑起来后，另一端的OpenBTS崩溃了！再同样的测试了几次，几次OpenBTS都是崩溃。这次激动得当晚都睡不着觉。像跟做iOS逆向一样，有时成功就是差最后一点的坚持，技术是基础，不断尝试，当然还要靠点运气。

第二天赶紧跑回办公室，拿伪基站的设备进行测试，发现原本发送中的任务，被攻击了一次后，任务被暂停了！！ps看了一下，OpenBTS的PID不一样了，证明进程被重启过！！这下跟哥伦布发现新大陆一样兴奋。漏洞的细节就不方便公布了。

总的来说，是触发了OpenBTS的某个漏洞导致进程崩溃重启,OpenBTS还是有很多漏洞的。伪基站的OpenBTS重启过程中，大约会有5秒时间信号是消失状态的，如果信号出现，马上又对伪基站进行攻击，伪基站就会是不停的重启状态。这样不稳定的信号，达不到正常用户小区重选的阀值，就不会落入伪基站中。