移动安全自动化测试框架MobSF多个版本静态分析接口存在的任意文
0×00. 引言
MobSF 一款智能化、一体化的开源移动应用（Android / iOS/Windows Phone）自动测试框架（详见：http://www.myhack58.com/Article/60/63/2017/88298.htm），通过框架自带的Web接口上传待分析的移动应用包，就可以自动有效、快速地对应用APK 和IPA文件 及压缩的源代码进行审计分析， 并给出分析报告。在研究MobSF 框架使用的过程中，发现github的问题列表上有人曝出0.9.4.2 以下的版本web 上传接口对上传的apk包zip解压的时候存在漏洞可导致任意文件写入，引发潜在的代码执行漏洞，本文以0.9.3.7 Beta版本为例进行复现与分析，详文如下。
0×01. 复现
1.安装MobSF 0.9.3.7
需要事先安装好JDK1.7。
然后下载MobSF 0.9.3.7，解压，在其目录下执行pip install -r requirements.txt。
最后运行：python manage.py runserver 0.0.0.0:8080。
2.漏洞测试
打开MobSF的web接口（基于Django开发）：
选择事先准备好的漏洞测试验证压缩包，上传分析：
上图表示任意文件写入成功，因为系统处于开发模式下运行，故会自动重载，然后执行__init__.py中的命令(任意文件写入成功，下图，导致代码执行，上图)
查看/root/MobSF/StaticAnalyzer/__init__.py 确实被写入了内容：print ‘Webcome to FreeBuf!
0×02. 分析
先来了解一下MobSF的系统代码结构：
上传功能对应的接口/upload：
/upload接口对应的视图函数：
跟进MobSF.views.upload ，如下：
上传接口的主要功能就是校验文件，然后计算上传文件的MD5值，在响应包中指明即将跳转至静态扫描接口的完整路径,也即如下图所示接口：
开始分析/StaticAnalyzer/ 接口：
静态分析接口位于StaticAnalyzer 模块的android.static_analyzer.static_analyzer视图函数中，跟进：
最终回调用Unzip函数对上传的apk文件进行解压缩，问题就出在这个函数中，这函数位于MobSF安装路径/StaticAnalyzer/views目录下的shared_func.py 模块中（这个路径对于构造漏洞验证压缩包有用）, 核心代码如下：
看到这里就知道为啥能任意文件写入了，虽然Django 框架中的request.FILES对象会对上传文件的文件名进行过滤处理，使得形如../../../的目录穿越失效（详见：http://www.myhack58.com/Article/60/61/2018/91458.htm），导致无法任意目录写入文件，但是request.FILES 不会对压缩包内的文件进行过滤，业务代码逻辑中也未对压缩包内的文件名进行过滤，从而导致漏洞的发生。
因为漏洞验证环境中，MobSF系统处于开发模式下，因为代码文件有变动，导致系统会自动重载，执行写入到StaticAnalyzer模块__init__.py文件的代码，也即执行：print ‘Webcome to FreeBuf!
如果写入到__init__.py中的代码是一段反弹shell代码，那么就存在任意代码执行导致获取系统shell的可能。
0×03. 不足与突破之策
0×02节中最终分析的结果是：导致任意代码执行的前提是：系统处理开发模式，写入代码后会导致系统重载触发代码执行。
不过在正式环境中，系统一般不会处于开发模式，所以被写入的代码不会被执行。
怎么提高恶意代码被执行的概率呢？
0×00. 引言
MobSF 一款智能化、一体化的开源移动应用（Android / iOS/Windows Phone）自动测试框架（详见：http://www.myhack58.com/Article/60/63/2017/88298.htm），通过框架自带的Web接口上传待分析的移动应用包，就可以自动有效、快速地对应用APK 和IPA文件 及压缩的源代码进行审计分析， 并给出分析报告。在研究MobSF 框架使用的过程中，发现github的问题列表上有人曝出0.9.4.2 以下的版本web 上传接口对上传的apk包zip解压的时候存在漏洞可导致任意文件写入，引发潜在的代码执行漏洞，本文以0.9.3.7 Beta版本为例进行复现与分析，详文如下。
0×01. 复现
1.安装MobSF 0.9.3.7
需要事先安装好JDK1.7。
然后下载MobSF 0.9.3.7，解压，在其目录下执行pip install -r requirements.txt。
最后运行：python manage.py runserver 0.0.0.0:8080。
www.wnhack.com
2.漏洞测试
打开MobSF的web接口（基于Django开发）：
选择事先准备好的漏洞测试验证压缩包，上传分析：
上图表示任意文件写入成功，因为系统处于开发模式下运行，故会自动重载，然后执行__init__.py中的命令(任意文件写入成功，下图，导致代码执行，上图)
查看/root/MobSF/StaticAnalyzer/__init__.py 确实被写入了内容：print ‘Webcome to FreeBuf!
0×02. 分析
先来了解一下MobSF的系统代码结构：
本文来自无奈人生安全网 上传功能对应的接口/upload：
/upload接口对应的视图函数：
跟进MobSF.views.upload ，如下：
上传接口的主要功能就是校验文件，然后计算上传文件的MD5值，在响应包中指明即将跳转至静态扫描接口的完整路径,也即如下图所示接口：
开始分析/StaticAnalyzer/ 接口：
copyright 无奈人生 静态分析接口位于StaticAnalyzer 模块的android.static_analyzer.static_analyzer视图函数中，跟进：
最终回调用Unzip函数对上传的apk文件进行解压缩，问题就出在这个函数中，这函数位于MobSF安装路径/StaticAnalyzer/views目录下的shared_func.py 模块中（这个路径对于构造漏洞验证压缩包有用）, 核心代码如下：
内容来自无奈安全网
看到这里就知道为啥能任意文件写入了，虽然Django 框架中的request.FILES对象会对上传文件的文件名进行过滤处理，使得形如../../../的目录穿越失效（详见：http://www.myhack58.com/Article/60/61/2018/91458.htm），导致无法任意目录写入文件，但是request.FILES 不会对压缩包内的文件进行过滤，业务代码逻辑中也未对压缩包内的文件名进行过滤，从而导致漏洞的发生。
因为漏洞验证环境中，MobSF系统处于开发模式下，因为代码文件有变动，导致系统会自动重载，执行写入到StaticAnalyzer模块__init__.py文件的代码，也即执行：print ‘Webcome to FreeBuf!
如果写入到__init__.py中的代码是一段反弹shell代码，那么就存在任意代码执行导致获取系统shell的可能。
0×03. 不足与突破之策
0×02节中最终分析的结果是：导致任意代码执行的前提是：系统处理开发模式，写入代码后会导致系统重载触发代码执行。
不过在正式环境中，系统一般不会处于开发模式，所以被写入的代码不会被执行。
怎么提高恶意代码被执行的概率呢？
copyright 无奈人生