小米手机预装App安全中心将用户暴露在威胁之中

智能手机一般都有预装的应用软件，其中一些是非常有用的，而有些是我们从来都不会用的。因为预装的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_<timestamp>.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存在安全漏洞的话，就可能会引发组合漏洞，造成难以估量的危害和威胁。