落葉飛舞

I'm a leaf on wind, Watch how I fly.

Search: 盗打购买游戏点卡的分析

.clear

博文分类

  • 正在载入数据中...

最近发表

  • 正在载入数据中...
  • 正在载入数据中...

热门文章

  • 正在载入数据中...
  • 正在载入数据中...

随机文章

  • 正在载入数据中...
  • 正在载入数据中...

广而告之


盗打购买游戏点卡的分析

可视编辑 UBB编辑

落葉飛舞 » 技巧工具 » 盗打购买游戏点卡的分析

案例分析背景
随着移动通信网络的不断发展,手机已成为人们生活、工作的一个重要组成部分,但同时不和谐的是现阶段市场上出现了各类非法盗打、SIM克隆以及短信群发、任意改号等和通信相关的问题,严重影响了客户的通信使用安全。因此,作为移动网络的通信运营商,中国移动有必要对上述问题进行分析,对网络上存在的安全漏洞予以重视和预防,提高客户的网络感知。
问题描述
07年12月xx公司收到市场部门的投诉,申告内容是有客户反应发现电话被盗打,并收到提示购买游戏充值点卡短信的情况。根据投诉号码,我们对话单进行了分析,比对发现所有的投诉用户都被盗打了125904252001信息台(腾讯,北京联动优势)和发送短信至10658008(手机钱包话费支付业务)的情况,且用户都统一被收取了该声讯台的包月费30元,通过话单梳理,全地区在该时间段内(从12月1日至10日)共有8000多用户被收取了包月费,根据业务支撑部门的统计,已超过了过该业务的正常业务量数倍多,属于不正常现象。
分析原理
出现上述问题的网元由于没有接入信令监测平台,而且挂表分析时由于没有再盗打,相关消息也没有跟踪到,因此对该问题的分析,只能从话单分析先入手,通过对投诉客户的话单文件进行分析后发现有以下共同特征:
1、(1)通话记录显示拨打125904252001时产生该话单的LAC和CELL集中在同一个基站(xx南湖饭店),南湖饭店共三个扇区(CELLID:27FE/4F07/761F)。
序号 对方用户通话所在地 通话日期起始时间 通话时长 通话状态 通话类型 对方号码 对方号码类型 通话地 业务类型 基本通话费 长途费 信息费 费用小计 用户通话所在LAC 用户通话所在CELLID
用户1 xx 2007-12-07 10:44:27 273秒 本地 主叫 125904252001 12590 xx 音信互动 1.50 0.00 5.00 6.50 5830 27FE
用户2 xx 2007-12-07 06:34:42 221秒 本地 主叫 125904252001 12590 xx 音信互动 0.60 0.00 4.00 4.60 5830 4F07
用户3 xx 2007-12-10 06:54:26 378秒 本地 主叫 125904252001 12590 xx 音信互动 1.20 0.00 7.00 8.20 5830 27FE
用户4 xx 2007-12-10 05:55:35 201秒 本地 主叫 125904252001 12590 xx 音信互动 0.60 0.00 4.00 4.60 5830 4F0E
(2)根据原始话单的分析,确认上述话单的各个字段,包括IMEI、IMSI等都正常,都是实际用户所对应的字段,可以排除SIM克隆的情况(根据以前的经验,SIM克隆时上报的IMEI号都采用非法IMEI)。
(3)从LAC/CELLID上看投诉客户的前后通话地点和拨打125904252001的通话地点完全不符合。
序号 对方用户通话所在地 通话日期起始时间 通话时长 通话状态 通话类型 对方号码 对方号码类型 通话地 业务类型 基本通话费 长途费 信息费 费用小计 用户通话所在LAC 用户通话所在CELLID
38 xx 2007-12-10 06:54:26 378秒 本地 主叫 125904252001 12590 xx 音信互动 1.20 0.00 7.00 8.20 5830 27FE
39 xx 2007-12-10 07:01:31 31秒 本地 被叫 677068 中国移动MVPN xx 虚拟网 0.00 0.00 0.00 0.00 5738 3D55
如上表,两个小区相距至少30KM,而通话记录显示客户在7分钟内发生了位置变动,其他很多用户都有类似的情况,因此,分析来看,应该是存在盗打的可能,而不是用户自己直接拨打的。
(4)在打125904252001 之后均有两条短信,一条发往13164936365或13175584555(短信内容均为COM1~30),一条发往10658008(手机钱包话费支付业务,短信内容均为购买游戏卡)。
序号 日期时间 业务类型 对方号码 服务类型 长度 费用
用户1 2007-12-07 06:36:55 发短信 13164936365 网外短信 5byte 0.15
用户2 2007-12-07 06:37:57 发短信 10658008 梦网短信 3byte 0.10
SP代收费:30.00元
411435:0.00元
服务代码 业务名称 标准资费 使用量 费用
10086 98 0.00 7 0.00
北京联动优势:30.00元
服务代码 业务名称 标准资费 使用量 费用
7777 热点游戏充值30元 30.00 2 30.00
序号 日期时间 费用产生月份 SP名称 SP服务代码 SP企业代码 业务名称 业务类型 计费类型 费用
用户1 2007-12-07 06:38:05   北京联动优势 7777 901525 热点游戏充值30元 梦网短信 计次 0.00
用户2 2007-12-07 07:58:45 2007年12月 北京联动优势 7777 901525 热点游戏充值30元 梦网短信 包月 30.00
综合以上各种现象,组合起来分析应该是属于非法盗打购买游戏充值点卡获利行为。具体分析如下:
1、 一次正常的购买游戏充值点卡的业务流程
在分析是否为盗打之前,有必要先了解一下一次正常的购买游戏充值点卡的过程。通过查询相关资料知道,联动商城商品交易是通过网上下订单,手机确认支付的方式来开展。主要有两种方式,一是短信方式,另一种是互联网方式,但大体相同,以互联网方式为例的流程如下:登陆商城-选择商品-立即购买-输入手机号和验证码-输入确认短信-支付成功,之后收到下发的帐号和密码,利用该帐号和密码在指定的网站进行充值。因此,该流程的关键点是要取得最后支付成功后下发的帐号和密码,并在指定的网站进行及时的充值,实现将话费转成点卡。
2、 实现盗打的几个关键点
实现盗打有几个关键点,第一点是要实现语音的成功呼叫,以及上发业务代码短信,实现包月注册;第二点是成功接受到帐号和密码短信内容,实现将话费转成点卡,实现充值转移。结合GSM通信网络逐项的安全策略分析如下:
根据规范,GSM通信网络主要是通过哪些技术对策来实现通信的安全性的呢?归结起来主要有下列5个部分:一是无线接入方面采用了用户鉴权;二是无线路径上采用对通信信息加密;三是对移动设备采用设备识别;四是对用户识别码用临时识别码(TMSI)保护;五是SIM卡用PIN码保护。一次呼叫的接入流程如下,简要说明如下:

 

 


MS通过SDCCH上发一个层三消息---CM业务请求消息,主要包含的参数有TMSI、LAC 和CELLID,该消息被BSS透明的传送至MSC,VLR根据上报的TMSI进行识别,如果TMIS 不存在则请求上报IMSI(通过ID REQUEST/ID RESPONSE消息来实现),否则查看在数据库中该MS是否有鉴权三参组,如果有,将直接向MSC下发鉴权命令,否则,向相应的HLR/AUC请求鉴权参数,从HLR/AUC得到三参组,然后再向MSC下发鉴权命令。MSC收到VLR发送的鉴权命令后,通过BSS向MS下发鉴权请求,在该命令中含有鉴权参数,MS收到鉴权请求后,利用SIM卡中的IMSI和鉴权算法,得出鉴权结果,通过鉴权响应消息送达MSC,MSC将鉴权结果回送VLR,由VLR 核对MS上报的鉴权结果和从HLR取得的鉴权参数中的结果,如果二者不一致,拒绝此次接入请求,此次呼叫失败,然后MSC向MS下发加密命令,该命令内含加密模式,MS收到此命令并完成加密后,回送加密完成消息,到此MS完成了 整个接入阶段的工作。因此,从上述流程可以看到,鉴权是整个接入过程的大门,是很关键的一点,直接关系到MS能否成功接入网络。
目前现网交换机的一般情况是在无线接入方面鉴权参数设置为每10次呼叫鉴权一次,并进行TMSI重分配,(空口不加密和IMEI不识别),因此上述流程中CM 请求中使用的TMSI如果恰好VLR中存在,且本次不鉴权,该模拟设备就可以顺利接入网络,就可以实现盗打行为,包括语音呼叫以及发短信等。
上述分析了第一个关键点,即实现语音的成功呼叫,以及上发业务代码短信,第二关键是成功接受到帐号和密码短信内容,在分析该问题时先了解一下网络寻呼的流程。

当一个LAC下的移动台被寻呼时,MSC就会通过基站控制器(BSC)向对应LAC范围内的所有小区发出寻呼请求,目前有TMSI 寻呼和IMSI 寻呼两种寻呼方式,由于字段长短的关系,使用IMSI 方式寻呼带来的寻呼负荷会比使用TMSI 方式寻呼增加一倍,因此,xx现网无线寻呼采用的是TMSI方式。
  从流程可知,当MSC从VLR中获得移动台当前所处的位置区号(LAI)后,将向这一位置区内的所有BSC发出寻呼消息,BSC收到寻呼消息后,向该BSC下属于此位置区的所有小区发出寻呼命令消息,当基站收到寻呼命令后,将在该寻呼组所属的寻呼子信道上发出寻呼请求消息,该消息中携带有被寻呼用户的IMSI或者TMSI 号码,移动台在收到寻呼请求消息后,MS回寻呼响应(Paging Resp)消息给BSC,BSC将Paging Resp 消息转发给MSC,完成一次成功的无线寻呼,后续流程主要是鉴权和加密等过程。
结合盗打过程和上述流程分析来看,SP根据用户号码下发帐号和密码短信,交换机由于收到的是正常的用户号码,可以在VLR中找很方便的得到IMSI、TMSI以及更新后的LAC位置区,然后进行A接口下发的PAGING消息(第一次PAGING消息中包含的是IMSI和TMSI,二次PAING消息则只有IMSI),该PAGING是基于LAC的寻呼,而此时VLR中的LAC已经更改为模式设备上报的LAC,因此此时下发的PAGING消息也就直接下发到盗打模拟设备所在的LAC/BSC/CELLID上,如果此时真实用户在其他LAC下,则真实的用户就收不到PAGING消息,同样,此时如果网络在被叫接入时恰好不进行鉴权,盗打模拟设备就可以收到帐号和密码的短信,而真实用户由于不在该LAC下就收不到帐号和密码,也就是此时客户是在没有感知的情况下被盗打了。还有一种情况就是恰好真实的被叫用户也刚好在该LAC上(5830H),由于无线侧寻呼是根据TMSI下发的,因此,有可能的情况是两个设备都能响应,但能接受到短信的就存在概率问题,有可能真实用户收到,也有可能是盗打模拟设备收到。
分析过程
结合上述分析原理,我们可以推测出本次非法盗打的过程,主要分五步,即:
第一步:通过设备模拟TMSI(通过工程模式手机可以查询手机的TMSI信息,而且TMSI的分配有一定的变化规则),直接发起CM_SERVICE_REQUEST请求,同时上报该模拟设备所在的LAC信息。
第二步:如果该TMSI恰好在交换机中存在,该模拟设备就能在收到CM_SERVICE_ACCEPT消息后,按正常呼叫流程发送SETUP请求呼叫125904252001,呼叫该号码的目的是为了登记注册,并按包月的方式注册成功。如果不存在,该设备在收到交换机发送Indentity-Request消息之后,因为不知道真实IMSI而不回任何消息,或者随意回一个IMSI,在网络超时或者收到CM_SERVECE_REJECT后直接进行下一个TMSI号码尝试。
第三步:呼叫挂机后,立即发起一次发送短信的请求,发往两个联通号码13164936365或13175584555(短信内容均为COM1~30),该过程主要是为了得到被盗打的用户的主叫的MSISDN号码。
第四步:通过网站或者利用设备模拟向手机钱包SP发起一次短信,内容主要是购买商品的代号,如游戏卡 55等,之后SP下发游戏帐号和密码到手机。
第五步:模拟设备收到短信后,拿到帐号和密码,登陆相关地址后进行充值,成功的实现将话费转成点卡。
研究如何通过监测系统实现监测
根据分析,上述问题主要的实现主要是基于模拟设备频繁的重试TMSI来实现,因此,在A接口上通过监测系统还是可以实现有效监测的,主要分两步:
第一步:由于交换机的参数设置为每10次呼叫鉴权一次,并进行TMSI重分配,因此,要实现盗打在层三上肯定会收到异常多的CM 请求消息,且由于鉴权等原因,MSC/VLR会下发较高概率的CM SERVIECE REJECT消息。因此,只要在A接口上进行监测是否有异常的CM SERVIECE REJECT消息(cause=IMSI UNKNOWN IN VLR)。同样,也可以监测是否有异常多的ID REQ消息。
第二步:根据得到的异常消息中的小区,利用监测系统的统计功能,统计指定小区下是否有存在大量的异常消息,就可以判断无线网络是否有盗打存在。
其他问题
由于现网没有跟踪到相关信令,因此上述问题都是基于可行性的分析,为暂时解决此类恶意盗打现象,目前已将投诉集中的交换机鉴权和TMSI改成“每次呼叫和短信都必须重新分配”(正常为10次),但修改后网络将增加呼叫接续时长和信令负荷,因此暂时在小范围内修改参数进行观察。
另外,根据业务实现流程,如果只是说针对该问题,也可以通过对SP厂商的业务流程的修改来解决该问题。主要思路是通过时间上的错开来保护TMSI的重分配不被盗用,措施有:一是语音接入后的注册分两次呼叫来实现,且要求两次间隔一定的时间;二是帐号和密码的短信下发分开发送,且要求两次间隔一定的时间。
最后,需要说明一点的是要彻底解决盗打的问题,网络一定要开启每次鉴权,虽然网络负荷会有所增加,但对客户的网络感知来说一定是有提升的。
 

.clear

Tags:移动通信  中国移动  网络优化   分享家:Addthis中文版

分类:技巧工具 评论:0 浏览:
正在载入数据中...

发表评论:

◎欢迎参与讨论,请在这里发表您的看法、交流您的观点。
.clear
.clear

* ©leafFly.com.浙ICP备08102798号
本站采用创作共用版权协议, 要求署名、非商业用途和保持一致.回顶部
free counters

Powered By Z-Blog 1.8 Walle Build 100427 Designed by haphic&LeafFly [Top]