MobSF移动安全检测框架简述
移动安全分析框架 (MobSF) 是⼀个智能的、集成型的、开源移动App（安卓/iOS）⾃动检测框架，能⽤于静态检测和动态检测。该框架可以进⾏⾼效迅速的移动应⽤安全分析。⽂章将介绍MobSF的使⽤指南和检测项⽬，并对框架结构进⾏分析。
1.MobSF使⽤指南
1）上传分析⽂件she
sast使⽤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。everydayenglish
②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可以被调试，攻击者可以获取调试信息，这会泄漏许多关键信息，造成严重的安全风险。
cable modem
2）检查android:allowBackup是否为true，如果为true或者未定义android:allowBackup，都认为此处具有级别为“中等”的安全风险，通常认为可以备份应⽤数据是有安全风险的，如果未定义，则在某些情况下系统会默认该项为true，同样会造成安全隐患，如果检测出未定义android:allowBackup，那么将会提⽰需要将其设置为fal。
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_cret_code，如果是，则存在“⾼”安全风险，将会导致加密内容泄漏。
9）⼆进制短信端⼝处于监听状态。程序应当对接收的短信进⾏安全性验证，并且应该假定所有接收到的短信都来⾃不可信任源。如果对⼆
进制短信没有进⾏适当处理，则程序具有“⾼”安全风险。
（注：关于⼆进制短信的相关内容可以查看）
安全分析的第⼆部分是源码分析，源码分析的所有项⽬都在如下这个元组中，这⾥是源码分析中所有检测项⽬的标签，每⼀项的具体
near怎么读
含义以及判别⽅式将会逐⼀说明。
key:[]for key
in('inf_act','inf_r','inf_bro','log','fileio','rand','d_hcode','d_app_tamper','dex_cert','dex_tamper','d_rootcheck','d_root','d_ssl_pin','dex_roo )
石家庄出国留学在程序确认⽂件路径后，初始化源码分析，由于源码不同于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[].append(
place(java_src,''))
⾸先⽤正则表达式寻找所有设置MODE_WORLD_READABLE的项，如果找到则存在这个标签为的安全风险，并且记录⽂件名称及路径，
⽅便在最后的报告中查看源码⽂件。在上⾯的元组中可以看到，这⼀标签已经⽤红⾊标出。其他检测项与之同理，因为代码量较⼤，这⾥不
再⼀⼀解读。这⼀步骤结束后，第四部分的安卓API功能也在这个源码⽂件中实现，这⾥只是罗列了所有⽤到的API并做简单描述，然后附
上调⽤API的源码位置，功能较为简单。
完成了源码的分析后，对每⼀项安全风险进⾏了描述，还是以'd_con_world_readable'为例，如果发现这⼀风险，则提⽰⽤户当前⽂
件可以被其他应⽤读取，存在有安全风险。这⾥总共罗列了32个安全风险，但在上⾯的元组中有72项，这是因为元组中72项并⾮全部是安
全风险，源码分析中的检测项被分为四个级别，分别是“⾼危”、“信息”、“安全”和“警告”。其中“⾼危”是最⾼级别的安全风
险，“警告”是次⼀级的，“信息”则主要是敏感信息、隐私信息保护不当，不属于安全风险，“安全”属于表扬性质，在代码中发现有防
⽌截屏、root检查等功能，则列出标记为安全。⽇志信息或者敏感信息加密不当属于“信息”。不安全的Web视图实现属于“警告”。其余
检测出的项⽬全部标记为“⾼危”。这种粗粒度的分级⽅式是不够完善的，在接下来的⼯作中我们可以进⼀步细化各个安全风险的分级，并
veral的用法
将之前的评分模型应⽤进去，在完成安全分析的同时给出⼀个评分，使该框架的安全评价更为完善。
3.App漏洞整理对⽐
在之前的⼯作中，对App漏洞进⾏了整理，MobSF中也有许多检测项⽬，这⾥对两种漏洞整理进⾏对⽐，⽅便未来的增删改⼯作。
我整理的漏洞分为四类：源码安全漏洞、组件安全漏洞、数据安全漏洞、业务逻辑漏洞。MobSF的安全分析则分为三部分，manifest分
析、源码分析和⽂件分析。对于其中的具体项⽬在表1中进⾏对⽐。
method是什么意思
表1 App漏洞整理对⽐
检测项⽬MobSF我的⼯作
代码未混淆×√
Dex保护不⾜×√
So保护不⾜×√
调试设置漏洞√√
组件导出漏洞√√
activity绑定browrable与⾃定义协议×√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进⾏安全评级。
