虚拟号码场景下的逻辑漏洞挖掘（全网原创首发）

引言

由于最近挖洞遇到的虚拟号码场景比较多，且都存在各种各样的问题，所以本篇文章来总结一下在该场景下应该如何有效地，快速地进行逻辑漏洞挖掘（文章中涉及真实信息，所以厚码，见谅）

一、漏洞分析

这里要讲的虚拟号码场景，应该不少师傅也都遇到过，一般流程如下

某些功能需要提供用户A手机号给用户B查看并拨打时，往往为了保护用户的隐私安全，就会提供与用户A手机号绑定的虚拟号码给用户B，这时B拨打虚拟号码就会转接给A，这样用户B就不会获取到A的真实手机号，同时这样的虚拟号码一般都带有自动保存录音的功能，所以大大保障了用户的隐私安全与数据安全

通过上面的流程，可以发现使用虚拟号码的最大目的——隐藏用户的真实手机号，保护用户的隐私安全，如下

那我们有没有可能绕过该功能获取到用户的真实手机号呢，答案是肯定的，并且我目前挖企业SRC中遇到的该场景，99%都是存在问题的（就是我目前遇到的该场景都存在该问题，但肯定有做得好，并且不存在该问题的，只是我还没有发现）    

该问题就是用户真实手机号的泄露，也就是使用了虚拟号码的场景，就极大概率存在真实号码的泄露，但泄露的位置可能有很多种，下面来看几个我遇到的真实案例

二、漏洞案例

1、用户主页信息的泄露

这个比较简单，场景如下

该平台由于功能与业务要求，所以会在用户（例如商家）的主页提供虚拟号码的服务，以供其他用户联系。

这个功能点也一目了然吧，直联老板就是获取电话，点击之后出现加密号码，如下

注意这里写的是“本次通过将通过加密号码呼出”，并没有说提供的号码是加密的号码，那如何确认提供的号码是不是加密号码呢？很简单，换一个浏览器或者账号，再获取一次，看两次是不是一样的就行了，如下

可以看到两次是不一样的，说明这确实是加密的号码，而真实号码的泄露，就存在于该页面的回显中，如下

可以看到泄露的信息已经非常全了，所以这个漏洞也算是特别简单的一个漏洞，这里就是在用户主页，F12刷新，在请求商家信息的回显数据包的js中，存在信息泄露

猜测该漏洞存在的原因是请求商家信息的回显中没有做好脱敏处理    

2、用户搜索结果的泄露

这个漏洞与上一个漏洞的不同之处就在于信息泄露的位置不一样，首先用户的主页也是可以获取到虚拟号码，如下

在该主页，虽然存在虚拟号码的功能，但这里是不存在任何的信息泄露的，也就是无法绕过虚拟号获取用户的真实手机号，那这里就不存在漏洞了吗，继续往下看

其实该信息泄露的漏洞是位于搜索结果处

简而言之也是用户信息回显未做脱敏，上一个漏洞是在用户的主页获取用户信息时未脱敏，而这里是在搜索用户时，结果列表获取用户的信息未脱敏，如下

也就是在搜索接口的回显中，会泄露搜索结果中的所有用户的真实电话号    

并且这里只有找店铺才可以（因为店铺才有电话号信息）

也就是想获取哪个用户的真实电话，就搜哪个用户，抓包看该接口的回显就行了，即跟上一个漏洞一样，也是可以获取全平台的用户真实电话

最后这个洞给了我低危，25块，整个人都不好了(˚ ˃̣̣̥᷄⌓˂̣̣̥᷅ )

第二天想battle的时候就已经修了，变成了下面这样用*代替

懒得去扯了，不响丸辣，唉

3、虚拟号码生成处的泄露

上面两个漏洞是由于数据未脱敏导致的，但这个洞是单纯的逻辑有问题导致的泄露，如下    

与第一个漏洞是同一个场景，但是利用方式不同，在该位置开启抓包，并点击直联老板，会抓到一个获取真实电话号的包，如下

分析一下这里的请求逻辑，大概如下

点击直联老板—获取老板的真实手机号—将真实手机号进行加密—获取加密后的手机号—展示加密后的手机号    

所以这里抓包的话，就可以获取到老板的真实手机号手机号，实际上应该进行对明文手机号进行数据加密的，所以这里应该算是设计缺陷了

4、首页推荐信息的泄露

这里也是一个回显信息的未脱敏导致的漏洞，但位置不同

首先在各种商城以及律师咨询平台，医生咨询平台，教师咨询平台等各种职业咨询平台中，是不是都会存在一个首页推荐的功能点，例如精选商品，推荐医师，推荐律师等等，而它们的一部分信息就会展示到首页中，例如职业人员的名称，擅长的技能等，这些信息肯定是来自于一个获取首页推荐信息的接口，那这个接口会不会导致信息泄露呢？答案是肯定的

例如首页推荐接口获取一个医生或律师的全部信息，但其中只有头像，名字和擅长技能在首页展示，而该接口获取的信息远不止这些，并且未脱敏的情况下，也就造成了敏感信息泄露，来看看下面这个场景

可以看到首页推荐了一些从业者，以便用户能快速选择并咨询

进入从业者主页后，如果想要联系从业者，可以选择获取从业者的虚拟号码拨打，或者缴费之后留下自己的电话，等待从业者回电

注意，两种方式都是无法获取从业者的真实电话的，如下    

获取虚拟号进行拨打

缴费之后等待从业者回电

这里的漏洞就存在于主页获取首页推荐内容的接口中，回到主页刷新，抓到获取首页推荐内容的接口即可

可以看到获取首页推荐内容的接口，虽然在首页展示的只有姓名和擅长领域，但其实真实姓名（有的从业者会用别称）和真实电话，也会同时获取，只是不被展示在首页，所以这就是在获取首页推荐信息的接口处存在的敏感信息泄露漏洞的表现形式。

这个全平台从业者真实信息，最后给了我中危50块（光缴费等待从业者回电都要缴99元子。。。）

心情更不好了(ᇂ_ᇂ|||)

5、脱敏数据接口绕过的泄露

这个也是首页推荐信息的泄露，但和上一个漏洞不同的是，获取首页推荐信息的接口是做了脱敏的，那有师傅就要问了，脱敏了为什么还能从中获取敏感信息呢？答案就是它这个脱敏是可以被绕过的，并且这个场景和上面四个是不一样的，算是变相的“虚拟号码”场景，一起来看看吧。    

首先来到商家的主页，如下

注意，由于业务需要，这里的“电话”是可以公开的，也就是点击之后可以直接获取真实电话的，没有任何的加密号码，如下

那这里电话都出来了，还泄露什么呢？其实还是泄露电话，再往下看漏洞点，同样也是抓取获取首页推荐信息的数据包，接口如下

https://xxxx.com/xxx/search/recommend?ajax=1&device=pc&pageSource=home&strategy=view&pageSize=1&page=1&category=20900,20600,20200,20500,20000,20400,20700,20800,20300,20100,21000&multicat=2    

这里该接口的回显中只有商家的公开信息，也就是首页推荐展示的信息，是没有危害的

但观察接口，接口存在一个multicat参数，并且值为2，将其修改为1，结果如下

可以看到出现了敏感信息，商家的邮箱，电话。但这里为什么会有两个电话呢，其实要思考一个问题，那就是商家预留的用于让用户联系的电话，就一定是商家注册平台账户时用的电话吗？不一定吧，猜测商家端应该有一个功能，可以自由设置展示在平台用于客户联系的电话，经过验证，也就是这里的call_contact，而form_contact自然就是商家注册平台时所用的电话号    

普通用户只能看到call_contact，也就是商家设置的让客户看到的信息，而商家的真实电话号和邮箱，普通用户是无法获取，自然也就是存在漏洞了

三、重磅工具

看了上面的案例，有的师傅就要问了，这么多存在泄露的位置，我难道要挨个去找吗，那当然是不用的，只需要一个插件，就能让你省去繁琐的查找敏感信息的工作，就是——HAE

Hae这款工具很多师傅都用过，但大部分人都感觉不太行，但我个人觉得好的正则匹配规则配合新版Hae的展示台，对敏感信息的泄露这一类漏洞的挖掘，是有非常大的帮助的，并且也非常方便

一般测试漏洞的流程，就是开启Burp然后测各种场景，各种功能点，中间也不需要来看Hae插件，测完漏洞要下班之前，再来到Hae的展示台，挨个分析一下匹配到的敏感数据，特别是人名，电话号以及各种key，这样说可能有些师傅不太能感受到冲击力，可以看看下面这两张图

当师傅们准备下班的时候来到Hae看到这一幕，我相信师傅们应该都会很高兴吧,并不需要刻意地去测试这类漏洞，只要把Hae开着，测试漏洞时不用看Hae，下班之前来Hae展示台看一眼，挨个分析一下匹配到的数据就行了

四、总结

因为我也靠Hae挖到了不少的漏洞，所以我个人比较推崇这款插件，但不得不说的是，当数据包过多的时候，Hae插件确实容易崩溃，而且Hae插件也比较吃内存，所以我通常都是两小时分析一次，分析之后把Hae抓到的数据包全部clean，也就是清空掉，或者分析之后重启burp，这样就可以解决当Hae积攒的数据包过大过多之后，hae插件崩溃或卡死的情况，至于吃内存的问题，新版的Hae相比老版已经好了很多，相信未来这个问题也会逐步得到解决。

最后，祝挖洞的师傅们天天有高危，月月有严重，respect！    

原文始发于微信公众号（Hacking庆尘）：“虚拟号码场景下的逻辑漏洞挖掘（全网原创首发）