整合營銷服務商
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
電腦端+手機端+微信端=數據同步管理
免費咨詢熱線：
攜號轉網于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小時內與您取得聯系。
