Android應用:社會化授權登錄及分享安全漏洞

一、漏洞發現

先說說場景吧,由于業務要求,需要對分享控件做了一次大的升級和重構,然后發現我們分享組件使用的是第三方的ShareSDK(專門封裝分享API的組件,大部分童鞋應該都聽說過),這本來也沒什么問題。

然后,重構過程中遇到一個難以理解的事情,在工程assets目錄下面有一個名為ShareSDK.xml的文件,在打開這個文件之后,我震精了,喝到口的咖啡全噴到了鍵盤上,文件內容是這樣的:

這里寫圖片描述

第三方開放平臺的應用注冊信息都是明文寫在這個文件中的,包括重要的AppId和AppSecret(圖內容來自是ShareSDK官方demo)。這個時候,第一個考慮的問題還僅僅是隱私暴露,并沒有考慮到安全漏洞方面。

當然,接下來就去看這樣設計的原因,原來是ShareSDK內部調用第三方應用授權分享需要這些應用注冊信息,為了方便開發者接入,所以采用這種文件靜態注冊的方式。

作為一個開發者老司機,無論是直覺上還是開發原則上,都隱隱覺得這種方式是有嚴重問題的。為什么呢?因為assets目錄在打包過程中是原封不動地打進APK包內的,任何人不需要任何反編譯工具就能直接從APK包內提取出來。那么,如果直接提取出來放到另一款應用中是不是意味著……

想到這里,已經驚出一身冷汗了,世紀大坑!世紀大坑!世紀大坑??!

接下來就是驗證的過程,步驟非常簡單。 
1、找到一款接入ShareSDK組件的應用,將其安裝包APK內的ShareSDK.xml解壓提取出來。 
2、直接將項目的ShareSDK.xml替換為上一步的文件。 
3、調用分享

驗證結果:除了微信相關的不能分享,QQ和新浪都分享成功了,并且顯示分享內容來自XX應用,XX應用就是我們提取的那款應用了。


二、漏洞原因

當然,如果僅僅是這樣,只能說是小漏洞,波及范圍并不廣??上掠朐肝?,市場上90%以上的應用都在受災范圍內,原因后面分析。

為了幫助理解,我們先來談一談社會化分享的機制。

首先,一款應用要接入社會化的授權登錄分享等功能,需要到開發平臺上去注冊應用信息,注冊信息包括應用包名,應用簽名等等,以微信為例:

這里寫圖片描述

接著,應用注冊成功后,我們會得到兩個key,一個是AppId,一個是AppSecret(或AppKey):

這里寫圖片描述

當然,一般情況下,移動應用只需要AppId,而AppSecret主要是用在接口API調用。為了安全起見,微信開放平臺都已經不再存儲AppSecret,可想而知這些信息有多重要,所以在大家項目中無論是寫在Java代碼里還是配置在xml中,只要是明文,都是萬萬不可行的!

那么,第三方調用的機制流程是怎樣的呢,以微信為例:

步驟1:項目應用中集成微信SDK,也就是libammsdk.jar。 
步驟2:通過AppId調用微信SDK發送請求,比如登錄授權、分享等。 
步驟3:微信SDK將AppId、當前應用包名、請求信息發送到微信客戶端。 
步驟4:微信客戶端接收到AppId后,請求服務端得到我們注冊在開放平臺的應用包名、應用簽名、權限等。 
步驟5:微信客戶端比對注冊的應用包名和步驟3中的應用包名,不一致調用失敗。 
步驟6:微信客戶端比對注冊的應用簽名和請求應用的簽名(通過步驟3中的應用包名調用系統API查詢),不一致調用失敗。 
步驟7:調用相應的API,比如登錄授權、分享等,當然還要看注冊的應用是否有這些權限。

其中最關鍵是步驟5和步驟6,正是因為有了這兩步的包名和簽名校驗,所以之前驗證漏洞時微信分享調用失敗。

新浪微博和QQ的第三方調用機制流程大同小異,但是QQ完全不做包名和簽名校驗,也就是省略了步驟5和步驟6,所以驗證漏洞時分享成功。

新浪微博比較特殊,因為其除了客戶端調用還是支持網頁端調用,所以驗證漏洞時調用客戶端分享失敗,調用網頁端分享成功。

綜上所述,校驗包名和校驗簽名是防止惡意調用的防御手段,QQ和新浪微博網頁這種不做校驗的方式都是存在安全隱患的,只需要知道特定應用的AppId,就可以以其名義發起惡意的授權登錄分享。遺憾的是,很多開發者不清楚AppId的重要性,直接暴露在代碼或文件中。


三、漏洞升級

前面說了,事情并不僅僅是這么簡單。校驗包名和校驗簽名是防止惡意調用的防御手段,但是這種防御是否真的有用呢?

我們再來仔細梳理下流程,同樣以微信為例:

步驟3:微信SDK將AppId、當前應用包名、請求信息發送到微信客戶端。 
步驟5:微信客戶端比對注冊的應用包名和步驟3中的應用包名,不一致調用失敗。 
步驟6:微信客戶端比對注冊的應用簽名和請求應用的簽名(通過步驟3中的應用包名調用系統API查詢),不一致調用失敗。

這是其中最關鍵的三個步驟,微信客戶端接收到的AppId、應用包名都是來自微信SDK,而應用簽名是通過應用包名調用系統API獲取的,所以實質上校驗的來源只有AppId和應用包名兩個。

這里面有一個非常重要的但又非常容易忽略的點就是:系統查詢到的應用簽名,可能并不是發起調用的應用,而是手機上安裝的指定包名的應用。 換言之,步驟3中發送到微信客戶端的AppId和應用包名,如果就是被惡意攻擊的應用的AppId和包名,并且手機上裝有這款被攻擊的官方應用,那么步驟5和步驟6就全部被繞過了。

剩下的難點就是如何通過第三方SDK發送指定的AppId和包名給第三方客戶端了。

AppId容易得到,市場上幾乎所有應用里面接入的社交化AppId都是明文形式寫在代碼里面的,比如AndroidManifest.xml(天坑!天坑!天坑?。?。

最后一步就是偽裝包名了,在Android中獲取當前應用包名都是通過Context.getPackageName的方式,開發者調用SDK的時候傳入的參數就有這個Context,那么事情就變得無比簡單了!

這里寫圖片描述

這里寫圖片描述

另外,還有第二種方式,因為最終都是通過startActivity的方式調起第三方應用,參數都是通過Intent傳遞,我們可以在startActivity前將Intent中的參數包名替換掉,思路差不多,在此略過。

所以,只需要獲取到指定應用的包名,第三方AppId,就可以偽裝成這款應用發起第三方調用,而包名和AppId都是極其容易獲取的,當然為了繞過簽名校驗手機還必須裝有這款指定的官方應用。

下面,測試了國內幾款接入微信分享功能的知名應用,截圖如下:

這里寫圖片描述 這里寫圖片描述


四、漏洞危害

說完了漏洞,下面就要說這款漏洞的危害了,當然開發者節后也有的忙活了。

1、用戶隱私盜取

很多應用程序都接有第三方登錄授權的功能,有利于簡化用戶注冊過程。利用這個漏洞,攻擊者可以偽裝成官方應用騙取用戶授權,而且授權頁面是真真正正的授權頁,上面也確實顯示的是真正官方應用的logo和應用名。

授權成功之后,攻擊者拿到openId和access_token之后,再結合AppId和AppSecret,很容易就獲取到用戶的社交隱私,甚至如果抓包到接入第三方登錄功能應用的登錄接口,你的相關應用隱私也就一覽無余了。

相對來說,微信授權登錄還是比較安全的,因為授權結果是回調到WXEntryActivity的,由于應用applicationId的關系,回調的WXEntryActivity是難以被偽裝的,所以暫時還未想到其它攻擊手段,但依然是隱患。

2、虛假分享

和登錄授權不同,分享是不需要數據回調的,直接就分享出去了,那么利用這個漏洞的可操作性就高了,而且非常簡單。

攻擊者可以給微信好友(群組)、朋友圈、QQ好友(群組)和新浪微博上肆意分享危害性質的信息網站鏈接,而在這些社交應用里面,會顯示來自XX應用。比如利用此漏洞分享虛假新聞(來自XX頭條),分享虛假視頻(來自XX視頻),分享虛假話題(來自X乎),分享紅包優惠券(來自X東)等等。由于社交應用里面顯示的是來自官方應用,所以可信任度非常高,真假難辨,騙取用戶點擊的幾率可謂是100%,如果是釣魚鏈接,后果難以想象。


五、漏洞反思

經過數個小時的測試,目前市場上主流應用都在此漏洞危害范圍之內,幾乎被全軍盡墨,能夠幸免的應用屈指可數,想想背后都是一身冷汗。

關于這個漏洞,從兩個層面來分析下修復策略吧。

1、開發者

這個漏洞原理并不復雜,其中一個重要的因素就是開發者直接暴露出去AppId甚至AppSecret,由于開發者安全意識不夠,未認識到它們的重要性。直接的后果就是暴露出去無法收回,即使后面版本處理了,歷史版本里面仍然可以查到,可謂亡羊補牢為時晚矣!雖然這種事情難以避免,但仍然需要給我們一個血淋淋的教訓。在此,總結出以下兩點:

a、嚴禁明文暴露注冊第三方平臺的AppId、AppSecret,包括文件、代碼、接口,至少要做一層簡單的加密。 
b、接入ShareSDK授權登錄或分享的,必須在代碼中動態注冊AppId、AppSecret,同樣代碼中明文用的也應該是加密后的值。

2、第三方開放平臺

首先,鄙視下手Q,竟然連包名和簽名都不校驗,也不知道是為了簡化開發者接入流程還是其它原因,這不是坑爹么。

對于微信和新浪微博等開放平臺,需要重新思考下校驗機制,目前的包名+簽名校驗方式肯定是不安全的了,當然現在是不可能整體更換方案了,修復針對點是保證授權分享調起者是真正的官方應用。個人有以下幾點建議:

a、增加Context的校驗,防止使用自定義的Context偽裝包名(最簡單)。 
b、授權登錄回調禁用廣播監聽器等方式,使用指定Activity啟動回調,難以被攔截和偽裝,類似微信這種。 
c、接口API調用嚴禁明文暴露調用發起者的AppId、AppSecret,比如微信授權時chromium的log就能抓到這些信息。 
d、需要重視AppId,同時督促開發者?;ず謎廡┲匾?。

綜上所述,強烈建議開發者按照以上幾點排查和處理,同時希望第三方開放平臺盡快更新SDK和客戶端,修復此漏洞。

來源:CSDN-MegatronKing的博客

上一篇: Android 混淆從入門到精通

下一篇: 9款完美體驗的HTML5/jQuery應用

分享到: 更多
重庆时时彩稳赚公式 北京时时软件手机软件 二八杠生死门演示 7m篮球即时比分直播 宝马计划飞艇 手机上炸金花技巧规律 91y哪里可以上下分 体球网即时比分手机版 pk10如何学会看走势 pk10冠军4码3期计划 pk10最牛稳赚模式8码怎么打 腾讯分分彩软件计划两期中 西安二人麻将技巧 二十一点简单规则 北京塞车计划网全天更新 pk10计划软件5码手机版