MobSF移动安全检测框架简述

移动安全分析框架 (MobSF) 是一个智能的、集成型的、开源移动App（安卓/iOS）自动检测框架，能用于静态检测和动态检测。该框架可以进行高效迅速的移动应用安全分析。文章将介绍MobSF的使用指南和检测项目，并对框架结构进行分析。

1.MobSF使用指南

（1）上传分析文件

使用MobSF进行App安全检测的第一步，是将APK文件上传到MobSF上去，上传APK文件有以下三种方法。

①在MobSF的首页上，有一处可以进行文件拖动，提示把文件拖动到此处或点击上传并分析按钮，只要拖动APK文件至该处即可，框架将会开始对该文件进行检测分析。

②在上述文件拖动框的下方，有上传并分析按钮，点击后在磁盘相应位置找到APK文件并上传。

③除了上传文件之外，MobSF还能查看上传过的文件的分析结果。可以通过APK文件的md5进行搜索，来搜索上传过的文件的分析结果，或者在首页点击最近分析项目，进入其中选择想要查看的APK文件的分析结果。

（2）下载分析报告

上传分析报告后，MobSF会以网页的形式展示所有分析结果（具体分析项目会在下一部分详细描述）这些分析结果可以下载以方便打印查看等，而MobSF也十分人性化的提供了下载功能。在网页左边菜单栏的倒数第二项，点击下载报告，不同浏览器可能会提供不同的反馈，但最终都能得到一份PDF格式的分析报告，而报告的内容和网页上显示的是一模一样的，在格式上会稍有差异。

在条件允许的情况下不建议下载分析报告进行查看，在MobSF的界面中直接进行查看会更加的方便，UI也更为美观。

（3）动态分析

除了生成静态分析报告，MobSF还可以进行动态分析。

在左边菜单栏下载报告的下一行，即最后一项，点击开始动态分析，可进入动态分析界面。如图1所示，动态分析界面的左半部分是虚拟机的屏幕分享，右半部分是提示信息，状态信息等内容。这里的手机屏幕并非是一个可操作的虚拟机，MobSF框架在安装过程中就要求安装OracleVM VirtualBox，这里的手机屏幕显示的是VirtualBox中的虚拟机界面，操作需要在虚拟机中操作，这里只能查看屏幕当前显示情况。

图1 动态分析界面

在开始阶段，只有一个蓝色按钮“创建环境”，点击创建环境，可以在启动MobSF的命令行看到当前工作情况，如果发现环境没有正常启动可以在这里查看错误信息，来找出问题所在。通常情况都是APK无法在虚拟机中安装。在环境创建成功后，会出现6个新的按钮，分别是：显示屏幕，移除MobSF的RootCA，开始导出Activity测试者，开启Activity测试者，屏幕截图，结束测试。

事实上MobSF中的动态检测功能并不好用，存在许多BUG。例如一个应用进行完动态分析之后，无法再对第二个应用进行动态分析，需要重启MobSF和虚拟机才能进行第二次动态分析，在部分极端情况下甚至要重启才能恢复正常。还有就是显示屏幕这个功能时常失灵，无法保证正常工作。

2.MobSF静态检测模块

（1）基本信息

①文件信息：文件信息包括了文件名、文件大小、md5、sha1、sha256。

②App信息：App信息包括了包名、Main Activity等信息。

③基本信息中还会给出Activities、Services、Receivers、Providers这四大组件的数目，以及可导出组件的数目。在之前的安卓漏洞学习笔记中已经提到了，可导出组件是较为严重的安全漏洞，因此这里单独列出了可导出组件的数目。

（2）代码性质

在代码性质中，可以查看并下载App的Java代码，或者查看并下载Smali代码，再或者查看Manifest文件。另外，在代码性质中部分中也可以开始动态分析。

（3）权限信息

在权限信息中，罗列了被检测App在Manifest文件中申请的所有权限，并标出了每个权限的危险指数，对于有安全隐患的权限标记为危险。在每个权限后面都加上了该权限的作用简介，并对其功能及安全风险进行了描述。

以android.permission.ACCESS_COARSE_LOCATION为例，被检测App请求了这一权限，这项权限用于获取设备的粗略位置信息，MobSF将其标记为dangerous，即认为这项权限是有安全风险的。在描述中介绍了这一权限的功能，可以通过基站定位等方式获取用户位置，恶意程序可以通过该权限来获取你的大致位置。

（4）安卓API

列举了被检测App调用的所有安卓API，并给出了调用API的代码的位置，这一功能在代码研究分析时比较实用，但在安全检测分析中实际作用并不大，考虑在修改框架时将其删除。

（5）安全分析

安全分析是MobSF的最重要部分，安全分析分为三部分，manifest分析、源码分析和文件分析。

Manifest文件的分析代码位于C:\MobSF\StaticAnalyzer\views\android\manifest_analysis.py，关于各功能实现代码的位置将在第三部分对框架的解析中详细阐述，这里不再赘述。此处将通过分析源代码来对manifest分析功能进行深入的认识。代码的第一部分是获取manifest文件，获取方法的函数已经在别处实现，这里的函数主要用于处理获取manifest文件时发生的异常，获取失败时程序将抛出异常。第二部分是获取manifest数据，这部分代码从manifest文件中提取上文提到的基本信息和权限信息。第三部分与我们的工作无关，此处不予分析。第四部分是重点的manifest文件分析代码，首先对权限管理进行了定义。

if protectionlevel== "0x00000000":

protectionlevel="normal"

elif protectionlevel== "0x00000001":

protectionlevel="dangerous"

elif protectionlevel== "0x00000002":

protectionlevel="signature"

elif protectionlevel== "0x00000003":

protectionlevel="signatureOrSystem"

这和安卓系统定义的权限管理是一致的，权限被声明为Normal级别，任何应用都可以申请，在安装应用时，不会直接提示给用户，点击全部才会展示。权限被声明为Dangerous级别，任何应用都可以申请，在安装应用时，会直接提示给用户。权限被声明为Signature级别，只有和该apk(定义了这个权限的apk)用相同的私钥签名的应用才可以申请该权限。权限被声明为SignatureOrSystem级别，有两种应用可以申请该权限，一是和该apk(定义了这个权限的apk)用相同的私钥签名的应用，还有则是在/system/app目录下的应用。

接下来则是具体到每一项有安全风险的权限分析。

1）检查android:debuggable是否为true，如果是true，那么认为此处具有级别为“高”的安全风险，因为此时App可以被调试，攻击者可以获取调试信息，这会泄漏许多关键信息，造成严重的安全风险。

2）检查android:allowBackup是否为true，如果为true或者未定义android:allowBackup，都认为此处具有级别为“中等”的安全风险，通常认为可以备份应用数据是有安全风险的，如果未定义android:allowBackup，则在某些情况下系统会默认该项为true，同样会造成安全隐患，如果检测出未定义android:allowBackup，那么将会提示需要将其设置为false。

3）检查android:testOnly是否为true，如果是则具有“高”安全风险，在此情况下程序出于测试状态，会暴露程序本身的功能或数据，这将导致安全漏洞。

4）检查Activity有没有设置TaskAffinity。MobSF认为，设置了TaskAffinity会让其他应用读取到发送给另一个任务的intents，而这具有“高”安全风险。框架建议这一项使用默认设置。

5）Activity启动方式不标准，这也具有“高”安全风险，当intent中包含敏感信息时，Activity启动方式应该设置为“standard”，如果设置为"singleTask/singleInstance"则可能导致信息泄漏。

6）组件导出检测。在之前的报告中已经强调过，组件可导出是很常见的安全风险，任何组件都不应设置为可导出的，否则均认为存在安全隐患。

7）不适当的Content Provider权限，Content Provider如果设置权限为设备上所有App均可访问则有可能导致其中包含的敏感信息泄露，这具有“高”安全风险。具体包括"android:pathPrefix=/"，"android:path=/"和"android:pathPattern=*"。

8）检查android:scheme中是否存在有android_secret_code，如果是，则存在“高”安全风险，将会导致加密内容泄漏。

9）二进制短信端口处于监听状态。程序应当对接收的短信进行安全性验证，并且应该假定所有接收到的短信都来自不可信任源。如果对二进制短信没有进行适当处理，则程序具有“高”安全风险。

（注：关于二进制短信的相关内容可以查看https://mobiforge.com/design-development/binary-sms-sending-rich-content-devices-using-sms）

        安全分析的第二部分是源码分析，源码分析的所有项目都在如下这个元组中，这里是源码分析中所有检测项目的标签，每一项的具体含义以及判别方式将会逐一说明。

key: [] for key in('inf_act','inf_ser','inf_bro','log','fileio','rand','d_hcode','d_app_tamper','dex_cert','dex_tamper','d_rootcheck','d_root','d_ssl_pin','dex_root','dex_debug_key','dex_debug','dex_debug_con','dex_emulator','d_prevent_screenshot','d_webviewdisablessl','d_webviewdebug','d_sensitive','d_ssl','d_sqlite','d_con_world_readable','d_con_world_writable','d_con_private','d_extstorage','d_tmpfile','d_jsenabled','gps','crypto','exec','server_socket','socket','datagramp','datagrams','ipc','msg','webview_addjs','webview','webviewget','webviewpost','httpcon','urlcon','jurl','httpsurl','nurl','httpclient','notify','cellinfo','cellloc','subid','devid','softver','simserial','simop','opname','contentq','refmethod','obf','gs','bencode','bdecode','dex','mdigest','sqlc_password','d_sql_cipher','d_con_world_rw','ecb','rsa_no_pad','weak_iv' )

在程序确认文件路径后，初始化源码分析，由于源码不同于manifest文件是标准化的XML语言，因此在分析中需要使用正则表达式，Python中的re.findall()函数可以很好的满足需求。以第一段分析代码为例

if(

    re.findall(r'MODE_WORLD_READABLE|Context\.MODE_WORLD_READABLE', dat) or re.findall(r'openFileOutput\(\s*".+"\s*,\s*1\s*\)', dat)

    ):

        code['d_con_world_readable'].append(

jfile_path.replace(java_src,''))

首先用正则表达式寻找所有设置MODE_WORLD_READABLE的项，如果找到则存在这个标签为'd_con_world_readable'的安全风险，并且记录文件名称及路径，方便在最后的报告中查看源码文件。在上面的元组中可以看到，这一标签已经用红色标出。其他检测项与之同理，因为代码量较大，这里不再一一解读。这一步骤结束后，第四部分的安卓API功能也在这个源码文件中实现，这里只是罗列了所有用到的API并做简单描述，然后附上调用API的源码位置，功能较为简单。

        完成了源码的分析后，对每一项安全风险进行了描述，还是以'd_con_world_readable'为例，如果发现这一风险，则提示用户当前文件可以被其他应用读取，存在有安全风险。这里总共罗列了32个安全风险，但在上面的元组中有72项，这是因为元组中72项并非全部是安全风险，源码分析中的检测项被分为四个级别，分别是“高危”、“信息”、“安全”和“警告”。其中“高危”是最高级别的安全风险，“警告”是次一级的，“信息”则主要是敏感信息、隐私信息保护不当，不属于安全风险，“安全”属于表扬性质，在代码中发现有防止截屏、root检查等功能，则列出标记为安全。日志信息或者敏感信息加密不当属于“信息”。不安全的Web视图实现属于“警告”。其余检测出的项目全部标记为“高危”。这种粗粒度的分级方式是不够完善的，在接下来的工作中我们可以进一步细化各个安全风险的分级，并将之前的评分模型应用进去，在完成安全分析的同时给出一个评分，使该框架的安全评价更为完善。

3.App漏洞整理对比

在之前的工作中，对App漏洞进行了整理，MobSF中也有许多检测项目，这里对两种漏洞整理进行对比，方便未来的增删改工作。

我整理的漏洞分为四类：源码安全漏洞、组件安全漏洞、数据安全漏洞、业务逻辑漏洞。MobSF的安全分析则分为三部分，manifest分析、源码分析和文件分析。对于其中的具体项目在表1中进行对比。

表1 App漏洞整理对比

检测项目	MobSF	我的工作
代码未混淆	×	√
Dex保护不足	×	√
So保护不足	×	√
调试设置漏洞	√	√
组件导出漏洞	√	√
activity绑定browserable与自定义协议	×	√
ActivityManager漏洞	√	√
Service组件漏洞	√	√
动态注册广播组件暴露漏洞	×	√
Content Provider中的SQL注入漏洞	×	√
Content Provider读写权限漏洞	√	√
Provider文件目录遍历漏洞	√	√
隐式意图调用漏洞	×	√
意图协议URL漏洞	×	√
Webview明文存储密码风险	√	√
Webview远程代码执行漏洞	×	√
Webview绕过证书校验漏洞	×	√
未移除有风险的Webview系统隐藏接口	√	√
WebView忽略SSL证书错误	√	√
数据存储漏洞	√	√
数据加密漏洞	√	√
数据传输漏洞	√	√
日志信息漏洞	√	√
权限漏洞	√	√
业务漏洞	×	√
android:testOnly检测	√	×
TaskAffinity检测	√	×
Activity启动方式不标准	√	×
二进制短信端口	√	×
android:scheme检测	√	×
······	······	×

        表中信息并不完全，在MobSF中还有很多细致的检测项，在前文提到了，仅安全分析模块就有82个检测项，安全分析中的源码分析部分的分析项并未全部列出，凡是未列出的源码分析项全是我的工作中所没有的。另外，我的工作中一些检测项目在MobSF中在其他模块中，不在安全分析模块，例如数据传输漏洞等，这些功能将在未来工作中移动到安全分析模块，方便对App进行安全评级。