路曄綿李軼夫應(yīng)凌云,3谷雅聰蘇璞睿,3馮登國

1(中國科學(xué)院軟件研究所可信計(jì)算與信息保障實(shí)驗(yàn)室 北京 100190)2(國家計(jì)算機(jī)網(wǎng)絡(luò)應(yīng)急技術(shù)處理協(xié)調(diào)中心 北京 100029)3(中國科學(xué)院大學(xué)計(jì)算機(jī)與控制學(xué)院 北京 101408)(luyemian@tca.iscas.ac.cn)

?

Android應(yīng)用第三方推送服務(wù)安全分析與安全增強(qiáng)

路曄綿1李軼夫2應(yīng)凌云1,3谷雅聰1蘇璞睿1,3馮登國1

1(中國科學(xué)院軟件研究所可信計(jì)算與信息保障實(shí)驗(yàn)室 北京 100190)2(國家計(jì)算機(jī)網(wǎng)絡(luò)應(yīng)急技術(shù)處理協(xié)調(diào)中心 北京 100029)3(中國科學(xué)院大學(xué)計(jì)算機(jī)與控制學(xué)院 北京 101408)(luyemian@tca.iscas.ac.cn)

推送服務(wù)已成為移動智能終端應(yīng)用的一個(gè)基礎(chǔ)服務(wù)，各大手機(jī)平臺及互聯(lián)網(wǎng)公司相繼推出了各自的推送服務(wù)供應(yīng)用程序開發(fā)者使用.為了降低資源消耗，部分第三方Android推送服務(wù)采用共享通道的設(shè)計(jì)方式，在設(shè)備上使用某個(gè)應(yīng)用的推送后臺組件作為其他應(yīng)用推送數(shù)據(jù)的分發(fā)中心.由于缺乏針對數(shù)據(jù)機(jī)密性、完整性、不可偽造性等安全需求的設(shè)計(jì)與實(shí)現(xiàn)，數(shù)據(jù)分發(fā)環(huán)節(jié)面臨多種攻擊的威脅.分析了使用共享通道的第三方Android推送服務(wù)在數(shù)據(jù)分發(fā)環(huán)節(jié)存在的安全問題，通過在攻擊程序中Hook相關(guān)API調(diào)用的方法，實(shí)現(xiàn)了針對其他應(yīng)用推送數(shù)據(jù)的竊聽、篡改、偽造和重放攻擊，實(shí)驗(yàn)結(jié)果表明:大部分共享通道的第三方Android推送服務(wù)無法抵抗這些攻擊，可能造成用戶隱私數(shù)據(jù)泄露和釣魚攻擊等實(shí)際危害.在上述研究的基礎(chǔ)上，設(shè)計(jì)并實(shí)現(xiàn)了Android應(yīng)用推送服務(wù)安全增強(qiáng)方案SecPush，使用加密算法及HMAC運(yùn)算提供推送數(shù)據(jù)分發(fā)環(huán)節(jié)的安全保護(hù)，實(shí)驗(yàn)結(jié)果表明:SecPush提高了推送數(shù)據(jù)的安全性，可有效抵擋竊聽、篡改、偽造和重放等攻擊行為.

安卓；推送服務(wù)；數(shù)據(jù)分發(fā)；共享通道；安全分析；安全增強(qiáng)

推送服務(wù)是當(dāng)今移動智能終端應(yīng)用的一個(gè)基礎(chǔ)需求，通過維持應(yīng)用程序客戶端與推送服務(wù)器之間的socket長連接，推送服務(wù)允許應(yīng)用程序開發(fā)者通過推送服務(wù)器主動向客戶端發(fā)送信息.與客戶端通過輪詢來獲取信息的方式相比，推送服務(wù)降低了資源消耗，同時(shí)保證了消息的實(shí)時(shí)性，因此移動智能終端應(yīng)用程序開發(fā)者廣泛使用推送服務(wù)向用戶發(fā)送新產(chǎn)品信息、活動預(yù)告、社交信息、新版本更新通知等消息.通過使用推送服務(wù)，開發(fā)者在及時(shí)發(fā)布信息的同時(shí)，可以顯著提升用戶的留存率和活躍度.根據(jù)Urban Airship于2013年12月發(fā)布的針對使用推送服務(wù)的移動應(yīng)用進(jìn)行統(tǒng)計(jì)分析的結(jié)果[1]顯示，開啟推送功能的用戶留存率約是不使用推送的用戶的2倍.

推送服務(wù)極大地簡化了移動終端應(yīng)用開發(fā)者的開發(fā)過程，然而其在帶來巨大便利的同時(shí)也帶來了一些安全隱患.Li等人[2]對推送服務(wù)中應(yīng)用程序的注冊操作和PendingIntent對象的使用進(jìn)行了詳細(xì)的分析，指出攻擊者通過精心的設(shè)計(jì)，可以獲取本應(yīng)發(fā)送給目標(biāo)設(shè)備上目標(biāo)應(yīng)用用戶的隱私數(shù)據(jù)，或?qū)е履繕?biāo)應(yīng)用執(zhí)行攻擊者發(fā)送的命令.Li等人的分析多集中在應(yīng)用程序的注冊過程和信息上傳過程，對目標(biāo)設(shè)備上推送數(shù)據(jù)傳遞環(huán)節(jié)的安全性缺少詳細(xì)的分析.

目標(biāo)設(shè)備上推送數(shù)據(jù)的傳遞過程存在3種實(shí)現(xiàn)方式:

1) 推送服務(wù)使用移動終端操作系統(tǒng)自身模塊或系統(tǒng)應(yīng)用作為推送數(shù)據(jù)的轉(zhuǎn)發(fā)中心，推送數(shù)據(jù)經(jīng)由推送服務(wù)器發(fā)送給目標(biāo)設(shè)備后由該轉(zhuǎn)發(fā)中心傳遞給目標(biāo)應(yīng)用，例如蘋果官方的APNS[2](Apple push notification service)服務(wù)使用iOS自身功能模塊作為推送數(shù)據(jù)的轉(zhuǎn)發(fā)中心、谷歌官方的GCM[3](Google cloud messaging)服務(wù)使用Google Play Store應(yīng)用轉(zhuǎn)發(fā)推送數(shù)據(jù)，基于官方推送服務(wù)開發(fā)的第三方推送服務(wù)也屬于這種方式.這種實(shí)現(xiàn)方式一方面在目標(biāo)設(shè)備上只維持了1條長連接，供推送數(shù)據(jù)轉(zhuǎn)發(fā)中心與推送服務(wù)器進(jìn)行數(shù)據(jù)交互，降低了資源消耗；另一方面，作為轉(zhuǎn)發(fā)中心的系統(tǒng)模塊或者官方應(yīng)用很難被外來攻擊者攻破，在一定程度上保證了數(shù)據(jù)轉(zhuǎn)發(fā)環(huán)節(jié)的安全性.

2) 同一設(shè)備上使用同一推送服務(wù)的每個(gè)應(yīng)用各自維持其與推送服務(wù)器之間的socket長連接，推送服務(wù)器發(fā)送給目標(biāo)應(yīng)用的推送數(shù)據(jù)由該應(yīng)用中嵌入的推送服務(wù)客戶端SDK獨(dú)立接收并處理，其他應(yīng)用無法對該過程進(jìn)行干涉.極光推送、小米推送等第三方Android推送服務(wù)使用該方式實(shí)現(xiàn).這種實(shí)現(xiàn)方式只要保證推送數(shù)據(jù)僅可在應(yīng)用內(nèi)部傳遞即可保證其安全性，然而設(shè)備上將存在多條與推送服務(wù)器之間的socket長連接，耗費(fèi)資源過多.

3) 同一臺設(shè)備上使用同一推送服務(wù)的多個(gè)應(yīng)用之間共享1條長連接，將其中某個(gè)應(yīng)用的推送Service組件作為推送數(shù)據(jù)的轉(zhuǎn)發(fā)中心，本文使用PDDS(push data distribution service)代指該組件.應(yīng)用程序開發(fā)者的推送數(shù)據(jù)將首先由推送服務(wù)器發(fā)送給目標(biāo)設(shè)備上的PDDS組件，由PDDS組件進(jìn)行簡單處理后將數(shù)據(jù)轉(zhuǎn)發(fā)給目標(biāo)應(yīng)用.百度云推送、友盟推送、騰訊信鴿推送等第三方Android推送服務(wù)使用該方式實(shí)現(xiàn).這種方式可以避免同一設(shè)備上存在多條與推送服務(wù)器之間的socket長連接，節(jié)省資源，但是與官方推送服務(wù)的設(shè)計(jì)相比，卻增加了額外的安全風(fēng)險(xiǎn).由于目標(biāo)設(shè)備上的PDDS組件是由某個(gè)應(yīng)用使用的推送SDK創(chuàng)建，與宿主應(yīng)用運(yùn)行在同一應(yīng)用空間，因此宿主應(yīng)用可以完全控制PDDS組件的運(yùn)行.當(dāng)推送服務(wù)沒有提供數(shù)據(jù)加密等安全保護(hù)措施時(shí)，PDDS組件的宿主應(yīng)用可以通過控制PDDS組件獲取推送給其他應(yīng)用的信息，甚至于偽造消息發(fā)送給目標(biāo)應(yīng)用，這將給用戶帶來極大的安全隱患.

本文對使用PDDS組件的第三方Android推送服務(wù)進(jìn)行了詳細(xì)的分析，發(fā)現(xiàn)其中多數(shù)推送服務(wù)缺乏對推送數(shù)據(jù)分發(fā)環(huán)節(jié)安全性的有效保護(hù)，包括其市場占有率居于前幾位的百度云推送、友盟推送和騰訊信鴿推送.數(shù)據(jù)分發(fā)環(huán)節(jié)安全措施的缺乏可能導(dǎo)致用戶的隱私信息被泄露，或?qū)⒂脩糁糜卺烎~攻擊的威脅之下.本文設(shè)計(jì)了相應(yīng)的攻擊模型以檢測推送服務(wù)在數(shù)據(jù)分發(fā)環(huán)節(jié)的安全性，通過在攻擊程序中對推送服務(wù)的函數(shù)調(diào)用進(jìn)行Hook，實(shí)現(xiàn)了針對推送數(shù)據(jù)的竊聽、篡改、偽造和重放攻擊.最后，針對發(fā)現(xiàn)的安全問題，本文提出了相應(yīng)的安全增強(qiáng)方案.

本文的貢獻(xiàn)主要包括4個(gè)方面：

1) 分析了第三方Android推送服務(wù)數(shù)據(jù)分發(fā)環(huán)節(jié)安全機(jī)制的實(shí)現(xiàn)情況，并設(shè)計(jì)了相應(yīng)的攻擊模型；

2) 針對多個(gè)推送服務(wù)進(jìn)行了實(shí)際分析和攻擊測試，實(shí)驗(yàn)結(jié)果表明，多數(shù)第三方Android推送服務(wù)面臨著竊聽、篡改、偽造和重放攻擊的威脅；

3) 提出了Android推送服務(wù)安全增強(qiáng)方案SecPush，通過添加加密模塊和HMAC運(yùn)算增強(qiáng)推送服務(wù)數(shù)據(jù)分發(fā)環(huán)節(jié)的安全性，實(shí)現(xiàn)了數(shù)據(jù)機(jī)密性、完整性、不可偽造性和抗重放攻擊的安全需求；

4) 實(shí)現(xiàn)了SecPush原型系統(tǒng)，并對其進(jìn)行安全測試，實(shí)驗(yàn)結(jié)果表明，SecPush能有效抵擋竊聽、篡改、偽造和重放攻擊.

1 第三方Android推送服務(wù)的使用模式

本文的研究對象是使用PDDS組件進(jìn)行推送數(shù)據(jù)分發(fā)的第三方Android推送服務(wù)，其整體架構(gòu)如圖1所示：

Fig. 1 Framework of third-party Android push service.圖1 第三方Android推送服務(wù)架構(gòu)

Push SDK為嵌入目標(biāo)應(yīng)用的推送SDK；Push Server為推送服務(wù)器；Portal為推送服務(wù)的Web前端，由推送服務(wù)提供商開發(fā)維護(hù)，方便應(yīng)用程序開發(fā)者在不開發(fā)服務(wù)端代碼的情況下發(fā)送推送信息；Application Server是開發(fā)者為其應(yīng)用開發(fā)的服務(wù)器端，使用推送服務(wù)的服務(wù)器端SDK實(shí)現(xiàn)推送相關(guān)功能，開發(fā)者可以通過Application Server向Push Server發(fā)送推送消息，由Push Server將該消息推送給目標(biāo)應(yīng)用.

推送服務(wù)的交互流程如下：

1) 應(yīng)用程序調(diào)用Push SDK的初始化函數(shù)，Push SDK將應(yīng)用的包名、應(yīng)用創(chuàng)建時(shí)從推送平臺獲取的APP_ID等信息傳遞給Push Server，完成應(yīng)用信息的注冊，獲取ClientId作為當(dāng)前設(shè)備上當(dāng)前應(yīng)用在Push Server上的用戶標(biāo)識，供應(yīng)用程序開發(fā)者向當(dāng)前設(shè)備上的應(yīng)用發(fā)送數(shù)據(jù)時(shí)使用；

2) Push SDK檢查當(dāng)前應(yīng)用是否是該設(shè)備上第1個(gè)使用Push SDK的應(yīng)用程序，若是，則建立設(shè)備與Push Server之間的socket長連接，用以接收推送數(shù)據(jù)，并定時(shí)發(fā)送心跳包以維持該連接，管理該連接的Service組件即為設(shè)備上的PDDS組件；

3) 應(yīng)用程序開發(fā)者通過Portal或Application Server將推送數(shù)據(jù)提交給Push Server；

4) Push Server使用其與目標(biāo)應(yīng)用所在設(shè)備之間的socket長連接將推送數(shù)據(jù)發(fā)送給目標(biāo)設(shè)備上的PDDS組件；

5) PDDS組件對收到的數(shù)據(jù)進(jìn)行預(yù)處理，判斷目標(biāo)應(yīng)用，將推送數(shù)據(jù)傳遞給目標(biāo)應(yīng)用；

6) 目標(biāo)應(yīng)用的消息接收器根據(jù)推送數(shù)據(jù)類型進(jìn)行后續(xù)處理.

多數(shù)第三方Android推送服務(wù)提供2種類型的推送數(shù)據(jù)：1)通知類推送；2)透傳信息.通知類推送將在設(shè)備通知欄展現(xiàn)1條通知，用戶點(diǎn)擊該通知后，根據(jù)具體類型的不同，Android系統(tǒng)或者打開目標(biāo)應(yīng)用的某個(gè)界面，或者通過系統(tǒng)瀏覽器或目標(biāo)應(yīng)用使用的WebView控件打開某個(gè)網(wǎng)頁，通知類推送的處理一般由推送服務(wù)SDK自己實(shí)現(xiàn)；而透傳信息則是由應(yīng)用程序開發(fā)者設(shè)計(jì)其獨(dú)有的數(shù)據(jù)格式及相應(yīng)的處理方式，推送服務(wù)只負(fù)責(zé)將推送數(shù)據(jù)傳遞給目標(biāo)應(yīng)用，不負(fù)責(zé)后續(xù)的處理過程.

通過提供多樣化的推送方式，推送服務(wù)可以應(yīng)用于多種場景，包括面向多數(shù)用戶的新產(chǎn)品推薦、運(yùn)營活動通知以及面向特定用戶的好友互動提醒、聊天信息推送等.多數(shù)推送服務(wù)都將上述場景作為典型應(yīng)用場景介紹給用戶，然而很少有推送服務(wù)提供這些應(yīng)用場景需要的安全保護(hù)措施.部分推送服務(wù)考慮到網(wǎng)絡(luò)數(shù)據(jù)傳輸?shù)陌踩?，使用TLS協(xié)議進(jìn)行傳輸，或者將推送數(shù)據(jù)加密后傳輸，以對抗來自網(wǎng)絡(luò)的攻擊者，然而對于推送SDK在設(shè)備上進(jìn)行推送數(shù)據(jù)分發(fā)過程的安全性卻少有考慮，由于進(jìn)行推送數(shù)據(jù)分發(fā)的PDDS組件由設(shè)備上某個(gè)應(yīng)用程序創(chuàng)建，可被該應(yīng)用完全控制，因此一旦PDDS組件的宿主應(yīng)用是攻擊者控制的惡意應(yīng)用，攻擊者即可通過PDDS組件獲取傳送給其他應(yīng)用的數(shù)據(jù)，進(jìn)行竊聽、篡改等攻擊，推送SDK的數(shù)據(jù)分發(fā)環(huán)節(jié)將成為整個(gè)推送服務(wù)運(yùn)行過程中最為薄弱的環(huán)節(jié).

2 推送服務(wù)數(shù)據(jù)分發(fā)環(huán)節(jié)安全性分析

本節(jié)主要分析第三方Android推送服務(wù)數(shù)據(jù)分發(fā)環(huán)節(jié)中存在的安全問題，并介紹敵手能力及相應(yīng)的攻擊模型.

2.1 安全目標(biāo)

根據(jù)推送服務(wù)的典型應(yīng)用場景，開發(fā)者使用推送服務(wù)推送的數(shù)據(jù)大致可以分為公開信息和私密信息2類.對于前者而言，推送服務(wù)應(yīng)保證數(shù)據(jù)在傳送給目標(biāo)應(yīng)用的途中未被篡改，不會被攻擊者利用構(gòu)建釣魚攻擊等攻擊場景；對于后者而言，推送服務(wù)應(yīng)保證推送數(shù)據(jù)的機(jī)密性，不能被攻擊者竊聽以獲取用戶隱私信息.整體而言，推送服務(wù)數(shù)據(jù)分發(fā)環(huán)節(jié)的設(shè)計(jì)應(yīng)充分考慮機(jī)密性、完整性、不可偽造性和抗重放攻擊4個(gè)安全需求.

具體來說，機(jī)密性應(yīng)保證目標(biāo)應(yīng)用收到的推送數(shù)據(jù)未被泄露給他人，或即使數(shù)據(jù)被竊聽，敵手也無法獲知數(shù)據(jù)的明文信息；完整性應(yīng)保證目標(biāo)應(yīng)用收到的推送數(shù)據(jù)未被篡改；不可偽造性應(yīng)保證目標(biāo)應(yīng)用收到的數(shù)據(jù)只能是其開發(fā)者通過推送服務(wù)器發(fā)送的數(shù)據(jù)，敵手不能偽造新的推送數(shù)據(jù)發(fā)送給目標(biāo)應(yīng)用而不被識別；抗重放攻擊應(yīng)保證目標(biāo)應(yīng)用能夠判斷收到的數(shù)據(jù)是否已被處理過，已收到并處理過的數(shù)據(jù)不再進(jìn)行重復(fù)處理.

2.2 敵手能力分析

推送服務(wù)數(shù)據(jù)分發(fā)環(huán)節(jié)的核心參與者是PDDS組件，可控制PDDS組件運(yùn)行的宿主應(yīng)用為該環(huán)節(jié)的攻擊者.

根據(jù)作者對目前市場上存在的第三方Android推送SDK的分析，大部分推送SDK將PDDS組件設(shè)定為設(shè)備上安裝的第1個(gè)使用該SDK的應(yīng)用所創(chuàng)建的推送Service組件，因此，當(dāng)使用了某個(gè)推送SDK的攻擊程序先于目標(biāo)應(yīng)用安裝于同一設(shè)備上時(shí)，攻擊者可以通過控制PDDS組件實(shí)施針對目標(biāo)應(yīng)用的攻擊.然而這個(gè)條件并不是必須的，根據(jù)作者的分析，推送SDK通常會通過添加并維護(hù)某個(gè)系統(tǒng)屬性值的方式或者通過檢測系統(tǒng)中正在運(yùn)行的Service組件等方式進(jìn)行PDDS組件的設(shè)定和判斷，通過修改相應(yīng)的系統(tǒng)屬性值或者函數(shù)調(diào)用返回值，可以在目標(biāo)應(yīng)用先于攻擊程序安裝的情況下，將攻擊程序創(chuàng)建的推送Service組件作為設(shè)備的PDDS組件.只要攻擊程序可以將自己的推送Service組件設(shè)定為PDDS組件，攻擊者就可以通過控制PDDS組件控制發(fā)送給目標(biāo)應(yīng)用的推送數(shù)據(jù).

此外攻擊者可以通過反編譯目標(biāo)應(yīng)用的apk文件，從程序代碼中獲取感興趣的信息，例如獲取目標(biāo)應(yīng)用的APP_ID、目標(biāo)應(yīng)用服務(wù)器的網(wǎng)址及相關(guān)參數(shù)格式信息等.通過這種方式，攻擊者可以目標(biāo)應(yīng)用的身份向推送服務(wù)器或目標(biāo)應(yīng)用服務(wù)器發(fā)起一些網(wǎng)絡(luò)請求.

本文設(shè)定的攻擊程序不具備root權(quán)限，因此可以在所有使用Android系統(tǒng)的設(shè)備上實(shí)施攻擊.由于攻擊程序與目標(biāo)應(yīng)用屬于不同的應(yīng)用，根據(jù)Android系統(tǒng)中進(jìn)程沙箱隔離機(jī)制的設(shè)計(jì)，在未獲取root權(quán)限的情況下，攻擊程序無法干涉目標(biāo)應(yīng)用的運(yùn)行，也無法獲取目標(biāo)應(yīng)用通過其他途徑進(jìn)行網(wǎng)絡(luò)通信的數(shù)據(jù).

針對2.1節(jié)中描述的安全目標(biāo)，攻擊者可能實(shí)施的攻擊如下：

1) 消息竊聽

由于通過目標(biāo)推送服務(wù)傳輸?shù)臄?shù)據(jù)都需要經(jīng)過PDDS組件的處理，因此可以在PDDS組件收到數(shù)據(jù)并分發(fā)給目標(biāo)應(yīng)用的過程中獲取傳送給所有目標(biāo)應(yīng)用的數(shù)據(jù).當(dāng)推送數(shù)據(jù)涉及私聊信息等用戶隱私數(shù)據(jù)且未經(jīng)加密保護(hù)時(shí)，該攻擊將導(dǎo)致用戶隱私信息的泄露.

圖2所示為使用百度云推送服務(wù)的攻擊程序通過竊聽獲取的同一設(shè)備上“Pogo看演出”應(yīng)用的用戶lulu收到的私聊信息.從中可以獲取私聊信息的明文“hello, I’m Alice”、發(fā)送者的昵稱“roadinmind”等信息.

Fig. 2 Private chat information of Pogo user obtained by eavesdropping.圖2 通過竊聽獲取的Pogo用戶的私聊信息

除了獲取用戶隱私信息，攻擊者還可以從竊聽到的數(shù)據(jù)中獲取目標(biāo)應(yīng)用的APP_ID、消息格式等信息，這些信息將有助于構(gòu)造符合格式要求的偽造數(shù)據(jù).此外消息篡改和重放攻擊也需要首先獲取目標(biāo)應(yīng)用應(yīng)接收的正確數(shù)據(jù)以作修改或重放.可以認(rèn)為，竊聽攻擊是攻擊者進(jìn)行后續(xù)攻擊的基礎(chǔ).

2) 消息篡改

PDDS組件的宿主應(yīng)用可以對收到數(shù)據(jù)的部分字段進(jìn)行修改，將篡改后的數(shù)據(jù)發(fā)送給目標(biāo)應(yīng)用.直接篡改開發(fā)者發(fā)送的正確消息，可以提高虛假消息成功發(fā)送的概率，降低用戶的疑心，為釣魚攻擊等后續(xù)攻擊提供方便.

圖3所示為使用百度云推送服務(wù)的攻擊程序通過修改同一設(shè)備上的“當(dāng)當(dāng)讀書”應(yīng)用發(fā)送的新書推薦消息，誘使用戶打開通知并輸入用戶名密碼的攻擊.其中，圖3(a)所示為用戶點(diǎn)擊通知后展示的網(wǎng)頁內(nèi)容，圖3(b)所示為用戶點(diǎn)擊“點(diǎn)擊領(lǐng)取”按鈕后請求用戶輸入登錄信息的頁面.

Fig. 3 Phishing attack through tampering.圖3 通過消息篡改進(jìn)行釣魚攻擊

3) 消息偽造

通過分析竊聽攻擊獲得數(shù)據(jù)的數(shù)據(jù)格式，PDDS組件的宿主應(yīng)用可以偽造1條符合格式要求的新消息發(fā)送給目標(biāo)應(yīng)用，經(jīng)過目標(biāo)應(yīng)用的正確處理后將內(nèi)容展示給用戶.

偽造攻擊可以獲得與篡改攻擊相似的攻擊效果，作者通過偽造消息的方式，同樣實(shí)現(xiàn)了圖3中展示的釣魚攻擊.與篡改攻擊相比，偽造攻擊更為靈活，攻擊者可以選擇在任何合適的時(shí)間發(fā)送偽造的消息.

圖4所示為攻擊者假冒“Pogo看演出”的用戶roadinmind構(gòu)造虛假消息發(fā)送給用戶lulu的攻擊.其中，圖4(a)所示為消息的接收者lulu看到的消息界面，lulu收到的偽造消息內(nèi)容為“這是假消息”；圖4(b)所示為用戶roadinmind的私聊界面，其中并沒有“這是假消息”這條消息顯示，證明該偽造攻擊對于用戶雙方都是不可感知的.

Fig. 4 Forgery attack for Pogo.圖4 針對Pogo應(yīng)用的偽造攻擊

如果攻擊者可以通過其他方式控制“Pogo看演出”應(yīng)用網(wǎng)絡(luò)數(shù)據(jù)的發(fā)送，那么攻擊者可以截獲用戶lulu發(fā)出的所有信息，在這種情況下，攻擊者完全可以偽裝成“Pogo看演出”應(yīng)用的合法用戶與lulu進(jìn)行私聊，從而實(shí)施社會工程學(xué)攻擊.

4) 消息重放

PDDS組件的宿主應(yīng)用可以將收到的數(shù)據(jù)重復(fù)發(fā)送給目標(biāo)應(yīng)用，如果目標(biāo)應(yīng)用不檢測數(shù)據(jù)的新鮮性，將會再次處理重放消息.

2.3 攻擊實(shí)現(xiàn)

本文通過在攻擊程序中Hook推送SDK的相關(guān)函數(shù)調(diào)用實(shí)現(xiàn)針對推送數(shù)據(jù)的竊聽、篡改、偽造和重放攻擊.由于實(shí)現(xiàn)Hook功能的代碼與Hook操作的對象同屬于攻擊程序，因此攻擊程序不需要請求root權(quán)限就可以實(shí)現(xiàn)對PDDS的控制，事實(shí)上，攻擊程序只需要申請推送SDK運(yùn)行所必需的權(quán)限便可以實(shí)施上述4種攻擊.為了實(shí)現(xiàn)Hook功能，本文使用了GitHub上的公開庫ZHookLib[3].

實(shí)現(xiàn)對PDDS組件的控制之后，通過Hook PDDS組件向目標(biāo)應(yīng)用分發(fā)數(shù)據(jù)的函數(shù)，攻擊程序可以實(shí)現(xiàn)針對推送數(shù)據(jù)的竊聽和篡改攻擊.另一方面，由于目標(biāo)應(yīng)用接收推送數(shù)據(jù)的組件多數(shù)是BroadcastReceiver組件，且出于實(shí)現(xiàn)功能的需要無法通過設(shè)置發(fā)送者權(quán)限進(jìn)行有效保護(hù)，因此實(shí)際上任意Android應(yīng)用都可以向目標(biāo)應(yīng)用發(fā)送格式及編碼符合要求的偽造消息.

攻擊模型原理圖如圖5所示.其中Application 1為攻擊程序，Application 2為目標(biāo)應(yīng)用，PDDS組件由Application 1創(chuàng)建，Hook Service與Forge_Replay為攻擊模塊.Hook Service通過對sendBroadcast等函數(shù)進(jìn)行Hook，獲取放置在Intent類型參數(shù)中的推送數(shù)據(jù)，實(shí)施竊聽和篡改攻擊；Forge_Replay模塊使用竊聽攻擊獲取的數(shù)據(jù)實(shí)施偽造和重放攻擊.

圖5中實(shí)線箭頭所示為推送SDK分發(fā)數(shù)據(jù)的正常途徑，步驟如下：

Step1. Push Server將推送數(shù)據(jù)發(fā)送給目標(biāo)設(shè)備上的PDDS組件；

Step2. PDDS組件對數(shù)據(jù)進(jìn)行簡單處理，判斷目標(biāo)應(yīng)用為Application 2，通過sendBroadcast等函數(shù)將數(shù)據(jù)發(fā)送給Application 2相應(yīng)的Push Receiver.

本文的攻擊模型是在數(shù)據(jù)分發(fā)的第2步實(shí)施攻擊，圖5中虛線箭頭所示即為攻擊過程，步驟如下：

Step1′. Push Server將推送數(shù)據(jù)發(fā)送給目標(biāo)設(shè)備上的PDDS組件，同Step1；

Step2′. Hook Service截獲PDDS對send-Broadcast等函數(shù)的調(diào)用，從Intent類型參數(shù)中獲取推送數(shù)據(jù)進(jìn)行分析，同時(shí)修改推送數(shù)據(jù)的內(nèi)容；

Step3′. Hook Service將篡改后的推送數(shù)據(jù)通過sendBroadcast等函數(shù)發(fā)送給目標(biāo)應(yīng)用Application 2對應(yīng)的Push Receiver，實(shí)施篡改攻擊；

Step4′. 攻擊程序通過分析Step2′中竊聽到的數(shù)據(jù)，偽造合適的推送數(shù)據(jù)發(fā)送給目標(biāo)應(yīng)用，或者將Step2′中竊聽到的推送數(shù)據(jù)重復(fù)發(fā)送給目標(biāo)應(yīng)用，實(shí)施重放攻擊.

通過使用上述攻擊模型，作者對市場上6款第三方Android推送服務(wù)進(jìn)行了攻擊測試，實(shí)驗(yàn)結(jié)果表明，多數(shù)使用PDDS組件的第三方Android推送服務(wù)無法抵抗竊聽、篡改、偽造和重放攻擊，沒有實(shí)現(xiàn)其聲稱的典型應(yīng)用場景所需要的安全需求，威脅用戶的使用安全，其中包括開發(fā)者廣泛使用的百度云推送、友盟推送、騰訊信鴿推送等推送服務(wù).具體實(shí)驗(yàn)結(jié)果在本文4.1節(jié)中展示.

Fig. 5 Attack model.圖5 攻擊模型原理圖

3 SecPush的設(shè)計(jì)與實(shí)現(xiàn)

由于現(xiàn)有的第三方Android推送服務(wù)很少考慮到數(shù)據(jù)分發(fā)環(huán)節(jié)的安全性需求，使得應(yīng)用程序的最終用戶可能暴露在隱私數(shù)據(jù)泄露和釣魚攻擊等安全威脅之下.為了保證應(yīng)用程序最終用戶的使用安全，使用現(xiàn)有推送服務(wù)的應(yīng)用程序開發(fā)者只能自己實(shí)現(xiàn)推送數(shù)據(jù)的加密保護(hù)及完整性驗(yàn)證等安全需求，這將給開發(fā)者帶來額外的開發(fā)負(fù)擔(dān)，而且由于推送服務(wù)本身不支持上述安全需求，應(yīng)用程序開發(fā)者只能在推送服務(wù)提供的多樣化推送方式和安全之間做出折中選擇.因此完全依賴應(yīng)用程序開發(fā)者自己實(shí)現(xiàn)相關(guān)的安全需求是不合理的.另一方面，推送服務(wù)宣稱的典型應(yīng)用場景也要求其實(shí)現(xiàn)相應(yīng)的安全保護(hù)措施.因此，從根本上提高第三方Android推送服務(wù)的安全性，才是促進(jìn)第三方Android推送服務(wù)產(chǎn)業(yè)發(fā)展的有效措施.本文設(shè)計(jì)并實(shí)現(xiàn)了Android應(yīng)用推送服務(wù)安全增強(qiáng)方案SecPush，以增強(qiáng)推送服務(wù)中數(shù)據(jù)分發(fā)環(huán)節(jié)的安全性，保護(hù)應(yīng)用程序的最終用戶免受隱私泄露和釣魚等攻擊的威脅.

本節(jié)主要介紹SecPush的設(shè)計(jì)原理、安全性分析及局限性分析.

3.1 系統(tǒng)設(shè)計(jì)

SecPush的設(shè)計(jì)目標(biāo)在于增強(qiáng)推送數(shù)據(jù)分發(fā)環(huán)節(jié)的安全性，實(shí)現(xiàn)數(shù)據(jù)機(jī)密性、完整性、不可偽造性和抗重放攻擊的安全需求.SecPush采用對稱加密及HMAC運(yùn)算提供數(shù)據(jù)機(jī)密性、完整性和不可偽造性保護(hù)，通過數(shù)據(jù)庫保存和查詢推送消息Id的方式提供消息重放檢測功能.具體設(shè)計(jì)描述如下:

3.1.1 密鑰分配方案設(shè)計(jì)

應(yīng)用程序與推送服務(wù)器之間需要共享對稱密鑰和HMAC運(yùn)算密鑰方可完成推送數(shù)據(jù)的加解密運(yùn)算和HMAC驗(yàn)證，設(shè)計(jì)安全的密鑰分配方案保護(hù)目標(biāo)應(yīng)用的密鑰不被敵手獲取是保證SecPush方案安全性的關(guān)鍵.

根據(jù)推送服務(wù)的典型應(yīng)用場景，推送數(shù)據(jù)可以大致分為2種類型：1)面向應(yīng)用程序多數(shù)用戶發(fā)送的公開信息，例如新產(chǎn)品推薦、活動通知等；2)針對特定用戶發(fā)送的私密信息，例如新增評論、私聊信息等.2種類型數(shù)據(jù)的安全需求不同，對于公開信息而言，機(jī)密性并不是必要需求，因?yàn)槿魏问褂迷搼?yīng)用程序的用戶都可能收到這些公開通知，對于這類信息而言，安全防護(hù)的重點(diǎn)在于防止信息內(nèi)容被攻擊者篡改或偽造從而進(jìn)行釣魚等后續(xù)攻擊.對于私密信息而言，數(shù)據(jù)機(jī)密性、完整性、不可偽造性和抗重放攻擊都是進(jìn)行安全防護(hù)的重要目標(biāo).根據(jù)不同的安全需求，SecPush設(shè)計(jì)了不同的密鑰分配方案.

對于公開信息推送，推送服務(wù)器在應(yīng)用程序通過SecPush客戶端SDK進(jìn)行應(yīng)用信息注冊時(shí)生成當(dāng)前應(yīng)用在當(dāng)前設(shè)備上使用的加密密鑰和HMAC運(yùn)算密鑰，將其作為注冊請求的響應(yīng)數(shù)據(jù)傳遞給應(yīng)用程序.在應(yīng)用程序因某些原因重新發(fā)起注冊請求后，服務(wù)器將生成新的密鑰替換之前的密鑰傳遞給應(yīng)用程序并使用新的密鑰進(jìn)行加密和HMAC運(yùn)算.由于攻擊程序無法獲取目標(biāo)應(yīng)用與推送服務(wù)器之間直接的網(wǎng)絡(luò)通信數(shù)據(jù)，因此攻擊程序無法獲取目標(biāo)應(yīng)用的密鑰，無法對使用這些密鑰進(jìn)行保護(hù)的推送數(shù)據(jù)進(jìn)行解密和篡改.另一方面，即使攻擊程序偽裝成目標(biāo)應(yīng)用向推送服務(wù)器發(fā)起注冊請求，其獲取的密鑰也與目標(biāo)應(yīng)用正在使用的密鑰不同，此時(shí)攻擊程序可以解密推送服務(wù)器使用新密鑰發(fā)送給目標(biāo)應(yīng)用的公開推送數(shù)據(jù)，但是不能構(gòu)造可以被目標(biāo)應(yīng)用正確處理的篡改信息和偽造信息.在整個(gè)過程中，攻擊者最多只能實(shí)施竊聽攻擊，無法實(shí)施其他攻擊.而攻擊者通過竊聽獲取的只是目標(biāo)應(yīng)用的公開通知，對攻擊者而言價(jià)值不大.相應(yīng)地，目標(biāo)應(yīng)用可能因?yàn)樗妹荑€與推送服務(wù)器不同導(dǎo)致無法解析其應(yīng)當(dāng)收到的數(shù)據(jù)，但考慮到使用公開通知發(fā)送的信息一般對于用戶而言并不重要，且應(yīng)用程序在下一次發(fā)起注冊請求時(shí)依舊可以與服務(wù)器同步密鑰，正確收到之后的公開通知，因此上述密鑰分配方案具備現(xiàn)實(shí)可用性.

對于私密信息推送而言，推送內(nèi)容一般與應(yīng)用程序的特定用戶相關(guān)聯(lián)，需要在用戶登錄應(yīng)用程序賬號后才可以接收相應(yīng)的通知信息，因此可以在應(yīng)用程序向其服務(wù)器發(fā)送登錄請求時(shí)由應(yīng)用程序服務(wù)器根據(jù)登錄用戶名、密碼及其他相關(guān)參數(shù)生成該用戶在當(dāng)前設(shè)備上使用的推送數(shù)據(jù)加密密鑰和HMAC運(yùn)算密鑰.由于攻擊程序無法獲取目標(biāo)應(yīng)用與其服務(wù)器之間的網(wǎng)絡(luò)通信數(shù)據(jù)，因此攻擊者無法直接獲取目標(biāo)應(yīng)用服務(wù)器返回的密鑰信息.另一方面，由于攻擊者不知道目標(biāo)應(yīng)用當(dāng)前用戶的用戶名和密碼，因此無法偽裝成目標(biāo)應(yīng)用向其服務(wù)器請求密鑰.因此攻擊者無法獲取目標(biāo)應(yīng)用用于私密推送信息處理的密鑰，無法進(jìn)行竊聽、篡改和偽造攻擊.為了減輕開發(fā)者的開發(fā)負(fù)擔(dān)，相關(guān)的功能可以由SecPush提供給應(yīng)用程序服務(wù)器端的SDK實(shí)現(xiàn).

3.1.2 推送數(shù)據(jù)格式設(shè)計(jì)

雖然公開信息推送和私密信息推送使用的密鑰不同，但是針對推送數(shù)據(jù)進(jìn)行的加密操作和HMAC運(yùn)算是一致的，因此可以采用相同的推送數(shù)據(jù)格式，以簡化客戶端的處理過程.推送服務(wù)器發(fā)送的數(shù)據(jù)可表示為

Msgsend={pkgname,msgId,enctype,contentc,

HMACkeymac(pkgname,msgId,enctype,contentc)},

contentc的格式如下：

其中，E代表加密運(yùn)算；keyE為數(shù)據(jù)加密密鑰；typeId表示消息類型，通過設(shè)置該值可以提供多種推送數(shù)據(jù)處理方式；title為通知類消息的標(biāo)題；body為推送消息的具體內(nèi)容.

3.1.3 SecPush方案架構(gòu)設(shè)計(jì)

SecPush方案的整體架構(gòu)如圖6所示:

Fig. 6 Framework of SecPush.圖6 SecPush方案架構(gòu)圖

SecPush包含客戶端SDK、應(yīng)用程序服務(wù)器端SDK和推送服務(wù)器三大部分.圖6中通道1～4表示雙方使用httphttps協(xié)議進(jìn)行通信，通道5表示推送數(shù)據(jù)通過socket連接進(jìn)行傳輸.

公開信息推送的運(yùn)行流程如下：

1) Application調(diào)用Client SDK的初始化函數(shù)，向Push Server發(fā)送應(yīng)用信息注冊請求；

2) Push Server生成與Application對應(yīng)的ClientId、公開信息加密密鑰keyE_p以及公開信息HMAC運(yùn)算密鑰keymac_p作為應(yīng)用信息注冊請求的響應(yīng)數(shù)據(jù)傳遞給Application；

3) Client SDK檢查當(dāng)前應(yīng)用是否是該設(shè)備上第1個(gè)使用SecPush SDK的應(yīng)用程序，若是，則建立當(dāng)前設(shè)備與Push Server之間的socket長連接，管理該連接的Service組件即為設(shè)備上的PDDS組件；

4) 應(yīng)用程序開發(fā)者通過Portal或Application Server，將推送數(shù)據(jù)提交給Push Server；

5) Push Server查詢安裝有目標(biāo)應(yīng)用的目標(biāo)設(shè)備，并獲取相應(yīng)的加密密鑰和HMAC運(yùn)算密鑰，構(gòu)造推送數(shù)據(jù)Msgsend，通過Push Server與目標(biāo)設(shè)備之間的socket連接將Msgsend發(fā)送給目標(biāo)設(shè)備上的PDDS組件；

6) PDDS組件從Msgsend中獲取目標(biāo)應(yīng)用包名，通過函數(shù)sendBroadcast將Msgsend發(fā)送給目標(biāo)應(yīng)用的Client SDK；

7) Client SDK通過enctype字段判斷處理當(dāng)前消息應(yīng)當(dāng)使用的加密密鑰和HMAC運(yùn)算密鑰，之后通過HMAC運(yùn)算判斷Msgsend的完整性，提取pkgname字段和msgId字段的值判斷其有效性，最后通過解密運(yùn)算獲取推送消息的明文，發(fā)送給相應(yīng)的消息接收器進(jìn)行后續(xù)處理.

私密信息推送的運(yùn)行流程如下：

1) 用戶登錄Application，Application向Appli-cation Server發(fā)起登錄請求，將用戶名、密碼、ClientId等信息傳遞給Application Server；

2) Application Server根據(jù)用戶名、密碼、ClientId等信息生成用戶在當(dāng)前登錄設(shè)備上處理私密推送數(shù)據(jù)的加密密鑰keyE_s和HMAC運(yùn)算密鑰keymac_s，作為登錄請求的響應(yīng)數(shù)據(jù)傳遞給Application；

3) Application Server需要推送私密信息時(shí)，調(diào)用Server SDK的接口，使用相應(yīng)用戶的加密密鑰和HMAC運(yùn)算密鑰構(gòu)建推送數(shù)據(jù)Msgsend，之后將目標(biāo)應(yīng)用的APP_ID，Msgsend，ClientId作為參數(shù)傳遞給Server SDK，由Server SDK向Push Server發(fā)起推送請求；

4) Push Server通過查詢目標(biāo)應(yīng)用APP_ID及ClientId尋找與目標(biāo)設(shè)備之間的socket連接，通過該連接將Msgsend發(fā)送給目標(biāo)設(shè)備上的PDDS；

5) PDDS從Msgsend中獲取目標(biāo)應(yīng)用包名，將Msgsend發(fā)送給目標(biāo)應(yīng)用的Client SDK；

6) 目標(biāo)應(yīng)用的Client SDK使用相應(yīng)密鑰進(jìn)行后續(xù)處理.

為了提高公開信息推送的安全性，對于需要用戶登錄的應(yīng)用程序，開發(fā)者也可以選擇在用戶登錄后使用私密信息處理密鑰對公開推送信息進(jìn)行安全保護(hù)，Server SDK提供相應(yīng)的接口供Application Server調(diào)用.

3.2 安全性分析

通過3.1節(jié)的設(shè)計(jì)，SecPush實(shí)現(xiàn)了推送數(shù)據(jù)分發(fā)環(huán)節(jié)的安全需求.

3.2.1 機(jī)密性

對于公開信息推送而言，推送數(shù)據(jù)的機(jī)密性并不是必要需求，因此這里的機(jī)密性主要指私密信息推送過程中推送數(shù)據(jù)的機(jī)密性要求.

對于私密信息推送而言，在SecPush的密鑰分配方案設(shè)計(jì)之下，攻擊程序無法獲取同一設(shè)備上目標(biāo)應(yīng)用處理私密推送數(shù)據(jù)的加密密鑰和HMAC運(yùn)算密鑰，因此無法解密推送數(shù)據(jù)中的密文數(shù)據(jù)以獲取明文信息.

分析表明：SecPush可以有效對抗攻擊程序?qū)嵤┑南⒏`聽攻擊.

3.2.2 完整性

對于公開信息而言，雖然攻擊程序可以偽裝成目標(biāo)應(yīng)用從SecPush推送服務(wù)器獲取加密密鑰和HMAC運(yùn)算密鑰，但是由于推送服務(wù)器對于同一應(yīng)用發(fā)送的不同注冊請求返回的是不同的密鑰，因此攻擊者仍然獲取不到目標(biāo)應(yīng)用正在使用的密鑰，即使攻擊程序使用獲取到的新密鑰解密并修改了推送服務(wù)器發(fā)送給目標(biāo)應(yīng)用的公開信息，其修改后的內(nèi)容也無法被目標(biāo)應(yīng)用正確解析，篡改攻擊無法成功實(shí)施.

對于私密信息推送而言，由于攻擊者無法獲取同一設(shè)備上目標(biāo)應(yīng)用處理私密推送數(shù)據(jù)的加密密鑰和HMAC運(yùn)算密鑰，因此無法解密并修改推送服務(wù)器發(fā)送給目標(biāo)應(yīng)用的推送數(shù)據(jù)，也無法生成合法的HMAC運(yùn)算結(jié)果.

分析表明：SecPush可以有效對抗攻擊程序?qū)嵤┑南⒋鄹墓?

3.2.3 不可偽造性

由于攻擊程序無法獲取目標(biāo)應(yīng)用正在使用的公開信息處理密鑰和私密信息處理密鑰，因此無法構(gòu)造有效的推送數(shù)據(jù)密文，也無法生成該密文對應(yīng)的合法HMAC運(yùn)算結(jié)果.

分析表明：SecPush可以有效對抗攻擊程序?qū)嵤┑南卧旃?

3.2.4 抗重放攻擊

由于Msgsend中包含msgId信息，目標(biāo)應(yīng)用在收到推送數(shù)據(jù)獲取msgId值后通過查詢數(shù)據(jù)庫可以判斷當(dāng)前的消息是否被重放.

3.3 局限性分析

SecPush在發(fā)送公開信息時(shí)需要針對每一個(gè)接收信息的設(shè)備分別進(jìn)行數(shù)據(jù)加密和HMAC運(yùn)算，對推送服務(wù)器而言將會造成一定的運(yùn)算負(fù)擔(dān)，然而作者在實(shí)驗(yàn)時(shí)發(fā)現(xiàn)友盟推送在進(jìn)行公開信息推送時(shí)，針對不同的設(shè)備也分別使用了不同的加密密鑰進(jìn)行數(shù)據(jù)加密操作，由此可知對公開推送數(shù)據(jù)進(jìn)行獨(dú)立的加密和HMAC運(yùn)算不會給推送服務(wù)器帶來過重的負(fù)擔(dān)，具備現(xiàn)實(shí)可行性.

3.4 原型系統(tǒng)實(shí)現(xiàn)

本文實(shí)現(xiàn)了一個(gè)基于MQTT協(xié)議的SecPush原型系統(tǒng)用于有效性測試及性能測試，其中客戶端SDK基于wmqtt.jar[4]實(shí)現(xiàn)，推送服務(wù)器基于開源消息代理軟件Mosquitto[5]以及SAM-PHP[6]實(shí)現(xiàn)，服務(wù)器端SDK使用Java開發(fā).推送數(shù)據(jù)的加密保護(hù)使用DES加密算法實(shí)現(xiàn)，數(shù)據(jù)完整性保護(hù)使用HMAC-SHA1算法實(shí)現(xiàn).具體實(shí)現(xiàn)細(xì)節(jié)不再贅述.

4 實(shí)驗(yàn)與分析

本節(jié)將詳細(xì)展示作者針對6個(gè)第三方Android推送服務(wù)進(jìn)行攻擊測試的實(shí)驗(yàn)結(jié)果以及SecPush的有效性測試和性能測試結(jié)果.

4.1 攻擊測試實(shí)驗(yàn)

本文選取了6個(gè)使用PDDS組件的第三方Android推送服務(wù)作為實(shí)驗(yàn)對象，使用2.3節(jié)介紹的攻擊模型，測試上述6個(gè)推送服務(wù)在數(shù)據(jù)分發(fā)環(huán)節(jié)的安全性.

4.1.1 實(shí)驗(yàn)對象選取

移動互聯(lián)網(wǎng)企業(yè)運(yùn)營解決方案整合平臺DevStore[7]中列出了30個(gè)推送服務(wù)，通過對安智(Anzhi)市場和豌豆莢(Wandoujia)市場上隨機(jī)選取的5 520個(gè)應(yīng)用樣本進(jìn)行測試，作者獲得了上述30個(gè)推送服務(wù)的市場占有率，排名前12位的推送服務(wù)如表1所示，分別為百度云推送(Baidu Push)、極光推送(JPush)、友盟推送(Umeng Push)、小米推送(MiPush)、個(gè)推推送(Getui Push)、騰訊信鴿推送(XG Push)、愛心推送(Ixintui Push)、華為推送(Huawei Push)、LeanCloud、魔推(mPush)、云巴消息推送(Yunba Push)和Cocos Push.測試樣本于2015-05-26—2015-05-31從上述2個(gè)應(yīng)用市場中爬取，其中3 526個(gè)樣本來自于安智市場，1 994個(gè)樣本來自于豌豆莢市場.

Table 1 Market Share of Push Services (Top 12)

在上述12個(gè)推送服務(wù)中，極光推送(JPush)、小米推送(MiPush)、個(gè)推推送(Getui Push)、Lean-Cloud和云巴消息推送(Yunba Push)采用每個(gè)應(yīng)用創(chuàng)建并維持各自的socket長連接的實(shí)現(xiàn)方式,其中個(gè)推推送在其網(wǎng)站上說明其實(shí)現(xiàn)方式為多個(gè)應(yīng)用共享1條長連接，然而經(jīng)作者測試發(fā)現(xiàn)，每個(gè)使用個(gè)推推送的應(yīng)用均各自在設(shè)備上維持1條連接到個(gè)推服務(wù)器的socket連接;其余7個(gè)推送服務(wù)均使用PDDS組件實(shí)現(xiàn)多個(gè)應(yīng)用共享長連接的功能.由于作者未能在華為開發(fā)平臺上注冊成功，因此無法針對華為推送(Huawei Push)進(jìn)行有效的測試，故本文選擇其余6個(gè)使用PDDS組件的推送服務(wù)作為實(shí)驗(yàn)對象，即百度云推送[8](Baidu Push)、友盟推送[9](Umeng Push)、騰訊信鴿推送[10](XG Push)、愛心推送[11](Ixintui Push)、魔推[12](mPush)和Cocos Push[13].實(shí)驗(yàn)中所用6個(gè)推送服務(wù)客戶端SDK版本如表2所示:

Table 2 Version Number of the Selected Push SDK

4.1.2 實(shí)驗(yàn)設(shè)計(jì)及結(jié)果分析

作者在上述6個(gè)推送服務(wù)開發(fā)平臺上進(jìn)行注冊，獲取推送SDK進(jìn)行攻擊程序及目標(biāo)應(yīng)用的開發(fā).攻擊程序使用2.3節(jié)介紹的攻擊模型實(shí)現(xiàn)針對目標(biāo)應(yīng)用的竊聽、篡改、偽造和重放攻擊.目標(biāo)應(yīng)用嚴(yán)格遵循各平臺的開發(fā)者文檔進(jìn)行開發(fā)，正確使用推送SDK實(shí)現(xiàn)相關(guān)功能.

選用自己開發(fā)的應(yīng)用程序作為目標(biāo)應(yīng)用，只是為了方便隨時(shí)發(fā)送推送數(shù)據(jù)進(jìn)行竊聽攻擊的測試，在攻擊程序針對目標(biāo)應(yīng)用的攻擊成功之后，作者同樣針對4.1.1節(jié)中獲取的相關(guān)SDK的宿主應(yīng)用樣本進(jìn)行了攻擊測試，進(jìn)一步驗(yàn)證了實(shí)驗(yàn)結(jié)果的正確性.

4類攻擊實(shí)驗(yàn)的結(jié)果分述如下：

1) 消息竊聽攻擊

通過Hook推送SDK對sendBroadcast，send-OrderedBroadcast，sendStickyBroadcast等函數(shù)的調(diào)用，攻擊程序可以在PDDS組件向目標(biāo)應(yīng)用分發(fā)推送數(shù)據(jù)的環(huán)節(jié)進(jìn)行監(jiān)聽，獲取傳輸?shù)耐扑蛿?shù)據(jù).

針對6個(gè)推送服務(wù)進(jìn)行竊聽攻擊的實(shí)驗(yàn)結(jié)果如表3所示:

Table 3 Results of Eavesdropping Attack

除了騰訊信鴿推送(XG Push)，其他推送SDK均使用函數(shù)sendBroadcast或sendOrderedBroadcast進(jìn)行數(shù)據(jù)傳輸，且多數(shù)SDK傳輸?shù)氖敲魑臄?shù)據(jù)，因此通過Hook該類函數(shù)可以直接獲取這些SDK分發(fā)的推送數(shù)據(jù).

騰訊信鴿推送(XG Push)通過調(diào)用函數(shù)bindService，將推送數(shù)據(jù)放置在Intent類型參數(shù)中進(jìn)行傳輸，并且傳輸?shù)氖羌用芎蟮拿芪男畔?但是作者通過對SDK反編譯代碼的分析，發(fā)現(xiàn)在推送Service組件分發(fā)數(shù)據(jù)給目標(biāo)應(yīng)用之前，會進(jìn)行SDK內(nèi)的數(shù)據(jù)廣播，在其中某個(gè)函數(shù)調(diào)用處可以獲取推送數(shù)據(jù)的明文，因此通過Hook該函數(shù)，攻擊程序可以在數(shù)據(jù)進(jìn)行分發(fā)之前獲取其明文信息.除了上述途徑，通過調(diào)用騰訊信鴿推送SDK中的解密函數(shù)，攻擊程序也可以獲取密文信息對應(yīng)的明文數(shù)據(jù)，解密函數(shù)不需要輸入密鑰參數(shù).

友盟推送(Umeng Push)將推送消息內(nèi)容的密文及其他參數(shù)的明文一起傳遞給目標(biāo)應(yīng)用，攻擊程序無法直接獲取推送消息內(nèi)容的明文，但是通過對明文參數(shù)的分析，作者發(fā)現(xiàn)目標(biāo)應(yīng)用進(jìn)行解密需使用的密鑰被附在消息Id字段中一起傳輸，因此通過使用該參數(shù)并反射調(diào)用SDK中的解密函數(shù)，攻擊程序同樣可以獲取推送數(shù)據(jù)的明文.

愛心推送(Ixintui Push)同樣是將加密后的消息傳遞給了目標(biāo)應(yīng)用，但是通過調(diào)用SDK中的解密函數(shù)，攻擊程序可以將這部分信息還原成明文，并且不需要輸入任何密鑰.

2) 消息篡改攻擊

攻擊程序在竊聽數(shù)據(jù)的環(huán)節(jié)可以對數(shù)據(jù)中的部分字段進(jìn)行修改，實(shí)現(xiàn)消息篡改的攻擊.

針對6個(gè)推送服務(wù)進(jìn)行篡改攻擊的實(shí)驗(yàn)結(jié)果如表4所示.6個(gè)推送SDK的目標(biāo)應(yīng)用在收到篡改的消息后，均可進(jìn)行正確處理，將篡改后的消息內(nèi)容展示給用戶，說明6個(gè)推送SDK在收到PDDS分發(fā)的消息后均未對消息的完整性進(jìn)行認(rèn)證.

Table 4 Results of Tampering Attack

實(shí)驗(yàn)中，由于友盟推送(Umeng Push)和愛心推送(Ixintui Push)從服務(wù)器端收到的信息均是密文，因此需要首先調(diào)用SDK中的函數(shù)對其解密，然后對篡改后的數(shù)據(jù)進(jìn)行加密.

3) 消息偽造攻擊

通過分析6個(gè)推送服務(wù)的消息格式，攻擊者可以偽造數(shù)據(jù)傳送給目標(biāo)應(yīng)用.偽造攻擊可以達(dá)到與篡改攻擊相似的攻擊效果.

針對6個(gè)推送服務(wù)進(jìn)行偽造攻擊的實(shí)驗(yàn)結(jié)果如表5所示：

Table 5 Results of Forgery Attack

實(shí)驗(yàn)中發(fā)現(xiàn)，百度云推送(Baidu Push)有單獨(dú)的推送數(shù)據(jù)格式類，通過使用Java反射技術(shù)創(chuàng)建該類的實(shí)例即可構(gòu)造正確格式的推送數(shù)據(jù).

此外，針對友盟推送(Umeng Push)和愛心推送(Ixintui Push)的偽造攻擊依然需要進(jìn)行相應(yīng)的加密操作.

4) 消息重放攻擊

攻擊程序可以將竊聽到的數(shù)據(jù)進(jìn)行存儲，之后再重放給目標(biāo)應(yīng)用.如果目標(biāo)應(yīng)用不對消息的新鮮性進(jìn)行檢測，將會對重放的消息進(jìn)行再次處理.

針對通知類推送進(jìn)行重放攻擊的實(shí)驗(yàn)結(jié)果如表6所示.6個(gè)推送服務(wù)的推送數(shù)據(jù)中均包含msgId字段或類似字段，用來唯一標(biāo)識當(dāng)前消息，但是針對其中4個(gè)推送SDK的重放攻擊依舊可以實(shí)施，目標(biāo)應(yīng)用依舊可以對重復(fù)的消息進(jìn)行正常的處理，彈出通知，并在用戶點(diǎn)擊之后進(jìn)行相應(yīng)的操作.實(shí)驗(yàn)結(jié)果顯示，在宿主應(yīng)用收到經(jīng)過PDDS處理的消息之后，推送SDK不再對消息的新鮮性進(jìn)行檢驗(yàn)，而是信任PDDS已經(jīng)對此進(jìn)行了驗(yàn)證，因此對于收到的消息依舊進(jìn)行了正常的處理.

Table 6 Results of Replay Attack

上述實(shí)驗(yàn)結(jié)果表明，多數(shù)使用PDDS組件的第三方Android推送服務(wù)無法對抗竊聽、篡改、偽造和重放攻擊，沒有實(shí)現(xiàn)其聲稱的典型應(yīng)用場景所需要的安全需求，威脅用戶的使用安全.

Fig. 7 Eavesdropping attack against SecPush.圖7 針對SecPush的竊聽攻擊

4.2 SecPush的有效性測試

本文開發(fā)了2個(gè)使用SecPush SDK的應(yīng)用程序：1)目標(biāo)應(yīng)用，其包名為com.lulupush.pushlibtest；2)攻擊程序，其包名為com.example.mypushlibtest.

首先在設(shè)備上安裝攻擊程序，待攻擊程序正確啟動后，安裝目標(biāo)應(yīng)用并啟動.通過SecPush服務(wù)器向目標(biāo)應(yīng)用發(fā)送推送數(shù)據(jù)，目標(biāo)應(yīng)用在logcat中顯示收到的數(shù)據(jù)如圖7(a)所示，攻擊程序的Hook Service竊聽到的數(shù)據(jù)如圖7(b)所示.

由于攻擊程序無法獲取目標(biāo)應(yīng)用正在使用的加密密鑰和HMAC運(yùn)算密鑰，因此攻擊者無法解密收到的密文信息.同樣，由于沒有相應(yīng)密鑰，攻擊程序無法對收到的信息進(jìn)行篡改或偽造有效的推送數(shù)據(jù)發(fā)送給目標(biāo)應(yīng)用.無論攻擊程序如何篡改和偽造消息，目標(biāo)應(yīng)用都無法正確解析，并在logcat中打印出“HMAC failed!”信息.

攻擊者程序?qū)D7(b)中收到的數(shù)據(jù)重放給目標(biāo)應(yīng)用，目標(biāo)應(yīng)用沒有展示相應(yīng)的通知，且在logcat中打印出“Old Message!”信息.

實(shí)驗(yàn)結(jié)果表明，SecPush實(shí)現(xiàn)了推送數(shù)據(jù)分發(fā)環(huán)節(jié)的數(shù)據(jù)機(jī)密性、完整性、不可偽造性和抗重放攻擊的安全需求，能有效抵擋來自該環(huán)節(jié)的攻擊者.

4.3 SecPush方案的性能測試

移動智能終端由于能源資源有限，對應(yīng)用程序的性能要求較高.本文通過連續(xù)發(fā)送1 000組推送數(shù)據(jù)的方式，測試SecPush處理數(shù)據(jù)時(shí)的能源和資源消耗，針對使用加密方案和不使用加密方案2種模式分別進(jìn)行測試，分析數(shù)據(jù)加密及HMAC運(yùn)算環(huán)節(jié)帶來的額外資源和能源消耗.

實(shí)驗(yàn)中針對CPU占用率和內(nèi)存使用情況的監(jiān)測通過top指令進(jìn)行采樣，采樣周期為1 s，取峰值作為展示數(shù)據(jù).針對耗電量的測試，借鑒Android系統(tǒng)耗電量統(tǒng)計(jì)相關(guān)代碼開發(fā)測試軟件，獲取目標(biāo)應(yīng)用處理推送數(shù)據(jù)期間對電量的消耗情況.

實(shí)驗(yàn)所用測試設(shè)備為三星Galaxy SIII手機(jī)，配備1.4 GHz 4核處理器、1 GB內(nèi)存空間，電池容量為2 100 mAh.

實(shí)驗(yàn)所用推送數(shù)據(jù)在未采用加密及HMAC運(yùn)算時(shí)構(gòu)造的Msgsend長度為734 B，采用加密及HMAC運(yùn)算后Msgsend的長度為1 019 B.應(yīng)用程序通常不會在1條推送消息中放置大量數(shù)據(jù)，實(shí)驗(yàn)中選用的數(shù)據(jù)長度可以很好地反映推送數(shù)據(jù)在實(shí)際生活中的使用情況.

測試結(jié)果如表7所示.其中第1行數(shù)據(jù)是針對使用加密及HMAC運(yùn)算enhanced mode的應(yīng)用程序的測試結(jié)果；第2行數(shù)據(jù)是針對不使用安全保護(hù)機(jī)制normal mode的應(yīng)用程序的測試結(jié)果；第3行數(shù)據(jù)為兩者的差值，即加密及HMAC運(yùn)算環(huán)節(jié)產(chǎn)生的資源和能源消耗.

CPU占用率的數(shù)值較大，是因?yàn)閷?shí)驗(yàn)中的1 000組推送數(shù)據(jù)是連續(xù)發(fā)送的，在42 s內(nèi)處理完成，因此對CPU的使用相對集中，實(shí)際使用中很少出現(xiàn)連續(xù)發(fā)送多組推送數(shù)據(jù)的情況，因此不會出現(xiàn)如此高的CPU占用率.本文額外測試了每隔3 s發(fā)送1組推送數(shù)據(jù)時(shí)CPU的占用率情況，測試結(jié)果顯示CPU占用率的峰值為1%.

Table 7 Performance Test of SecPush

SecPush對1000組推送數(shù)據(jù)的安全處理僅帶來2 774 KB的額外內(nèi)存消耗，相對于測試設(shè)備1 GB的內(nèi)存空間來說可以忽略不計(jì).

此外，SecPush對1 000組推送數(shù)據(jù)的安全處理所帶來的額外電量消耗為0.89mAh，僅占測試設(shè)備電池容量的0.04%，可以忽略不計(jì).

由于實(shí)際使用中很少有應(yīng)用程序在1 d之內(nèi)收到1 000條推送數(shù)據(jù)，因此根據(jù)本文的實(shí)驗(yàn)結(jié)果可以看出，SecPush中增添的安全措施不會給設(shè)備帶來沉重的資源和能源負(fù)擔(dān).

實(shí)驗(yàn)結(jié)果顯示，SecPush方案提高了推送服務(wù)數(shù)據(jù)分發(fā)環(huán)節(jié)的安全性，且其帶來的資源和能源消耗微乎其微，是增強(qiáng)推送服務(wù)安全性的有效方案.

5 相關(guān)工作

近年來Android系統(tǒng)獲得了飛速發(fā)展，與之相關(guān)的安全研究也得到了廣泛關(guān)注.文獻(xiàn)[14]對Android安全相關(guān)的研究進(jìn)行了詳細(xì)的討論，從系統(tǒng)安全和應(yīng)用安全2個(gè)方面分析了現(xiàn)有的安全問題，介紹了相關(guān)研究成果.然而應(yīng)用中廣泛使用的第三方庫的安全問題卻不能簡單歸入這兩類問題中.第三方庫類似于Android系統(tǒng)與應(yīng)用程序之間的中間件，同一個(gè)第三方庫可能存在于多個(gè)應(yīng)用之中，一旦第三方庫出現(xiàn)安全問題，所帶來的影響將遠(yuǎn)遠(yuǎn)大于單個(gè)惡意應(yīng)用帶來的影響.2013年Android OpenSSL庫漏洞[15]的出現(xiàn)也使得人們越來越重視應(yīng)用程序中廣泛使用的系統(tǒng)庫和第三方庫的安全問題.

近幾年，研究人員對Android應(yīng)用中廣泛使用的廣告庫進(jìn)行了深入的研究.Grace等人[16]提出了AdRisk方案檢測廣告庫中用戶隱私信息收集及非可信代碼執(zhí)行行為.Stevens等人[17]對廣告庫中存在的收集用戶信息、濫用宿主應(yīng)用權(quán)限、追蹤用戶等行為進(jìn)行了研究，分析其對用戶造成的安全威脅.Book等人[18]的研究指出，廣告平臺還可以通過許以高額廣告收益誘使移動終端應(yīng)用程序開發(fā)者主動提供用戶的隱私數(shù)據(jù)，造成用戶隱私信息的泄露.此外，廣告庫還可能面臨來自惡意開發(fā)者的攻擊.Crussell等人[19]的研究指出，應(yīng)用程序開發(fā)者可能通過對廣告的虛假訪問獲取非法廣告收益，造成廣告主的經(jīng)濟(jì)損失.針對廣告庫使用模式中帶來的安全問題，研究人員還設(shè)計(jì)了相應(yīng)的安全防護(hù)方案，將廣告庫與宿主應(yīng)用隔離，并限制廣告庫的權(quán)限和能力，以保護(hù)應(yīng)用程序用戶的使用安全，同時(shí)維護(hù)廣告主的合法利益，相關(guān)方案包括AdSplit[20]，AdDroid[21]，AFrame[22]等.

推送服務(wù)與廣告庫同為Android應(yīng)用中廣泛使用的第三方庫，然而由于功能邏輯不同，二者中存在的安全問題也有一定的差異.Li等人[2]詳細(xì)分析了推送服務(wù)中應(yīng)用程序注冊過程和上傳信息過程中存在的安全問題，這些問題可能導(dǎo)致目標(biāo)應(yīng)用的用戶隱私數(shù)據(jù)被泄露或者導(dǎo)致目標(biāo)應(yīng)用執(zhí)行攻擊者的命令.與之不同，本文的工作針對的是推送服務(wù)客戶端SDK在設(shè)備上的數(shù)據(jù)分發(fā)環(huán)節(jié)中存在的安全問題.由于使用PDDS組件進(jìn)行設(shè)備上推送數(shù)據(jù)的轉(zhuǎn)發(fā)，推送服務(wù)在數(shù)據(jù)分發(fā)環(huán)節(jié)可能面臨來自惡意宿主程序的竊聽、篡改、偽造和重放攻擊.針對PDDS組件的使用模式，本文設(shè)計(jì)了相應(yīng)的攻擊模型，對市場上6個(gè)推送服務(wù)進(jìn)行了攻擊測試，測試結(jié)果顯示，大部分第三方Android推送服務(wù)在推送數(shù)據(jù)分發(fā)環(huán)節(jié)沒有實(shí)現(xiàn)針對推送數(shù)據(jù)的安全保護(hù).騰訊信鴿推送和友盟推送等推送服務(wù)也僅通過使用SSL協(xié)議或加密算法提供推送數(shù)據(jù)在網(wǎng)絡(luò)上傳輸?shù)陌踩?，對于推送服?wù)內(nèi)部邏輯實(shí)現(xiàn)的安全性沒有過多關(guān)注.

針對發(fā)現(xiàn)的安全問題，本文提出了相應(yīng)的安全加固方案SecPush，方案中使用加密算法保護(hù)推送數(shù)據(jù)的機(jī)密性，使用HMAC運(yùn)算保護(hù)推送數(shù)據(jù)的完整性.與本文的工作相似，Li等人[2]也在其文章中提出了針對推送數(shù)據(jù)的端到端保護(hù)方案Secomp，其中針對私密數(shù)據(jù)的推送同樣采用認(rèn)證加密算法提供機(jī)密性和完整性保護(hù)，而針對公開信息的推送只采用公鑰簽名進(jìn)行完整性保護(hù)，即不同設(shè)備上的同一應(yīng)用使用同樣的公鑰進(jìn)行推送數(shù)據(jù)的簽名驗(yàn)證.Secomp使用公鑰簽名雖然僅需要進(jìn)行1次簽名就可以將1條信息發(fā)送給當(dāng)前應(yīng)用的所有用戶，然而移動終端設(shè)備在進(jìn)行簽名驗(yàn)證時(shí)將存在較重的運(yùn)算負(fù)擔(dān).此外，一旦攻擊者通過某種方式獲取了目標(biāo)應(yīng)用使用的私鑰，那么該應(yīng)用所有的用戶都將失去公開信息推送的完整性保護(hù).與之相比，本文使用HMAC運(yùn)算對公開信息推送進(jìn)行完整性保護(hù)，與公鑰簽名相比減輕了移動終端設(shè)備的運(yùn)算負(fù)擔(dān)；另一方面，即使某個(gè)移動終端設(shè)備上該應(yīng)用使用的HMAC運(yùn)算密鑰被泄露，其他移動終端設(shè)備也不會面臨推送的公開信息被篡改的危險(xiǎn)，并且HMAC密鑰被泄露的設(shè)備也可以通過再次獲取新的密鑰保證后續(xù)推送數(shù)據(jù)的安全性.不同設(shè)備使用不同的密鑰，雖然導(dǎo)致推送服務(wù)在發(fā)送公開信息時(shí)需要對每臺設(shè)備分別進(jìn)行HMAC運(yùn)算，但是鑒于友盟推送在發(fā)送公開信息時(shí)亦是使用不同的密鑰對不同的設(shè)備需要接收的信息進(jìn)行加密，因此可知對公開推送數(shù)據(jù)進(jìn)行獨(dú)立的加密和HMAC運(yùn)算不會給推送服務(wù)器帶來過重的負(fù)擔(dān)，具備可行性.

除了上述方案，文獻(xiàn)[23]設(shè)計(jì)了一種使用對稱密碼算法及數(shù)字簽名算法的消息推送服務(wù)方案，提供推送數(shù)據(jù)的加密性、完整性和不可否認(rèn)性保護(hù).方案使用對稱加密算法加密推送數(shù)據(jù)，使用基于身份的數(shù)字簽名算法對推送數(shù)據(jù)密文和其他參數(shù)進(jìn)行簽名.上述方案雖然實(shí)現(xiàn)了其安全性目標(biāo)，然而為了使用簽名算法，方案中需要額外引入第三方密鑰生成中心PKG，且簽名信息的驗(yàn)證也會給移動設(shè)備帶來較重的運(yùn)算負(fù)擔(dān).與該方案相比，本文的方案不需要引入第三方密鑰生成中心，也不會給移動終端設(shè)備帶來過重的運(yùn)算負(fù)擔(dān)，更適合移動終端設(shè)備使用.

6 結(jié)束語

本文分析了第三方Android推送服務(wù)在數(shù)據(jù)分發(fā)環(huán)節(jié)存在的安全問題，設(shè)計(jì)了相應(yīng)的攻擊場景，成功實(shí)現(xiàn)了針對推送數(shù)據(jù)的竊聽、篡改、偽造和重放攻擊，并具體展示了利用這些技術(shù)實(shí)施的用戶私聊信息竊取及釣魚攻擊等攻擊場景.實(shí)驗(yàn)結(jié)果表明，百度云推送、友盟推送、騰訊信鴿推送等第三方Android推送服務(wù)在數(shù)據(jù)分發(fā)環(huán)節(jié)存在嚴(yán)重的安全問題，沒有實(shí)現(xiàn)其宣稱的典型應(yīng)用場景的安全需求，當(dāng)開發(fā)者將推送服務(wù)用于這些場景時(shí)，有可能給用戶帶來實(shí)際的安全危害.為了提高推送數(shù)據(jù)分發(fā)環(huán)節(jié)的安全性，本文設(shè)計(jì)并實(shí)現(xiàn)了Android應(yīng)用推送服務(wù)安全增強(qiáng)方案SecPush，實(shí)現(xiàn)推送數(shù)據(jù)機(jī)密性、完整性、不可偽造性和抗重放攻擊的安全需求，為用戶提供更安全更方便的推送服務(wù).

[1]Urban Airship. The good push index [EB/OL]. 2013[2015-04-30]. http://urbanairship.com/resources/whitepapers/good-push-index

[2]Li T, Zhou X, Xing L, et al. Mayhem in the push clouds: Understanding and mitigating security hazards in mobile push-messaging services[C] //Proc of the 21st ACM SIGSAC Conf on Computer and Communications Security. New York: ACM, 2014: 978-989

[3]cmzy. ZHookLib [CP/OL]. (2014-11-12) [2015-04-20]. https://github.com/cmzy/ZHookLib

[4]IBM. IA92: WBI Brokers—Java Implementation of WebSphere MQ Telemetry Transport [CP/OL]. (2009-06-12)[2015-05-01]. http://www-01.ibm.com/support/docview.wss?uid=swg24006006

[5]WordPress. Mosquitto [CP/OL]. (2015-03-07) [2015-05-20]. http://mosquitto.org/download

[6]The PHP Group. SAM[EB/OL]. [2015-04-30]. http://php.net/manual/en/intro.sam.php

[7]DevStore. DevStore[EB/OL]. [2015-04-28]. http://www.devstore.cn (in Chinese)

(深圳尺子科技有限公司. 移動互聯(lián)網(wǎng)企業(yè)運(yùn)營解決方案整合平臺[EB/OL]. [2015-04-28]. http://www.devstore.cn)[8]Baidu. Baidu Push [EB/OL]. [2015-04-30]. http://push.baidu.com (in Chinese)

(百度. 百度云推送 [EB/OL]. [2015-04-20]. http://push.baidu.com)

[9]Umeng. Message push [EB/OL]. [2015-04-20]. http://www.umeng.com/push (in Chinese)

(友盟. 友盟消息推送 [EB/OL]. [2015-04-20]. http://www.umeng.com/push)

[10]Tencent. Xinge [EB/OL]. [2015-04-30]. http://xg.qq.com (in Chinese)

(騰訊. 信鴿 [EB/OL]. [2015-04-30]. http://xg.qq.com)

[11]Ixintui. Ixintui [EB/OL]. [2015-04-20]. http://www.ixintui.com (in Chinese)

(北京麒麟心通網(wǎng)絡(luò)技術(shù)有限公司. 愛心推 [EB/OL]. [2015-04-20]. http://www.ixintui.com)

[12]mRocker. mPush [EB/OL]. [2015-04-20]. http://www.mpush.cn/index.html (in Chinese)

(移石創(chuàng)想(北京)科技有限公司.魔推 [EB/OL]. [2015-04-20]. http://www.mpush.cn/index.html)

[13]Chukong Technologies. Cocos Push [EB/OL]. [2015-04-20]. http://www.cocospush.com (in Chinese)

(觸控科技. Cocos開發(fā)者平臺 [EB/OL]. [2015-04-20]. http://www.cocospush.com)

[14]Zhang Yuqing, Wang Kai, Yang Huan, et al. Survey of Android OS security [J]. Journal of Computer Research and Development, 2014, 51(7): 1385-1396 (in Chinese)

(張玉清, 王凱, 楊歡, 等. Android安全綜述[J]. 計(jì)算機(jī)研究與發(fā)展, 2014, 51(7): 1385-1396)

[15]Kim S H, Han D, Lee D H. Predictability of Android OpenSSL’s pseudo random number generator [C] //Proc of the 20th ACM SIGSAC Conf on Computer & Communications Security. New York: ACM, 2013: 659-668

[16]Grace M C, Zhou W, Jiang X, et al. Unsafe exposure analysis of mobile in-app advertisements[C] //Proc of the 5th ACM Conf on Security and Privacy in Wireless and Mobile Networks. New York: ACM, 2012: 101-112

[17]Stevens R, Gibler C, Crussell J, et al. Investigating user privacy in Android ad libraries[C] //Proc of the 1st IEEE Workshop on Mobile Security Technologies (MoST). Piscataway, NJ: IEEE, 2012

[18]Book T, Wallach D S. A case of collusion: A study of the interface between ad libraries and their apps[C] //Proc of the 3rd ACM Workshop on Security and Privacy in Smartphones & Mobile Devices. New York: ACM, 2013: 79-86

[19]Crussell J, Stevens R, Chen H. MAdFraud: Investigating ad fraud in Android applications[C] //Proc of the 12th Annual Int Conf on Mobile Systems, Applications, and Services. New York: ACM, 2014: 123-134

[20]Shekhar S, Dietz M, Wallach D S. AdSplit: Separating smartphone advertising from applications[C] //Proc of the 21st USENIX Security Symp. Berkeley, CA: USENIX Association, 2012: 553-567

[21]Pearce P, Felt A P, Nunez G, et al. AdDroid: Privilege separation for applications and advertisers in Android[C] //Proc of the 7th ACM Symp on Information, Computer and Communications Security. New York: ACM, 2012: 71-72

[22]Zhang X, Ahlawat A, Du W. AFrame: Isolating advertisements from mobile applications in Android[C] //Proc of the 29th Annual Computer Security Applications Conf. New York: ACM, 2013: 9-18

[23]Yuan Jing. Research on the identity-based digital signature for mobile communication technology[D]. Wuhan: Huazhong University of Science and Technology, 2012 (in Chinese)

(袁靜. 基于身份數(shù)字簽名的移動通信技術(shù)研究[D]. 武漢: 華中科技大學(xué), 2012)

Lu Yemian, born in 1989. PhD candidate. Her main research interests include Android application security and malicious code analysis.

Li Yifu, born in 1981. PhD. Intermediate engineer. His main research interests include network and information security.

Ying Lingyun, born in 1982. PhD. Senior engineer. His main research interests include malware analysis and mobile security.

Gu Yacong, born in 1989. PhD candidate. His main research interests include Android system security and malicious code analysis.

Su Purui, born in 1976. PhD. Professor. His main research interests include malware analysis and prevention.

Feng Dengguo, born in 1965. Professor and PhD supervisor. His main research interests include cryptography and information security.

Security Analysis and Enhancement of Third-Party Android Push Service

Lu Yemian1, Li Yifu2, Ying Lingyun1,3, Gu Yacong1, Su Purui1,3, and Feng Dengguo1

1(TrustedComputingandInformationAssuranceLaboratory,InstituteofSoftware,ChineseAcademyofSciences,Beijing100190)2(NationalComputerEmergencyResponseTeamandCoordinationCenterofChina,Beijing100029)3(SchoolofComputerandControlEngineering,UniversityofChineseAcademyofSciences,Beijing101408)

Push service is becoming a basic service for smartphone applications. Many companies, including official and third parties, have released their push services. In order to reduce resource cost, some third-party push services share push channels among applications running on the same device and using the same push service, which means that the background push component of one application acts as the push data distribution center for other applications. Due to the lack of considering security attributes such as confidentiality and integrity, the distribution part faces a variety of attacks. In this work we analyze the security issues in the data distribution part of third-party push services on Android. We design a corresponding attack model and implement attacks including eavesdropping, data tampering, forgery and replay attacks. During our experiments, it shows that most of the third-party Android push services using shared channels are subject to these attacks. It may cause some security hazards such as user privacy leakage and phishing attack. To mitigate the above threats, we propose SecPush which is a security enhancement scheme for Android push service. SecPush secures data distribution by introducing encryption and HMAC algorithm. Experimental results show that SecPush can effectively protect push data against eavesdropping, data tampering, forgery and replay attacks.

Android; push service; data distribution; shared channel; security analysis; security enhancement

2015-06-15；

2015-08-31

國家“九七三”重點(diǎn)基礎(chǔ)研究發(fā)展計(jì)劃基金項(xiàng)目(2012CB315804); 國家自然科學(xué)基金項(xiàng)目(61502468); 北京市自然科學(xué)基金項(xiàng)目(4154089)

應(yīng)淩云(lingyun@iscas.ac.cn)

TP309

This work was supported by the National Basic Research Program of China (973 Program) (2012CB315804), the National Natural Science Foundation of China (61502468), and the Beijing Muncipal Natural Science Foundation (4154089).