攜號轉(zhuǎn)網(wǎng)想都別想！運營商這些套路你中招沒

攜號轉(zhuǎn)網(wǎng)于2019年11月27日正式啟動，攜號轉(zhuǎn)網(wǎng)的目的是促進市場競爭，促進網(wǎng)絡(luò)提速降費。6月初，工信部和國家發(fā)改委發(fā)布關(guān)于取消電信業(yè)務(wù)資費告知制度的通告。電信業(yè)務(wù)經(jīng)營者應(yīng)進一步完善電信業(yè)務(wù)資費公示制度，在營業(yè)場所通過手冊或電子顯示屏等途徑，以清單方式公示所有面向公眾市場的在售資費方案。

7月7日，工業(yè)和信息化部信息通信管理局在京召開了 “攜號轉(zhuǎn)網(wǎng)”服務(wù)監(jiān)管電視電話會議，這是自去年 11 月 “攜號轉(zhuǎn)網(wǎng)”正式實施以來的第五次全國監(jiān)管工作會。工信部信息通信管理局會上通報了近期 “攜號轉(zhuǎn)網(wǎng)”服務(wù)存在的主要問題。

據(jù)工信部統(tǒng)計，當前全國 “攜號轉(zhuǎn)網(wǎng)”服務(wù)總體平穩(wěn)，申請服務(wù)的用戶量快速上升，已為 940 萬人次提供了 “攜號轉(zhuǎn)網(wǎng)”服務(wù)。7 月 2 日，全國 “攜號轉(zhuǎn)網(wǎng)”服務(wù)監(jiān)管系統(tǒng)已正式上線。

然而，攜號轉(zhuǎn)網(wǎng)要實現(xiàn)還真沒那么容易。自從攜號轉(zhuǎn)網(wǎng)開始了，各大運營商的套路也越來越清晰了。為了留住用戶，各種謎一樣的操作也是讓很多消費者表示自己都不知道怎么就中了招。

想要攜號轉(zhuǎn)網(wǎng)，限制太多

到期套餐電信能換卡沒_電信3g套餐沒有到期能換4g卡嗎_電信套餐到期了可以換嗎

同樣是今年1月，河南焦作的張女士爆料稱，在向移動公司發(fā)了轉(zhuǎn)網(wǎng)申請短信并得到可以轉(zhuǎn)網(wǎng)的回復(fù)后，移動公司又未經(jīng)同意擅自添加2個套餐設(shè)阻，導(dǎo)致不能轉(zhuǎn)網(wǎng)。

電信3g套餐沒有到期能換4g卡嗎_電信套餐到期了可以換嗎_到期套餐電信能換卡沒

除此之外，在實行攜號轉(zhuǎn)網(wǎng)之后，靚號轉(zhuǎn)網(wǎng)付巨額違約金、一些號段無法轉(zhuǎn)網(wǎng)、不明業(yè)務(wù)合約未到期不能轉(zhuǎn)網(wǎng)等等限制，讓很多用戶表示自己都不知道什么時候辦的這些業(yè)務(wù)，也沒想到運營商這些業(yè)務(wù)套路竟然如此具備“先見之明”。

電信套餐到期了可以換嗎_到期套餐電信能換卡沒_電信3g套餐沒有到期能換4g卡嗎

近日編輯的家人就沒能實現(xiàn)攜號轉(zhuǎn)網(wǎng)。原來在去年底，聯(lián)通推出了話費返還的活動。家里老人一看到這個優(yōu)惠，立馬就“投資”了100元。很遺憾的是，老人使用的是聯(lián)通2G手機，在近日聯(lián)通拆除2G3G基站之后，信號越來越差。原本想著給他換一個移動的功能手機，沒曾想，這個話費返還的合約還沒到，攜號轉(zhuǎn)網(wǎng)宣告失敗。當時還想著要不要換一個手機號碼，但是老人說自己的養(yǎng)老金、醫(yī)保卡、銀行卡什么的全是這個號碼，懶得慢慢改，聯(lián)通就這樣“成功”地留住了一個老用戶。

運營商花式挽留，方法真不止一種

為了防止用戶轉(zhuǎn)網(wǎng)，各大運營商開啟了花式挽留。

中國移動走的是優(yōu)惠路線：

有用戶表示：“我只是發(fā)短信給10086查詢了一下攜號轉(zhuǎn)網(wǎng)事宜，結(jié)果運營商竟給我發(fā)優(yōu)惠短信了。”有的用戶收到了“流量翻倍權(quán)益”——以原來的70元資費，多享14GB流量；還有人收到了“80元包打120元”——每月花80元即可享120元話費使用，總之一句話，你別轉(zhuǎn)網(wǎng)，我給你優(yōu)惠。

中國聯(lián)通則表示要改善信號差的問題

中國電信直接開啟送送送模式

中國電信比較直接，給每一位用戶每個月送100分鐘通話！可條件是綁定兩年！（這就是另一個坑）

最為典型的就是，今年5月，中國移動宣布20周年福利，在5月17日-6月30日期間，推出“查網(wǎng)齡、領(lǐng)勛章、享五大特權(quán)活動”。據(jù)了解，在本次“查網(wǎng)齡，領(lǐng)勛章，享五大特權(quán)活動”中，移動面向用戶推出了三種勛章，而這些勛章都可享受五種特權(quán)：5G暢玩服務(wù)（3個月）、寬帶暢享服務(wù)（3個月）、親情暢聊服務(wù)（3個月）、全球通尊享服務(wù)（3個月）、權(quán)益惠享服務(wù)，用戶自行認領(lǐng)勛章與專屬福利。

到期套餐電信能換卡沒_電信3g套餐沒有到期能換4g卡嗎_電信套餐到期了可以換嗎

電信套餐到期了可以換嗎_到期套餐電信能換卡沒_電信3g套餐沒有到期能換4g卡嗎

攜號轉(zhuǎn)網(wǎng)不易，小心5G套餐包誘惑

各大運營商不僅僅想出各種方法來留住用戶，有不少人看到這種限制，再看看運營商的優(yōu)惠活動，也就懶得嘗試攜號轉(zhuǎn)網(wǎng)了。沒曾想，運營商又開始了新一輪的套餐“綁定”了。那就是5G套餐包。為了推行即將到來的5G，各路運營商還真是不遺余力。

就在6月底，有媒體報道，三大運營商紛紛降低5G套餐門檻，最低只要69元。報道指出，三大運營商將原本百元以上的5G套餐紛紛拉低到百元以下。其中中國移動折扣力度最大，目前最便宜的5G套餐只要69元。

運營商通常會選擇給消費者打電話，有人甚至一天之內(nèi)要收到2-3個5G套餐推銷電話。不僅僅是電話通知，短信轟炸向來也是運營商的手段。最關(guān)鍵的是，短信文案很容易讓一些不仔細閱讀條款的人被忽悠。

肯定有人看到49元20G就覺得自己賺到了。實際上，如果你沒有更換5G手機、目前也沒什么真正意義上的5G應(yīng)用，你選一個5G套餐包真的有意義嗎？更何況，還有人理解為這是可以更換自己的手機套餐，其實并不是，這個是5G套餐升級包，4G流量依然需要自己購買。既然如此，多花49元，僅僅只是買了20G流量的4G手機用戶，有沒有感覺自己又差點被忽悠了？

所以，不管你現(xiàn)在的手機號是哪個運營商，如果沒什么特別不滿意的地方，也別想著折騰攜號轉(zhuǎn)網(wǎng)、優(yōu)惠升級5G什么的了，老老實實用就好了。

【技術(shù)分享】Shiro 權(quán)限繞過的歷史線（上）

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的任意內(nèi)容，不匹配多個路徑/hello/** 匹配url下 http://demo.com/hello/xxxx/aaaa的任意內(nèi)容

CVE時間線

這個可以從官方安全報告可以得到比較官方的時間線:

你沒有合適的權(quán)限訪問這個項目_權(quán)限合適訪問沒項目有記錄嗎_權(quán)限訪問有記錄說明什么

下面讓我們逐步分析，這些CVE的形成原因，最后再對成因做一個總結(jié)。

CVE-2020-1957

0x3.1 漏洞簡介

影響版本: shiro

類型: 權(quán)限繞過

其他信息:

這個洞可以追溯下SHIRO-682，1957 在此1.5.0版本修復(fù)的基礎(chǔ)上實現(xiàn)了繞過。

關(guān)于Shiro-682的繞過方式很簡單，就是對于形如如下的規(guī)則時

map.put("/admin", "authc");

可以通過請求/admin/去實現(xiàn)免驗證，即bypass.

原理是: Spring Web中/admin/支持訪問到/admin,這個洞shiro在1.5.0版本修了，修補手法也很簡單

權(quán)限合適訪問沒項目有記錄嗎_權(quán)限訪問有記錄說明什么_你沒有合適的權(quán)限訪問這個項目

只是做了下Path的路徑檢測，然后去掉了結(jié)尾/

0x3.2 漏洞配置

修改下shiro的檢驗配置:

config配置(這個很重要，必須)


map.put("/hello/*", "authc");

接口
@ResponseBody    @RequestMapping(value="/hello" +            "" +            "/{index}", method= RequestMethod.GET)    public  String hello1(@PathVariable Integer index){        return "Hello World"+ index.toString() + "!";    }


然后我們在maven中修改下Shiro的版本為1.5.1，然后還有個坑點就是要復(fù)現(xiàn)這個的話spring-boot的版本記得改為:1.5.22.RELEASE,要不然是沒辦法復(fù)現(xiàn)成功的. 至于為什么這里簡單說說吧，就是
來源的問題,舊版本能夠解析為/admin,而新版本直接解析為/static/../admin,然后基于去尋找對應(yīng)的方法自然是找不到的，要么就避免引入..
限于文章篇幅，關(guān)于理解下面兩個版本的結(jié)果，可以先看看Tomcat URL解析差異性導(dǎo)致的安全問題的一些相關(guān)內(nèi)容，這里就不去解釋了。
舊版本是:
/web/servlet/handler/.class:175
String lookupPath = this.getUrlPathHelper().getLookupPathForRequest(request);調(diào)用的是:String rest = this.getPathWithinServletMapping(request);調(diào)用的是:String servletPath = this.getServletPath(request);最終是tomcat的處理路徑:org.apache.catalina.connector.RequestFacade#getServletPath 這個時候就會做一些..;的處理，所以可以導(dǎo)致繞過。

而新版本是:
org..web.servlet.handler.ng#
this.getUrlPathHelper().resolveAndCacheLookupPath(request);調(diào)用的是:String lookupPath = this.getLookupPathForRequest(request);調(diào)用的是:String pathWithinApp = this.getPathWithinApplication(request);調(diào)用的是:String requestUri = this.getRequestUri(request);tomcat的調(diào)用: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這樣設(shè)置，這個洞依然是可以的，至于為什么，下面漏洞分析會說明。
map.put("/hello/**", "authc"); 這樣設(shè)置的話，之前靠/hello/112/ 末尾+/的話就沒用了map.put("/hellO", "authc");

0x3.4 漏洞分析

通過diff 1.5.2 與 1.5.0的代碼，可以確定在這里出現(xiàn)了問題

我們debug直接跟到這里:


然后在這里的話，首先會做解碼然后會刪除掉uri中;后面的內(nèi)容，然后規(guī)范化路徑。
然后返回的是這個路徑:

然后Shiro開始做匹配，從this.r()獲取定義的URL規(guī)則和權(quán)限規(guī)則來判斷URL的走向。

這里沒有定義fsdf,所以自然沒有找到,直接返回了Null

然后開始走默認的default的URL規(guī)則，經(jīng)過Spring-boot解析，tomcat解析之后到達了真正的函數(shù)點。
這里簡化點，通俗來說就是， 一個URL
/fsdf;/../hello/1111

首先要走Shiro的過濾器處理，解析得到/fsdf發(fā)現(xiàn)沒有匹配的攔截器，那么就默認放行，如果有那么就進行權(quán)限認證，shiro繞過之后，然后來到了Spring-boot解析，然后Spring-boot在查找方法的時候會調(diào)用tomcat的,那么就會返回/hello/1111去去找相對應(yīng)我們定義的方法，那么可以繞過了。
其實關(guān)于這個payload我們還可以這樣:
 /fsdf/..;/a;aaa;a/..;/hello/1  /fsdf/..;/a;aaa;a/..;/hello/1

原因是:
在流向的過程中，tomcat會對特殊字符;處理去掉((;XXXX)/)括號里面的內(nèi)容得到`/fsdf/../a/../hello/1，傳遞給,最終得到/hello/1作為,去對應(yīng)的函數(shù)來調(diào)用。
0x3.5 漏洞修復(fù)
這里我們修改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>

修復(fù)代碼，細究下:

可以看到原先是由
request.():根路徑到地址結(jié)尾,原封不動，不走任何處理。
現(xiàn)在變?yōu)榱?
項目根路徑(Spring MVC下如果是根目錄默認是為空的)+相對路徑+(Spring MVC下默認是為空的)
其實就是統(tǒng)一了request.()來處理路徑再進行比較，這里是Shiro主動去兼容Spring和tomcat。

CVE-2020-11989

0x4.1 漏洞簡介
影響版本: shiro
類型: 權(quán)限繞過
其他信息:
其實這兩篇文章成因很顯然是不同的，但是修補方式是可以避免這兩種繞過方式的，讓我們來分析下吧。
0x4.2 漏洞配置
這個漏洞的話，限制比CVE2020-1957多點，比如對于/**這種匹配的話是不存在漏洞還有就是針對某類型的函數(shù)，第二種利用則是需要context-path不為空，這個利用就和CVE-2020-1957差不多。
第一種:
這個還不會受到Spring MVC版本的影響。
map.put("/hello/*", "authc");

同時我們還需要改一下我們的方法:
@ResponseBody    @RequestMapping(value="/hello" +            "" +            "/{index}", method= RequestMethod.GET)    public  String hello1(@PathVariable String index){        return "Hello World"+ index.toString() + "!";    }

需要獲取的參數(shù)為String的，因為后面就是基于這個String類型來針對這種函數(shù)的特殊情況來繞過的。
第一種繞過方式對于這種是無效的，必須是動態(tài)獲取到傳入的內(nèi)容，然后把傳入的內(nèi)容當做參數(shù)才行，像下面這個沒有動態(tài)參數(shù)的話，那么根本就沒辦法匹配到more:
@ResponseBody    @RequestMapping(value="/hello/more", method= RequestMethod.GET)    public  String moreHello(){        return "Hello moreHello!";    }

第二種:
server.context-path=/shiro

這種情況就和CVE2020-1957的繞過原理很像，就是基于;這個解析差異來實現(xiàn)繞過,但是官方缺乏考慮邊緣情況，導(dǎo)致了繞過
這里新版本Spring是不行，因為在Mapping實現(xiàn)不同，
變成了


2.0之后的新版本配置Context-path:
server.servlet.context-path=/shiro

0x4.3 漏洞演示
第一種:
/hello/luanxie%25%32%661

%25%32%66其實就是%2f的編碼

第二種:
/;/shiro/hello/hi


0x4.4 漏洞分析
先說第一種，還是路徑解析差異導(dǎo)致，但是屬于多一層URL解碼，emm
還是在原來那個地方下一個斷點

這一行和上面分析差不多，然后這里注意下:

這里傳入URL的時候，request.()會做一層URL解碼處理(Tomcat URL解析差異性導(dǎo)致的安全問題),
然后我們繼續(xù)跟進去:(ing(request, uri));

可以看到這里又做了一層decode處理,下一個斷點，跟進去這個是什么處理的。

沒什么好說的，檢測一下編碼，然后解碼，把本來我想著有沒有那種純數(shù)字編碼的，這樣利用范圍就會大一些,比較極端的情況啦，確實沒有,解碼之后傳入做一些規(guī)范化處理，這個函數(shù)做了什么規(guī)范化處理呢，其實也可以看看。

感覺emm，會有點多余啦，這里寫了個循環(huán)去刪除/./和/../,這個其實都會被處理掉的

這里就先姑且當做雙重保險，函數(shù)的作用跟我們這次漏洞沒啥關(guān)系。

最終傳入Shiro進行和/hello/*匹配的是
原始hello/luanxie%25%32%661->經(jīng)過Shiro的->組裝URL`request.(這里解碼一次) ->ing(這里解碼一次)->->最終變成了-/hello/luanxie/1,然后進入了Shiro的匹配了，所以如果/hello/**這樣的配置是可以匹配到多路徑的，但是單*號的話，是沒辦法處理這個路徑的，直接放行，然后request繼續(xù)走呀走呀，走到Spring那里直接取request.也就是/hello/luanxie%2f1,作為，去尋找有沒有合適的定義的方法，結(jié)果發(fā)現(xiàn)
@ResponseBody    @RequestMapping(value="/hello" +            "" +            "/{index}", method= RequestMethod.GET)    public  String hello1(@PathVariable String index){        return "Hello World"+ index.toString() + "!";    }

這個參數(shù)hello/luanxie%2f1正好就是/hello/String的模式呀,那么就直接調(diào)用了這個函數(shù)hello1,實現(xiàn)了繞過。
下面說說第二種繞過方式，說實話，這種繞過方式其實應(yīng)用場景更廣
這個問題主要tomcat的的實現(xiàn)上
org.apache...Request#

可以看到這個函數(shù)執(zhí)行操作是POS會一直++直到匹配到`/shiro，

然后返回的時候直接返回0-Pos位置的字符串，怎么說呢，這個設(shè)計可能是為了兼容../的類似情況,然后導(dǎo)致最終解析的URL引入了;
然后后面的話，就回到我們之前2020-1957的分析的，只不過這次
;的引入不再是由request.()引入，這次引入是補丁中的這個拼接的時候引入的，然后Shiro對于;處理也說了，直接刪掉;后面的內(nèi)容，所以最終返回的是fsdf去匹配Shiro我們定義的正則。

所以這樣去繞過也可以的。
0x4.5 漏洞修復(fù)
直接比對下代碼:…shiro-root-1.5.3

這次的修補地方，主要是改了tion(這個函數(shù)返回的uri是用于后面Shiro進行URL過濾匹配的)。
return normalize(removeSemicolon(getServletPath(request) + getPathInfo(request)));

這樣沒有了多一重的URL解碼，解決了問題1,然后刪掉了,解決了問題2。
其實可以思考下，如果也可以引入;那么一樣是會存在漏洞的,筆者對于挖Shiro的這種有限制的0day并不感興趣，有興趣的讀者可以去挖。

參考鏈接

Spring源碼分析之WebMVC
Spring Boot中關(guān)于%2e的Trick