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

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

1(中國(guó)科學(xué)院軟件研究所可信計(jì)算與信息保障實(shí)驗(yàn)室 北京 100190)2(國(guó)家計(jì)算機(jī)網(wǎng)絡(luò)應(yīng)急技術(shù)處理協(xié)調(diào)中心 北京 100029)3(中國(guó)科學(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馮登國(guó)1

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

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

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

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

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

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

1) 推送服務(wù)使用移動(dòng)終端操作系統(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)用，例如蘋(pí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ù)開(kāi)發(fā)的第三方推送服務(wù)也屬于這種方式.這種實(shí)現(xiàn)方式一方面在目標(biāo)設(shè)備上只維持了1條長(zhǎng)連接，供推送數(shù)據(jù)轉(zhuǎn)發(fā)中心與推送服務(wù)器進(jìn)行數(shù)據(jù)交互，降低了資源消耗；另一方面，作為轉(zhuǎn)發(fā)中心的系統(tǒng)模塊或者官方應(yīng)用很難被外來(lái)攻擊者攻破，在一定程度上保證了數(shù)據(jù)轉(zhuǎn)發(fā)環(huán)節(jié)的安全性.

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

3) 同一臺(tái)設(shè)備上使用同一推送服務(wù)的多個(gè)應(yīng)用之間共享1條長(zhǎng)連接，將其中某個(gè)應(yīng)用的推送Service組件作為推送數(shù)據(jù)的轉(zhuǎn)發(fā)中心，本文使用PDDS(push data distribution service)代指該組件.應(yīng)用程序開(kāi)發(fā)者的推送數(shù)據(jù)將首先由推送服務(wù)器發(fā)送給目標(biāo)設(shè)備上的PDDS組件，由PDDS組件進(jìn)行簡(jiǎn)單處理后將數(shù)據(jù)轉(zhuǎn)發(fā)給目標(biāo)應(yīng)用.百度云推送、友盟推送、騰訊信鴿推送等第三方Android推送服務(wù)使用該方式實(shí)現(xiàn).這種方式可以避免同一設(shè)備上存在多條與推送服務(wù)器之間的socket長(zhǎng)連接，節(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ù)沒(méi)有提供數(shù)據(jù)加密等安全保護(hù)措施時(shí)，PDDS組件的宿主應(yīng)用可以通過(guò)控制PDDS組件獲取推送給其他應(yīng)用的信息，甚至于偽造消息發(fā)送給目標(biāo)應(yīng)用，這將給用戶帶來(lái)極大的安全隱患.

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

3) 提出了Android推送服務(wù)安全增強(qiáng)方案SecPush，通過(guò)添加加密模塊和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)，并對(duì)其進(jìn)行安全測(cè)試，實(shí)驗(yàn)結(jié)果表明，SecPush能有效抵擋竊聽(tīng)、篡改、偽造和重放攻擊.

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

本文的研究對(duì)象是使用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ù)提供商開(kāi)發(fā)維護(hù)，方便應(yīng)用程序開(kāi)發(fā)者在不開(kāi)發(fā)服務(wù)端代碼的情況下發(fā)送推送信息；Application Server是開(kāi)發(fā)者為其應(yīng)用開(kāi)發(fā)的服務(wù)器端，使用推送服務(wù)的服務(wù)器端SDK實(shí)現(xiàn)推送相關(guān)功能，開(kāi)發(fā)者可以通過(guò)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í)從推送平臺(tái)獲取的APP_ID等信息傳遞給Push Server，完成應(yīng)用信息的注冊(cè)，獲取ClientId作為當(dāng)前設(shè)備上當(dāng)前應(yīng)用在Push Server上的用戶標(biāo)識(shí)，供應(yīng)用程序開(kāi)發(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長(zhǎng)連接，用以接收推送數(shù)據(jù)，并定時(shí)發(fā)送心跳包以維持該連接，管理該連接的Service組件即為設(shè)備上的PDDS組件；

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

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

5) PDDS組件對(duì)收到的數(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)透?jìng)餍畔?通知類推送將在設(shè)備通知欄展現(xiàn)1條通知，用戶點(diǎn)擊該通知后，根據(jù)具體類型的不同，Android系統(tǒng)或者打開(kāi)目標(biāo)應(yīng)用的某個(gè)界面，或者通過(guò)系統(tǒng)瀏覽器或目標(biāo)應(yīng)用使用的WebView控件打開(kāi)某個(gè)網(wǎng)頁(yè)，通知類推送的處理一般由推送服務(wù)SDK自己實(shí)現(xiàn)；而透?jìng)餍畔t是由應(yīng)用程序開(kāi)發(fā)者設(shè)計(jì)其獨(dú)有的數(shù)據(jù)格式及相應(yīng)的處理方式，推送服務(wù)只負(fù)責(zé)將推送數(shù)據(jù)傳遞給目標(biāo)應(yīng)用，不負(fù)責(zé)后續(xù)的處理過(guò)程.

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

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

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

2.1 安全目標(biāo)

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

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

2.2 敵手能力分析

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

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

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

本文設(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)限的情況下，攻擊程序無(wú)法干涉目標(biāo)應(yīng)用的運(yùn)行，也無(wú)法獲取目標(biāo)應(yīng)用通過(guò)其他途徑進(jìn)行網(wǎng)絡(luò)通信的數(shù)據(jù).

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

1) 消息竊聽(tīng)

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

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

Fig. 2 Private chat information of Pogo user obtained by eavesdropping.圖2 通過(guò)竊聽(tīng)獲取的Pogo用戶的私聊信息

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

2) 消息篡改

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

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

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

3) 消息偽造

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

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

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

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

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

4) 消息重放

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

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

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

實(shí)現(xiàn)對(duì)PDDS組件的控制之后，通過(guò)Hook PDDS組件向目標(biāo)應(yīng)用分發(fā)數(shù)據(jù)的函數(shù)，攻擊程序可以實(shí)現(xiàn)針對(duì)推送數(shù)據(jù)的竊聽(tīng)和篡改攻擊.另一方面，由于目標(biāo)應(yīng)用接收推送數(shù)據(jù)的組件多數(shù)是BroadcastReceiver組件，且出于實(shí)現(xiàn)功能的需要無(wú)法通過(guò)設(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通過(guò)對(duì)sendBroadcast等函數(shù)進(jìn)行Hook，獲取放置在Intent類型參數(shù)中的推送數(shù)據(jù)，實(shí)施竊聽(tīng)和篡改攻擊；Forge_Replay模塊使用竊聽(tīng)攻擊獲取的數(shù)據(jù)實(shí)施偽造和重放攻擊.

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

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

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

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

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

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

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

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

通過(guò)使用上述攻擊模型，作者對(duì)市場(chǎng)上6款第三方Android推送服務(wù)進(jìn)行了攻擊測(cè)試，實(shí)驗(yàn)結(jié)果表明，多數(shù)使用PDDS組件的第三方Android推送服務(wù)無(wú)法抵抗竊聽(tīng)、篡改、偽造和重放攻擊，沒(méi)有實(shí)現(xiàn)其聲稱的典型應(yīng)用場(chǎng)景所需要的安全需求，威脅用戶的使用安全，其中包括開(kāi)發(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ú)攻擊等安全威脅之下.為了保證應(yīng)用程序最終用戶的使用安全，使用現(xiàn)有推送服務(wù)的應(yīng)用程序開(kāi)發(fā)者只能自己實(shí)現(xiàn)推送數(shù)據(jù)的加密保護(hù)及完整性驗(yàn)證等安全需求，這將給開(kāi)發(fā)者帶來(lái)額外的開(kāi)發(fā)負(fù)擔(dān)，而且由于推送服務(wù)本身不支持上述安全需求，應(yīng)用程序開(kāi)發(fā)者只能在推送服務(wù)提供的多樣化推送方式和安全之間做出折中選擇.因此完全依賴應(yīng)用程序開(kāi)發(fā)者自己實(shí)現(xiàn)相關(guān)的安全需求是不合理的.另一方面，推送服務(wù)宣稱的典型應(yīng)用場(chǎ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)用程序的最終用戶免受隱私泄露和釣魚(yú)等攻擊的威脅.

本節(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采用對(duì)稱加密及HMAC運(yùn)算提供數(shù)據(jù)機(jī)密性、完整性和不可偽造性保護(hù)，通過(guò)數(shù)據(jù)庫(kù)保存和查詢推送消息Id的方式提供消息重放檢測(cè)功能.具體設(shè)計(jì)描述如下:

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

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

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

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

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

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

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

Msgsend={pkgname,msgId,enctype,contentc,

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

contentc的格式如下：

其中，E代表加密運(yùn)算；keyE為數(shù)據(jù)加密密鑰；typeId表示消息類型，通過(guò)設(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ù)通過(guò)socket連接進(jìn)行傳輸.

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

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

2) Push Server生成與Application對(duì)應(yīng)的ClientId、公開(kāi)信息加密密鑰keyE_p以及公開(kāi)信息HMAC運(yùn)算密鑰keymac_p作為應(yīng)用信息注冊(cè)請(qǐ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長(zhǎng)連接，管理該連接的Service組件即為設(shè)備上的PDDS組件；

4) 應(yīng)用程序開(kāi)發(fā)者通過(guò)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，通過(guò)Push Server與目標(biāo)設(shè)備之間的socket連接將Msgsend發(fā)送給目標(biāo)設(shè)備上的PDDS組件；

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

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

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

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

2) Application Server根據(jù)用戶名、密碼、ClientId等信息生成用戶在當(dāng)前登錄設(shè)備上處理私密推送數(shù)據(jù)的加密密鑰keyE_s和HMAC運(yùn)算密鑰keymac_s，作為登錄請(qǐng)求的響應(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ā)起推送請(qǐng)求；

4) Push Server通過(guò)查詢目標(biāo)應(yīng)用APP_ID及ClientId尋找與目標(biāo)設(shè)備之間的socket連接，通過(guò)該連接將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ù)處理.

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

3.2 安全性分析

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

3.2.1 機(jī)密性

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

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

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

3.2.2 完整性

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

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

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

3.2.3 不可偽造性

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

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

3.2.4 抗重放攻擊

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

3.3 局限性分析

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

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

本文實(shí)現(xiàn)了一個(gè)基于MQTT協(xié)議的SecPush原型系統(tǒng)用于有效性測(cè)試及性能測(cè)試，其中客戶端SDK基于wmqtt.jar[4]實(shí)現(xiàn)，推送服務(wù)器基于開(kāi)源消息代理軟件Mosquitto[5]以及SAM-PHP[6]實(shí)現(xiàn)，服務(wù)器端SDK使用Java開(kāi)發(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ì)展示作者針對(duì)6個(gè)第三方Android推送服務(wù)進(jìn)行攻擊測(cè)試的實(shí)驗(yàn)結(jié)果以及SecPush的有效性測(cè)試和性能測(cè)試結(jié)果.

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

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

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

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

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長(zhǎng)連接的實(shí)現(xiàn)方式,其中個(gè)推推送在其網(wǎng)站上說(shuō)明其實(shí)現(xiàn)方式為多個(gè)應(yīng)用共享1條長(zhǎng)連接，然而經(jīng)作者測(cè)試發(fā)現(xiàn)，每個(gè)使用個(gè)推推送的應(yīng)用均各自在設(shè)備上維持1條連接到個(gè)推服務(wù)器的socket連接;其余7個(gè)推送服務(wù)均使用PDDS組件實(shí)現(xiàn)多個(gè)應(yīng)用共享長(zhǎng)連接的功能.由于作者未能在華為開(kāi)發(fā)平臺(tái)上注冊(cè)成功，因此無(wú)法針對(duì)華為推送(Huawei Push)進(jìn)行有效的測(cè)試，故本文選擇其余6個(gè)使用PDDS組件的推送服務(wù)作為實(shí)驗(yàn)對(duì)象，即百度云推送[8](Baidu Push)、友盟推送[9](Umeng Push)、騰訊信鴿推送[10](XG Push)、愛(ài)心推送[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ù)開(kāi)發(fā)平臺(tái)上進(jìn)行注冊(cè)，獲取推送SDK進(jìn)行攻擊程序及目標(biāo)應(yīng)用的開(kāi)發(fā).攻擊程序使用2.3節(jié)介紹的攻擊模型實(shí)現(xiàn)針對(duì)目標(biāo)應(yīng)用的竊聽(tīng)、篡改、偽造和重放攻擊.目標(biāo)應(yīng)用嚴(yán)格遵循各平臺(tái)的開(kāi)發(fā)者文檔進(jìn)行開(kāi)發(fā)，正確使用推送SDK實(shí)現(xiàn)相關(guān)功能.

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

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

1) 消息竊聽(tīng)攻擊

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

針對(duì)6個(gè)推送服務(wù)進(jìn)行竊聽(tīng)攻擊的實(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ù)，因此通過(guò)Hook該類函數(shù)可以直接獲取這些SDK分發(fā)的推送數(shù)據(jù).

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

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

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

2) 消息篡改攻擊

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

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

Table 4 Results of Tampering Attack

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

3) 消息偽造攻擊

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

針對(duì)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ù)格式類，通過(guò)使用Java反射技術(shù)創(chuàng)建該類的實(shí)例即可構(gòu)造正確格式的推送數(shù)據(jù).

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

4) 消息重放攻擊

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

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

Table 6 Results of Replay Attack

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

Fig. 7 Eavesdropping attack against SecPush.圖7 針對(duì)SecPush的竊聽(tīng)攻擊

4.2 SecPush的有效性測(cè)試

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

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

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

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

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

4.3 SecPush方案的性能測(cè)試

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

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

實(shí)驗(yàn)所用測(cè)試設(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長(zhǎng)度為734 B，采用加密及HMAC運(yùn)算后Msgsend的長(zhǎng)度為1 019 B.應(yīng)用程序通常不會(huì)在1條推送消息中放置大量數(shù)據(jù)，實(shí)驗(yàn)中選用的數(shù)據(jù)長(zhǎng)度可以很好地反映推送數(shù)據(jù)在實(shí)際生活中的使用情況.

測(cè)試結(jié)果如表7所示.其中第1行數(shù)據(jù)是針對(duì)使用加密及HMAC運(yùn)算enhanced mode的應(yīng)用程序的測(cè)試結(jié)果；第2行數(shù)據(jù)是針對(duì)不使用安全保護(hù)機(jī)制normal mode的應(yīng)用程序的測(cè)試結(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)處理完成，因此對(duì)CPU的使用相對(duì)集中，實(shí)際使用中很少出現(xiàn)連續(xù)發(fā)送多組推送數(shù)據(jù)的情況，因此不會(huì)出現(xiàn)如此高的CPU占用率.本文額外測(cè)試了每隔3 s發(fā)送1組推送數(shù)據(jù)時(shí)CPU的占用率情況，測(cè)試結(jié)果顯示CPU占用率的峰值為1%.

Table 7 Performance Test of SecPush

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

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

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

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

5 相關(guān)工作

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

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

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

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

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

6 結(jié)束語(yǔ)

本文分析了第三方Android推送服務(wù)在數(shù)據(jù)分發(fā)環(huán)節(jié)存在的安全問(wèn)題，設(shè)計(jì)了相應(yīng)的攻擊場(chǎng)景，成功實(shí)現(xiàn)了針對(duì)推送數(shù)據(jù)的竊聽(tīng)、篡改、偽造和重放攻擊，并具體展示了利用這些技術(shù)實(shí)施的用戶私聊信息竊取及釣魚(yú)攻擊等攻擊場(chǎng)景.實(shí)驗(yàn)結(jié)果表明，百度云推送、友盟推送、騰訊信鴿推送等第三方Android推送服務(wù)在數(shù)據(jù)分發(fā)環(huán)節(jié)存在嚴(yán)重的安全問(wèn)題，沒(méi)有實(shí)現(xiàn)其宣稱的典型應(yīng)用場(chǎng)景的安全需求，當(dāng)開(kāi)發(fā)者將推送服務(wù)用于這些場(chǎng)景時(shí)，有可能給用戶帶來(lái)實(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)

(深圳尺子科技有限公司. 移動(dòng)互聯(lián)網(wǎng)企業(yè)運(yùn)營(yíng)解決方案整合平臺(tái)[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ù)有限公司. 愛(ài)心推 [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開(kāi)發(fā)者平臺(tái) [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ù)字簽名的移動(dòng)通信技術(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

國(guó)家“九七三”重點(diǎn)基礎(chǔ)研究發(fā)展計(jì)劃基金項(xiàng)目(2012CB315804); 國(guó)家自然科學(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).