整合营销服务商
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
电脑端+手机端+微信端=数据同步管理
免费咨询热线：
携号转网于2019年11月27日正式启动，携号转网的目的是促进市场竞争，促进网络提速降费。6月初，工信部和国家发改委发布关于取消电信业务资费告知制度的通告。电信业务经营者应进一步完善电信业务资费公示制度，在营业场所通过手册或电子显示屏等途径，以清单方式公示所有面向公众市场的在售资费方案。
7月7日，工业和信息化部信息通信管理局在京召开了 “携号转网”服务监管电视电话会议，这是自去年 11 月 “携号转网”正式实施以来的第五次全国监管工作会。工信部信息通信管理局会上通报了近期 “携号转网”服务存在的主要问题。
据工信部统计，当前全国 “携号转网”服务总体平稳，申请服务的用户量快速上升，已为 940 万人次提供了 “携号转网”服务。7 月 2 日，全国 “携号转网”服务监管系统已正式上线。
然而，携号转网要实现还真没那么容易。自从携号转网开始了，各大运营商的套路也越来越清晰了。为了留住用户，各种谜一样的操作也是让很多消费者表示自己都不知道怎么就中了招。
01
想要携号转网，限制太多
同样是今年1月，河南焦作的张女士爆料称，在向移动公司发了转网申请短信并得到可以转网的回复后，移动公司又未经同意擅自添加2个套餐设阻，导致不能转网。
除此之外，在实行携号转网之后，靓号转网付巨额违约金、一些号段无法转网、不明业务合约未到期不能转网等等限制，让很多用户表示自己都不知道什么时候办的这些业务，也没想到运营商这些业务套路竟然如此具备“先见之明”。
近日编辑的家人就没能实现携号转网。原来在去年底，联通推出了话费返还的活动。家里老人一看到这个优惠，立马就“投资”了100元。很遗憾的是，老人使用的是联通2G手机，在近日联通拆除2G3G基站之后，信号越来越差。原本想着给他换一个移动的功能手机，没曾想，这个话费返还的合约还没到，携号转网宣告失败。当时还想着要不要换一个手机号码，但是老人说自己的养老金、医保卡、银行卡什么的全是这个号码，懒得慢慢改，联通就这样“成功”地留住了一个老用户。
02
运营商花式挽留，方法真不止一种
为了防止用户转网，各大运营商开启了花式挽留。
中国移动走的是优惠路线：
有用户表示：“我只是发短信给10086查询了一下携号转网事宜，结果运营商竟给我发优惠短信了。”有的用户收到了“流量翻倍权益”——以原来的70元资费，多享14GB流量；还有人收到了“80元包打120元”——每月花80元即可享120元话费使用，总之一句话，你别转网，我给你优惠。
中国联通则表示要改善信号差的问题
中国电信直接开启送送送模式
中国电信比较直接，给每一位用户每个月送100分钟通话！可条件是绑定两年！（这就是另一个坑）
最为典型的就是，今年5月，中国移动宣布20周年福利，在5月17日-6月30日期间，推出“查网龄、领勋章、享五大特权活动”。据了解，在本次“查网龄，领勋章，享五大特权活动”中，移动面向用户推出了三种勋章，而这些勋章都可享受五种特权：5G畅玩服务（3个月）、宽带畅享服务（3个月）、亲情畅聊服务（3个月）、全球通尊享服务（3个月）、权益惠享服务，用户自行认领勋章与专属福利。
03
携号转网不易，小心5G套餐包诱惑
各大运营商不仅仅想出各种方法来留住用户，有不少人看到这种限制，再看看运营商的优惠活动，也就懒得尝试携号转网了。没曾想，运营商又开始了新一轮的套餐“绑定”了。那就是5G套餐包。为了推行即将到来的5G，各路运营商还真是不遗余力。
就在6月底，有媒体报道，三大运营商纷纷降低5G套餐门槛，最低只要69元。报道指出，三大运营商将原本百元以上的5G套餐纷纷拉低到百元以下。其中中国移动折扣力度最大，目前最便宜的5G套餐只要69元。
运营商通常会选择给消费者打电话，有人甚至一天之内要收到2-3个5G套餐推销电话。不仅仅是电话通知，短信轰炸向来也是运营商的手段。最关键的是，短信文案很容易让一些不仔细阅读条款的人被忽悠。
肯定有人看到49元20G就觉得自己赚到了。实际上，如果你没有更换5G手机、目前也没什么真正意义上的5G应用，你选一个5G套餐包真的有意义吗？更何况，还有人理解为这是可以更换自己的手机套餐，其实并不是，这个是5G套餐升级包，4G流量依然需要自己购买。既然如此，多花49元，仅仅只是买了20G流量的4G手机用户，有没有感觉自己又差点被忽悠了？
所以，不管你现在的手机号是哪个运营商，如果没什么特别不满意的地方，也别想着折腾携号转网、优惠升级5G什么的了，老老实实用就好了。
【技术分享】Shiro 权限绕过的历史线（上）
anon 不需要验证，可以直接访问
authc 需要验证，也就是我们需要bypass的地方
Shiro的URL路径表达式为Ant格式:
/hello 只匹配url http://demo.com/hello/h? 只匹配url http://demo.com/h+任意一个字符/hello/* 匹配url下 http://demo.com/hello/xxxx的任意内容，不匹配多个路径/hello/** 匹配url下 http://demo.com/hello/xxxx/aaaa的任意内容
CVE时间线
这个可以从官方安全报告可以得到比较官方的时间线:
下面让我们逐步分析，这些CVE的形成原因，最后再对成因做一个总结。
CVE-2020-1957
0x3.1 漏洞简介
影响版本: shiro
类型: 权限绕过
其他信息:
这个洞可以追溯下SHIRO-682，1957 在此1.5.0版本修复的基础上实现了绕过。
关于Shiro-682的绕过方式很简单，就是对于形如如下的规则时
map.put("/admin", "authc");
可以通过请求/admin/去实现免验证，即bypass.
原理是: Spring Web中/admin/支持访问到/admin,这个洞shiro在1.5.0版本修了，修补手法也很简单
只是做了下Path的路径检测，然后去掉了结尾/
0x3.2 漏洞配置
修改下shiro的检验配置:
config配置(这个很重要，必须)
map.put("/hello/*", "authc");接口
+, method= RequestMethod.GET)public String hello1( Integer index){return "Hello World"+ index.toString() + "!";}然后我们在maven中修改下Shiro的版本为1.5.1，然后还有个坑点就是要复现这个的话spring-boot的版本记得改为:1.5.22.RELEASE,要不然是没办法复现成功的. 至于为什么这里简单说说吧，就是
来源的问题,旧版本能够解析为/admin,而新版本直接解析为/static/../admin,然后基于去寻找对应的方法自然是找不到的，要么就避免引入..
限于文章篇幅，关于理解下面两个版本的结果，可以先看看Tomcat URL解析差异性导致的安全问题的一些相关内容，这里就不去解释了。
旧版本是:
/web/servlet/handler/.class:175
String lookupPath = this.getUrlPathHelper().getLookupPathForRequest(request);调用的是:String rest = this.getPathWithinServletMapping(request);调用的是:String servletPath = this.getServletPath(request);最终是tomcat的处理路径:org.apache.catalina.connector.RequestFacade#getServletPath这个时候就会做一些..;的处理，所以可以导致绕过。而新版本是:
org..web.servlet.handler.ng#
this.getUrlPathHelper().resolveAndCacheLookupPath(request);调用的是:String lookupPath = this.getLookupPathForRequest(request);调用的是:String pathWithinApp = this.getPathWithinApplication(request);调用的是:String requestUri = this.getRequestUri(request);tomcat的调用:org.apache.catalina.connector.Request#getRequestURI然后最终进行了url清洗,会保留..来匹配:this.decodeAndCleanUriString(request, uri);然后下面是针对不同的漏洞使用不同的Shiro版本maven文件。
<dependency><groupId>org.apache.shirogroupId><artifactId>shiro-webartifactId><version>1.5.1version>dependency><dependency><groupId>org.apache.shirogroupId><artifactId>shiro-springartifactId><version>1.5.1version>dependency>0x3.3 漏洞演示
直接访问是被拒绝的。
绕过:
spring新版本(不能引入):
POC:
/fsdf;/../hello/1111那么如果map这样设置，这个洞依然是可以的，至于为什么，下面漏洞分析会说明。
map.put("/hello/**", "authc"); 这样设置的话，之前靠/hello/112/ 末尾+/的话就没用了map.put("/hellO", "authc");0x3.4 漏洞分析
通过diff 1.5.2 与 1.5.0的代码，可以确定在这里出现了问题
我们debug直接跟到这里:
然后在这里的话，首先会做解码然后会删除掉uri中;后面的内容，然后规范化路径。
然后返回的是这个路径:
然后Shiro开始做匹配，从this.r()获取定义的URL规则和权限规则来判断URL的走向。
这里没有定义fsdf,所以自然没有找到,直接返回了Null
然后开始走默认的default的URL规则，经过Spring-boot解析，tomcat解析之后到达了真正的函数点。
这里简化点，通俗来说就是， 一个URL
/fsdf;/../hello/1111首先要走Shiro的过滤器处理，解析得到/fsdf发现没有匹配的拦截器，那么就默认放行，如果有那么就进行权限认证，shiro绕过之后，然后来到了Spring-boot解析，然后Spring-boot在查找方法的时候会调用tomcat的,那么就会返回/hello/1111去去找相对应我们定义的方法，那么可以绕过了。
其实关于这个payload我们还可以这样:
/fsdf/..;/a;aaa;a/..;/hello/1/fsdf/..;/a;aaa;a/..;/hello/1原因是:
在流向的过程中，tomcat会对特殊字符;处理去掉((;XXXX)/)括号里面的内容得到`/fsdf/../a/../hello/1，传递给,最终得到/hello/1作为,去对应的函数来调用。
0x3.5 漏洞修复
这里我们修改maven,shiro升级到1.5.2
<dependency><groupId>org.apache.shirogroupId><artifactId>shiro-webartifactId><version>1.5.2version>dependency><dependency><groupId>org.apache.shirogroupId><artifactId>shiro-springartifactId><version>1.5.2version>dependency>修复代码，细究下:
可以看到原先是由
request.():根路径到地址结尾,原封不动，不走任何处理。
现在变为了:
项目根路径(Spring MVC下如果是根目录默认是为空的)+相对路径+(Spring MVC下默认是为空的)
其实就是统一了request.()来处理路径再进行比较，这里是Shiro主动去兼容Spring和tomcat。
CVE-2020-11989
0x4.1 漏洞简介
影响版本: shiro
类型: 权限绕过
其他信息:
其实这两篇文章成因很显然是不同的，但是修补方式是可以避免这两种绕过方式的，让我们来分析下吧。
0x4.2 漏洞配置
这个漏洞的话，限制比CVE2020-1957多点，比如对于/**这种匹配的话是不存在漏洞还有就是针对某类型的函数，第二种利用则是需要context-path不为空，这个利用就和CVE-2020-1957差不多。
第一种:
这个还不会受到Spring MVC版本的影响。
map.put("/hello/*", "authc");同时我们还需要改一下我们的方法:
(value="/hello" +"" +"/{index}", method= RequestMethod.GET)public String hello1( String index){return "Hello World"+ index.toString() + "!";}需要获取的参数为String的，因为后面就是基于这个String类型来针对这种函数的特殊情况来绕过的。
第一种绕过方式对于这种是无效的，必须是动态获取到传入的内容，然后把传入的内容当做参数才行，像下面这个没有动态参数的话，那么根本就没办法匹配到more:
public String moreHello(){return "Hello moreHello!";}第二种:
server.context-path=/shiro这种情况就和CVE2020-1957的绕过原理很像，就是基于;这个解析差异来实现绕过,但是官方缺乏考虑边缘情况，导致了绕过
这里新版本Spring是不行，因为在Mapping实现不同，
变成了
2.0之后的新版本配置Context-path:
server.servlet.context-path=/shiro0x4.3 漏洞演示
第一种:
/hello/luanxie%25%32%661%25%32%66其实就是%2f的编码
第二种:
/;/shiro/hello/hi
0x4.4 漏洞分析
先说第一种，还是路径解析差异导致，但是属于多一层URL解码，emm
还是在原来那个地方下一个断点
这一行和上面分析差不多，然后这里注意下:
这里传入URL的时候，request.()会做一层URL解码处理(Tomcat URL解析差异性导致的安全问题),
然后我们继续跟进去:(ing(request, uri));
可以看到这里又做了一层decode处理,下一个断点，跟进去这个是什么处理的。
没什么好说的，检测一下编码，然后解码，把本来我想着有没有那种纯数字编码的，这样利用范围就会大一些,比较极端的情况啦，确实没有,解码之后传入做一些规范化处理，这个函数做了什么规范化处理呢，其实也可以看看。
感觉emm，会有点多余啦，这里写了个循环去删除/./和/../,这个其实都会被处理掉的
这里就先姑且当做双重保险，函数的作用跟我们这次漏洞没啥关系。
最终传入Shiro进行和/hello/*匹配的是
原始hello/luanxie%25%32%661->经过Shiro的->组装URL`request.(这里解码一次) ->ing(这里解码一次)->->最终变成了-/hello/luanxie/1,然后进入了Shiro的匹配了，所以如果/hello/**这样的配置是可以匹配到多路径的，但是单*号的话，是没办法处理这个路径的，直接放行，然后request继续走呀走呀，走到Spring那里直接取request.也就是/hello/luanxie%2f1,作为，去寻找有没有合适的定义的方法，结果发现
(value="/hello" +"" +"/{index}", method= RequestMethod.GET)public String hello1( String index){return "Hello World"+ index.toString() + "!";}这个参数hello/luanxie%2f1正好就是/hello/String的模式呀,那么就直接调用了这个函数hello1,实现了绕过。
下面说说第二种绕过方式，说实话，这种绕过方式其实应用场景更广
这个问题主要tomcat的的实现上
org.apache...Request#
可以看到这个函数执行操作是POS会一直++直到匹配到`/shiro，
然后返回的时候直接返回0-Pos位置的字符串，怎么说呢，这个设计可能是为了兼容../的类似情况,然后导致最终解析的URL引入了;
然后后面的话，就回到我们之前2020-1957的分析的，只不过这次
;的引入不再是由request.()引入，这次引入是补丁中的这个拼接的时候引入的，然后Shiro对于;处理也说了，直接删掉;后面的内容，所以最终返回的是fsdf去匹配Shiro我们定义的正则。
所以这样去绕过也可以的。
0x4.5 漏洞修复
直接比对下代码:…shiro-root-1.5.3
这次的修补地方，主要是改了tion(这个函数返回的uri是用于后面Shiro进行URL过滤匹配的)。
return normalize(removeSemicolon(getServletPath(request) + getPathInfo(request)));这样没有了多一重的URL解码，解决了问题1,然后删掉了,解决了问题2。
其实可以思考下，如果也可以引入;那么一样是会存在漏洞的,笔者对于挖Shiro的这种有限制的0day并不感兴趣，有兴趣的读者可以去挖。
参考链接
Spring源码分析之WebMVC
Spring Boot中关于%2e的Trick
*请认真填写需求信息，我们会在24小时内与您取得联系。
