導語：Check Point研究人員發現小米手機預裝應用安全中心中存在安全漏洞。
智能手機一般都有預裝的應用軟件，其中一些是非常有用的，而有些是我們從來都不會用的。因為預裝的App都有所需的所有權限，一旦這些預裝應用不安全或存在漏洞，會對用戶隱私和安全帶來潛在威脅。Check Point分析發現小米安全中心應用程序就存在安全漏洞，並沒有承諾的那麼安全和隱私。
Check Point研究人員發現小米手機預裝應用中存在安全漏洞。更諷刺的是存在漏洞的應用竟然是安全中心（Guard Provider，com.miui.guardprovider），安全中心應用程序本來應該是檢測惡意軟件、保護用戶手機的，但是小米安全中心卻將用戶暴露在威脅之中。
由於網絡流量和安全中心應用之間網絡流量不安全的本質，攻擊者可以連接在受害者所在的WiFi網絡，併發起中間人（Man-in-the-Middle，MiTM）攻擊。然後作為第三方SDK更新，安全中心可以關閉惡意軟件保護並注入惡意代碼來竊取數據、植入勒索軟件、追蹤軟件或安裝其他任意的惡意軟件。
Check Point將該漏洞通報給小米後，小米已經發布了補丁。
圖1: Xiaomi預裝的安全中心APP（Guard Provider）
攻擊原理
小米安全中心APP是所有主流手機中都預裝的APP，它使用許多第三方SDK作為提供的安全服務的一部分，包括設備保護、垃圾清理等。
APP中植入了三種不同的反病毒引擎供用戶選擇，分別是Avast, AVL和騰訊。在選擇APP後，用戶可以選擇其中一個引擎作為掃描設備的默認反病毒引擎。
實際上在同一APP中使用多個SDK有一些潛在的不利之處。因為這些SDK共享App環境和權限，主要的不利之處在於：
· 一個SDK中存在問題可能會破壞其他所有SDK的保護
· 一個SDK的私有存儲數據無法隔離，可以被其他SDK訪問。
下面解釋一下如何在小米安全中心應用中執行遠程代碼執行攻擊。
由於來自小米設備的安全中心應用的網絡流量都是不安全的，因此可以通過中間人攻擊的方式進行攔截，然後注入惡意代碼作為第三方SDK的更新代碼。下面具體來看一下：
Stage 1: Avast更新
默認情況下AVAST是該APP的安全掃描器，APP會週期性地下載 avast-android-vps-v4-release.apk APK文件到安全中心APP的私有目錄來更新病毒數據庫：
/data/data/com.miui.guardprovider/app_dex/vps_update_.apk.
當文件下載完成後，Avast SDK 會加載和執行該APK文件。比如，vps_update_20190205-124933.apk：
圖2: Avast更新文件
但是因為更新過程使用的是不安全的HTTP連接來下載文件，因此攻擊者可以通過MITM攻擊來檢測Avast更新的時間並預測下一次要下載的APK的文件名。攻擊者只需要攔截http://au.ff.avast.sec.miui.com/android/avast-android-vps-v4-release.apk連接的響應部分內容就可以：
圖3: Avast更新流量
預測的Avast更新的文件名會用於第二步的攻擊。MITM攻擊者可以用404 error來響應http://au.ff.avast.sec.miui.com/android/vps_v4_info.vpx請求來預防之後的Avast更新。
Stage 2: 通過AVL更新路徑遍歷漏洞來覆寫Avast更新APK
一旦攻擊者開始攔截到Avast服務器的連接，用戶就會將默認的反病毒軟件切換到另一個反病毒引擎，本例中是AVL反病毒軟件。AVL反病毒SDK也是安全中心APP內置的。
當AVL變成默認的反病毒軟件，就會立刻更新App的反病毒數據庫。這是通過請求配置文件（比如http://update.avlyun.sec.miui.com/avl_antiy/miuistd/siglib/20180704.cj.conf）來檢查新病毒簽名的存在來實現的。.conf文件是明文文本格式的，含有新簽名文件的URL、大小、MD5哈希值等。
圖4: AVL更新配置文件
在處理完配置文件之後，AVL會下載簽名壓縮文件（read_update_url域）並解壓到安全中心APP的目錄。
因為下載過程也是通過不安全的連接，因此MITM攻擊者可以修改.conf文件的內容：使用is_new=0來表明新更新的存在，並提供到偽造的ZIP文件的URL鏈接。
圖5: AVL更新配置文件
AVL SDK還存在一個漏洞可以幫助攻擊者實現第二階段的攻擊：即在解壓縮過程中的路徑遍歷漏洞。因此，攻擊者可以用偽造的壓縮文件來覆寫App沙箱中的任意文件，包括與其他SDK相關的文件。
一個偽造的APK文件，加上../../app_dex/vps_update_20190205-124933.apk到ZIP簽名壓縮文件中就可以成功的覆寫之前下載的AVAST更新，所有的反病毒SDK組件在各自的SDK中都使用相同的沙箱。
而上次Avast更新的AOK文件名在第一步的MITM攻擊中已經獲得了。
圖6: 偽造的含有 AVL簽名的壓縮文件
接下來攻擊者需要做的就是恢復Avast通信並攔截AVL通信直到用戶選擇Avast作為反病毒引擎為止。如果用戶選擇Avast作為反病毒引擎，Avast SDK就會加載和執行偽造的惡意APK文件。
因為Avast更新的簽名文件在加載之前是不驗證的，而安全中心App在文件剛下載時已經驗證過簽名了，所以攻擊會成功進行。這樣的話，偽造的惡意文件就可以繞過安全防護，下載到手機上並正常運行。
結論
小米的案例讓我們再一次對智能手機廠商的預裝應用的可信度提出了質疑。同時在應用開發的時候要注意其安全性，尤其是智能手機廠商要注意預裝和內置應用程序的安全性。
上面的攻擊場景說明了在同一app中使用多個SDK文件的不安全性。單個SDK的漏洞可能只是獨立的問題，但是同一app中的多個SDK存在安全漏洞的話，就可能會引發組合漏洞，造成難以估量的危害和威脅。
