Android應用第三方推送服務安全分析與安全增強

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

1(中國科學院軟件研究所可信計算與信息保障實驗室 北京 100190)2(國家計算機網絡應急技術處理協調中心 北京 100029)3(中國科學院大學計算機與控制學院 北京 101408)(luyemian@tca.iscas.ac.cn)

?

Android應用第三方推送服務安全分析與安全增強

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

1(中國科學院軟件研究所可信計算與信息保障實驗室 北京 100190)2(國家計算機網絡應急技術處理協調中心 北京 100029)3(中國科學院大學計算機與控制學院 北京 101408)(luyemian@tca.iscas.ac.cn)

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

安卓；推送服務；數據分發；共享通道；安全分析；安全增強

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

推送服務極大地簡化了移動終端應用開發者的開發過程，然而其在帶來巨大便利的同時也帶來了一些安全隱患.Li等人[2]對推送服務中應用程序的注冊操作和PendingIntent對象的使用進行了詳細的分析，指出攻擊者通過精心的設計，可以獲取本應發送給目標設備上目標應用用戶的隱私數據，或導致目標應用執行攻擊者發送的命令.Li等人的分析多集中在應用程序的注冊過程和信息上傳過程，對目標設備上推送數據傳遞環節的安全性缺少詳細的分析.

目標設備上推送數據的傳遞過程存在3種實現方式:

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

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

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

本文對使用PDDS組件的第三方Android推送服務進行了詳細的分析，發現其中多數推送服務缺乏對推送數據分發環節安全性的有效保護，包括其市場占有率居于前幾位的百度云推送、友盟推送和騰訊信鴿推送.數據分發環節安全措施的缺乏可能導致用戶的隱私信息被泄露，或將用戶置于釣魚攻擊的威脅之下.本文設計了相應的攻擊模型以檢測推送服務在數據分發環節的安全性，通過在攻擊程序中對推送服務的函數調用進行Hook，實現了針對推送數據的竊聽、篡改、偽造和重放攻擊.最后，針對發現的安全問題，本文提出了相應的安全增強方案.

本文的貢獻主要包括4個方面：

1) 分析了第三方Android推送服務數據分發環節安全機制的實現情況，并設計了相應的攻擊模型；

2) 針對多個推送服務進行了實際分析和攻擊測試，實驗結果表明，多數第三方Android推送服務面臨著竊聽、篡改、偽造和重放攻擊的威脅；

3) 提出了Android推送服務安全增強方案SecPush，通過添加加密模塊和HMAC運算增強推送服務數據分發環節的安全性，實現了數據機密性、完整性、不可偽造性和抗重放攻擊的安全需求；

4) 實現了SecPush原型系統，并對其進行安全測試，實驗結果表明，SecPush能有效抵擋竊聽、篡改、偽造和重放攻擊.

1 第三方Android推送服務的使用模式

本文的研究對象是使用PDDS組件進行推送數據分發的第三方Android推送服務，其整體架構如圖1所示：

Fig. 1 Framework of third-party Android push service.圖1 第三方Android推送服務架構

Push SDK為嵌入目標應用的推送SDK；Push Server為推送服務器；Portal為推送服務的Web前端，由推送服務提供商開發維護，方便應用程序開發者在不開發服務端代碼的情況下發送推送信息；Application Server是開發者為其應用開發的服務器端，使用推送服務的服務器端SDK實現推送相關功能，開發者可以通過Application Server向Push Server發送推送消息，由Push Server將該消息推送給目標應用.

推送服務的交互流程如下：

1) 應用程序調用Push SDK的初始化函數，Push SDK將應用的包名、應用創建時從推送平臺獲取的APP_ID等信息傳遞給Push Server，完成應用信息的注冊，獲取ClientId作為當前設備上當前應用在Push Server上的用戶標識，供應用程序開發者向當前設備上的應用發送數據時使用；

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

3) 應用程序開發者通過Portal或Application Server將推送數據提交給Push Server；

4) Push Server使用其與目標應用所在設備之間的socket長連接將推送數據發送給目標設備上的PDDS組件；

5) PDDS組件對收到的數據進行預處理，判斷目標應用，將推送數據傳遞給目標應用；

6) 目標應用的消息接收器根據推送數據類型進行后續處理.

多數第三方Android推送服務提供2種類型的推送數據：1)通知類推送；2)透傳信息.通知類推送將在設備通知欄展現1條通知，用戶點擊該通知后，根據具體類型的不同，Android系統或者打開目標應用的某個界面，或者通過系統瀏覽器或目標應用使用的WebView控件打開某個網頁，通知類推送的處理一般由推送服務SDK自己實現；而透傳信息則是由應用程序開發者設計其獨有的數據格式及相應的處理方式，推送服務只負責將推送數據傳遞給目標應用，不負責后續的處理過程.

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

2 推送服務數據分發環節安全性分析

本節主要分析第三方Android推送服務數據分發環節中存在的安全問題，并介紹敵手能力及相應的攻擊模型.

2.1 安全目標

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

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

2.2 敵手能力分析

推送服務數據分發環節的核心參與者是PDDS組件，可控制PDDS組件運行的宿主應用為該環節的攻擊者.

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

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

本文設定的攻擊程序不具備root權限，因此可以在所有使用Android系統的設備上實施攻擊.由于攻擊程序與目標應用屬于不同的應用，根據Android系統中進程沙箱隔離機制的設計，在未獲取root權限的情況下，攻擊程序無法干涉目標應用的運行，也無法獲取目標應用通過其他途徑進行網絡通信的數據.

針對2.1節中描述的安全目標，攻擊者可能實施的攻擊如下：

1) 消息竊聽

由于通過目標推送服務傳輸的數據都需要經過PDDS組件的處理，因此可以在PDDS組件收到數據并分發給目標應用的過程中獲取傳送給所有目標應用的數據.當推送數據涉及私聊信息等用戶隱私數據且未經加密保護時，該攻擊將導致用戶隱私信息的泄露.

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

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

除了獲取用戶隱私信息，攻擊者還可以從竊聽到的數據中獲取目標應用的APP_ID、消息格式等信息，這些信息將有助于構造符合格式要求的偽造數據.此外消息篡改和重放攻擊也需要首先獲取目標應用應接收的正確數據以作修改或重放.可以認為，竊聽攻擊是攻擊者進行后續攻擊的基礎.

2) 消息篡改

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

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

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

3) 消息偽造

通過分析竊聽攻擊獲得數據的數據格式，PDDS組件的宿主應用可以偽造1條符合格式要求的新消息發送給目標應用，經過目標應用的正確處理后將內容展示給用戶.

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

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

Fig. 4 Forgery attack for Pogo.圖4 針對Pogo應用的偽造攻擊

如果攻擊者可以通過其他方式控制“Pogo看演出”應用網絡數據的發送，那么攻擊者可以截獲用戶lulu發出的所有信息，在這種情況下，攻擊者完全可以偽裝成“Pogo看演出”應用的合法用戶與lulu進行私聊，從而實施社會工程學攻擊.

4) 消息重放

PDDS組件的宿主應用可以將收到的數據重復發送給目標應用，如果目標應用不檢測數據的新鮮性，將會再次處理重放消息.

2.3 攻擊實現

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

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

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

圖5中實線箭頭所示為推送SDK分發數據的正常途徑，步驟如下：

Step1. Push Server將推送數據發送給目標設備上的PDDS組件；

Step2. PDDS組件對數據進行簡單處理，判斷目標應用為Application 2，通過sendBroadcast等函數將數據發送給Application 2相應的Push Receiver.

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

Step1′. Push Server將推送數據發送給目標設備上的PDDS組件，同Step1；

Step2′. Hook Service截獲PDDS對send-Broadcast等函數的調用，從Intent類型參數中獲取推送數據進行分析，同時修改推送數據的內容；

Step3′. Hook Service將篡改后的推送數據通過sendBroadcast等函數發送給目標應用Application 2對應的Push Receiver，實施篡改攻擊；

Step4′. 攻擊程序通過分析Step2′中竊聽到的數據，偽造合適的推送數據發送給目標應用，或者將Step2′中竊聽到的推送數據重復發送給目標應用，實施重放攻擊.

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

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

3 SecPush的設計與實現

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

本節主要介紹SecPush的設計原理、安全性分析及局限性分析.

3.1 系統設計

SecPush的設計目標在于增強推送數據分發環節的安全性，實現數據機密性、完整性、不可偽造性和抗重放攻擊的安全需求.SecPush采用對稱加密及HMAC運算提供數據機密性、完整性和不可偽造性保護，通過數據庫保存和查詢推送消息Id的方式提供消息重放檢測功能.具體設計描述如下:

3.1.1 密鑰分配方案設計

應用程序與推送服務器之間需要共享對稱密鑰和HMAC運算密鑰方可完成推送數據的加解密運算和HMAC驗證，設計安全的密鑰分配方案保護目標應用的密鑰不被敵手獲取是保證SecPush方案安全性的關鍵.

根據推送服務的典型應用場景，推送數據可以大致分為2種類型：1)面向應用程序多數用戶發送的公開信息，例如新產品推薦、活動通知等；2)針對特定用戶發送的私密信息，例如新增評論、私聊信息等.2種類型數據的安全需求不同，對于公開信息而言，機密性并不是必要需求，因為任何使用該應用程序的用戶都可能收到這些公開通知，對于這類信息而言，安全防護的重點在于防止信息內容被攻擊者篡改或偽造從而進行釣魚等后續攻擊.對于私密信息而言，數據機密性、完整性、不可偽造性和抗重放攻擊都是進行安全防護的重要目標.根據不同的安全需求，SecPush設計了不同的密鑰分配方案.

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

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

3.1.2 推送數據格式設計

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

Msgsend={pkgname,msgId,enctype,contentc,

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

contentc的格式如下：

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

3.1.3 SecPush方案架構設計

SecPush方案的整體架構如圖6所示:

Fig. 6 Framework of SecPush.圖6 SecPush方案架構圖

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

公開信息推送的運行流程如下：

1) Application調用Client SDK的初始化函數，向Push Server發送應用信息注冊請求；

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

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

4) 應用程序開發者通過Portal或Application Server，將推送數據提交給Push Server；

5) Push Server查詢安裝有目標應用的目標設備，并獲取相應的加密密鑰和HMAC運算密鑰，構造推送數據Msgsend，通過Push Server與目標設備之間的socket連接將Msgsend發送給目標設備上的PDDS組件；

6) PDDS組件從Msgsend中獲取目標應用包名，通過函數sendBroadcast將Msgsend發送給目標應用的Client SDK；

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

私密信息推送的運行流程如下：

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

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

3) Application Server需要推送私密信息時，調用Server SDK的接口，使用相應用戶的加密密鑰和HMAC運算密鑰構建推送數據Msgsend，之后將目標應用的APP_ID，Msgsend，ClientId作為參數傳遞給Server SDK，由Server SDK向Push Server發起推送請求；

4) Push Server通過查詢目標應用APP_ID及ClientId尋找與目標設備之間的socket連接，通過該連接將Msgsend發送給目標設備上的PDDS；

5) PDDS從Msgsend中獲取目標應用包名，將Msgsend發送給目標應用的Client SDK；

6) 目標應用的Client SDK使用相應密鑰進行后續處理.

為了提高公開信息推送的安全性，對于需要用戶登錄的應用程序，開發者也可以選擇在用戶登錄后使用私密信息處理密鑰對公開推送信息進行安全保護，Server SDK提供相應的接口供Application Server調用.

3.2 安全性分析

通過3.1節的設計，SecPush實現了推送數據分發環節的安全需求.

3.2.1 機密性

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

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

分析表明：SecPush可以有效對抗攻擊程序實施的消息竊聽攻擊.

3.2.2 完整性

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

對于私密信息推送而言，由于攻擊者無法獲取同一設備上目標應用處理私密推送數據的加密密鑰和HMAC運算密鑰，因此無法解密并修改推送服務器發送給目標應用的推送數據，也無法生成合法的HMAC運算結果.

分析表明：SecPush可以有效對抗攻擊程序實施的消息篡改攻擊.

3.2.3 不可偽造性

由于攻擊程序無法獲取目標應用正在使用的公開信息處理密鑰和私密信息處理密鑰，因此無法構造有效的推送數據密文，也無法生成該密文對應的合法HMAC運算結果.

分析表明：SecPush可以有效對抗攻擊程序實施的消息偽造攻擊.

3.2.4 抗重放攻擊

由于Msgsend中包含msgId信息，目標應用在收到推送數據獲取msgId值后通過查詢數據庫可以判斷當前的消息是否被重放.

3.3 局限性分析

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

3.4 原型系統實現

本文實現了一個基于MQTT協議的SecPush原型系統用于有效性測試及性能測試，其中客戶端SDK基于wmqtt.jar[4]實現，推送服務器基于開源消息代理軟件Mosquitto[5]以及SAM-PHP[6]實現，服務器端SDK使用Java開發.推送數據的加密保護使用DES加密算法實現，數據完整性保護使用HMAC-SHA1算法實現.具體實現細節不再贅述.

4 實驗與分析

本節將詳細展示作者針對6個第三方Android推送服務進行攻擊測試的實驗結果以及SecPush的有效性測試和性能測試結果.

4.1 攻擊測試實驗

本文選取了6個使用PDDS組件的第三方Android推送服務作為實驗對象，使用2.3節介紹的攻擊模型，測試上述6個推送服務在數據分發環節的安全性.

4.1.1 實驗對象選取

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

Table 1 Market Share of Push Services (Top 12)

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

Table 2 Version Number of the Selected Push SDK

4.1.2 實驗設計及結果分析

作者在上述6個推送服務開發平臺上進行注冊，獲取推送SDK進行攻擊程序及目標應用的開發.攻擊程序使用2.3節介紹的攻擊模型實現針對目標應用的竊聽、篡改、偽造和重放攻擊.目標應用嚴格遵循各平臺的開發者文檔進行開發，正確使用推送SDK實現相關功能.

選用自己開發的應用程序作為目標應用，只是為了方便隨時發送推送數據進行竊聽攻擊的測試，在攻擊程序針對目標應用的攻擊成功之后，作者同樣針對4.1.1節中獲取的相關SDK的宿主應用樣本進行了攻擊測試，進一步驗證了實驗結果的正確性.

4類攻擊實驗的結果分述如下：

1) 消息竊聽攻擊

通過Hook推送SDK對sendBroadcast，send-OrderedBroadcast，sendStickyBroadcast等函數的調用，攻擊程序可以在PDDS組件向目標應用分發推送數據的環節進行監聽，獲取傳輸的推送數據.

針對6個推送服務進行竊聽攻擊的實驗結果如表3所示:

Table 3 Results of Eavesdropping Attack

除了騰訊信鴿推送(XG Push)，其他推送SDK均使用函數sendBroadcast或sendOrderedBroadcast進行數據傳輸，且多數SDK傳輸的是明文數據，因此通過Hook該類函數可以直接獲取這些SDK分發的推送數據.

騰訊信鴿推送(XG Push)通過調用函數bindService，將推送數據放置在Intent類型參數中進行傳輸，并且傳輸的是加密后的密文信息.但是作者通過對SDK反編譯代碼的分析，發現在推送Service組件分發數據給目標應用之前，會進行SDK內的數據廣播，在其中某個函數調用處可以獲取推送數據的明文，因此通過Hook該函數，攻擊程序可以在數據進行分發之前獲取其明文信息.除了上述途徑，通過調用騰訊信鴿推送SDK中的解密函數，攻擊程序也可以獲取密文信息對應的明文數據，解密函數不需要輸入密鑰參數.

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

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

2) 消息篡改攻擊

攻擊程序在竊聽數據的環節可以對數據中的部分字段進行修改，實現消息篡改的攻擊.

針對6個推送服務進行篡改攻擊的實驗結果如表4所示.6個推送SDK的目標應用在收到篡改的消息后，均可進行正確處理，將篡改后的消息內容展示給用戶，說明6個推送SDK在收到PDDS分發的消息后均未對消息的完整性進行認證.

Table 4 Results of Tampering Attack

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

3) 消息偽造攻擊

通過分析6個推送服務的消息格式，攻擊者可以偽造數據傳送給目標應用.偽造攻擊可以達到與篡改攻擊相似的攻擊效果.

針對6個推送服務進行偽造攻擊的實驗結果如表5所示：

Table 5 Results of Forgery Attack

實驗中發現，百度云推送(Baidu Push)有單獨的推送數據格式類，通過使用Java反射技術創建該類的實例即可構造正確格式的推送數據.

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

4) 消息重放攻擊

攻擊程序可以將竊聽到的數據進行存儲，之后再重放給目標應用.如果目標應用不對消息的新鮮性進行檢測，將會對重放的消息進行再次處理.

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

Table 6 Results of Replay Attack

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

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

4.2 SecPush的有效性測試

本文開發了2個使用SecPush SDK的應用程序：1)目標應用，其包名為com.lulupush.pushlibtest；2)攻擊程序，其包名為com.example.mypushlibtest.

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

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

攻擊者程序將圖7(b)中收到的數據重放給目標應用，目標應用沒有展示相應的通知，且在logcat中打印出“Old Message!”信息.

實驗結果表明，SecPush實現了推送數據分發環節的數據機密性、完整性、不可偽造性和抗重放攻擊的安全需求，能有效抵擋來自該環節的攻擊者.

4.3 SecPush方案的性能測試

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

實驗中針對CPU占用率和內存使用情況的監測通過top指令進行采樣，采樣周期為1 s，取峰值作為展示數據.針對耗電量的測試，借鑒Android系統耗電量統計相關代碼開發測試軟件，獲取目標應用處理推送數據期間對電量的消耗情況.

實驗所用測試設備為三星Galaxy SIII手機，配備1.4 GHz 4核處理器、1 GB內存空間，電池容量為2 100 mAh.

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

測試結果如表7所示.其中第1行數據是針對使用加密及HMAC運算enhanced mode的應用程序的測試結果；第2行數據是針對不使用安全保護機制normal mode的應用程序的測試結果；第3行數據為兩者的差值，即加密及HMAC運算環節產生的資源和能源消耗.

CPU占用率的數值較大，是因為實驗中的1 000組推送數據是連續發送的，在42 s內處理完成，因此對CPU的使用相對集中，實際使用中很少出現連續發送多組推送數據的情況，因此不會出現如此高的CPU占用率.本文額外測試了每隔3 s發送1組推送數據時CPU的占用率情況，測試結果顯示CPU占用率的峰值為1%.

Table 7 Performance Test of SecPush

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

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

由于實際使用中很少有應用程序在1 d之內收到1 000條推送數據，因此根據本文的實驗結果可以看出，SecPush中增添的安全措施不會給設備帶來沉重的資源和能源負擔.

實驗結果顯示，SecPush方案提高了推送服務數據分發環節的安全性，且其帶來的資源和能源消耗微乎其微，是增強推送服務安全性的有效方案.

5 相關工作

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

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

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

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

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

6 結束語

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

[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)

(深圳尺子科技有限公司. 移動互聯網企業運營解決方案整合平臺[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)

(北京麒麟心通網絡技術有限公司. 愛心推 [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)

(移石創想(北京)科技有限公司.魔推 [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開發者平臺 [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]. 計算機研究與發展, 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)

(袁靜. 基于身份數字簽名的移動通信技術研究[D]. 武漢: 華中科技大學, 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

國家“九七三”重點基礎研究發展計劃基金項目(2012CB315804); 國家自然科學基金項目(61502468); 北京市自然科學基金項目(4154089)

應淩云(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).