ES文件浏览器CVE-2019-6447漏洞分析

系统漏洞名字

　　ES File Explorer Open Port Vulnerability – CVE-2019年-6447

　　系统漏洞介绍

　　ES文件浏览器在启动建立了1个.com网络服务器，在当地开启了59777端口号。网络攻击根据结构特定的payload可以获得客户手机上文档，安裝apk等实际操作。

　　危害范畴

　　4.1.9.7.4 little below（一部分版本号将会不兼容，也将会和应用商店相关）

　　系统漏洞剖析

　　从fs0c131y所得出的信息内容而言CVE-2019年-6447危害的ES运用版本号为4.1.9.7.4下列，可是在一些版本号的运用该系统漏洞却没法运用，比如从华为手机和google play店铺免费下载的ES就没法圆满复现该系统漏洞，向59777端口号上传payload始终会回应600 ERROR出错，下边将详尽对该系统漏洞开展剖析。

　　4.1.9.4版本号运用剖析

　　下列是挑选了4.1.9.4版本号的ES文件浏览器开展了剖析，该版本号ES可以取得成功运用该系统漏洞。

　　最先对APK解包后发觉存有3个DEX文档。

　　先简易看过下lib中的库发觉运用沒有加壳，用grep产前筛查下列59777明确有关编码将会在classes2.dex中。

　　把classses2.dex反编译后，全局变量检索command发觉存有系统漏洞的类在Com/estrongs/android/f/a当中,而开启系统漏洞的涵数为Com/estrongs/android/f/a.a。

　　简易看出来a.class,b.class,c.class将会都和该系统漏洞的服务项目有关，在其中a.class承继了c.class。

　　下边看来下全部系统漏洞的开启全过程，因为搞混编码无论是扔进jeb中還是smali阅读文章起來都较为费劲，因此人们可以先动态性的将程序流程跑一面后纪录trace，剖析android trace文档来查询函数调用栈（运用TraceReader载入）。

　　纪录trace的方式给出：

　　在DDMS上取得成功开启Trace以后，人们还要去结构payload去开启该系统漏洞，系统漏洞实际运用payload见github（htpp://github.Com/fs0c131y/ESFileExplorerOpenPortVuln）。

　　curl --header "Content-Type: application/json" --request POST --data "{\"command\":getDeviceInfo}" .com://192.168.13 7.10:59777 -vvv

　　把tracer文档扔到TraceReader查询启用栈，可以发觉程序流程进到Com/estrongs/android/f/c$a.run()V来解决了人们的恳求，留意这儿的类的实例化另一半我觉得是a.class而并不是c.class。：

　　最先接纳socket随后读完buffer中获取统计数据

　　随后分辨是否post统计数据，假如是post恳求则对content-type开展分析，当全部的外置分析进行后最终程序流程会赶到label_189处

　　label_189中，实行了v2_7 = this.a.a_parse_网页地址_other_data(v9, v10, v11, v6, v7);来深化分析并实行相对的command。

　　这儿有个难题，假如JEB立即双击鼠标来追踪涵数会自动跳转到自身类中的涵数，而实际上真实启用的是a.class(Com/Com/estrongs/android/f/a)中的涵数a_parse_网页地址_other_data（这儿我对搞混涵数名重新命名了事实上本来的涵数名是a）。

　　图为是JEB不正确自动跳转到涵数的部位，事实上人们应当剖析的是a.class中的a_parse_网页地址_other_data：

　　再次跟踪下来赶到就赶到了人们刚开始系统漏洞开启的地区（Com/estrongs/android/f/a.a）：

　　有关这一地区的剖析我觉得有许多稿子及其做已过，这儿就已不过多谈及了。

分析相匹配的command启用相匹配的作用涵数后回到json：

　　最终进到Com/estrongs/android/f/c$a.a(Ljava/lang/String;Ljava/lang/String;Ljava/util/Properties;Ljava/io/InputStream;)V将response写回。

　　该涵数将輸出的結果载入到OutputStream中随后将其回到。

　　该ES版本号全部系统漏洞的开启步骤大概就如上如图。

　　这儿有个必须留意的地区，假如是找不到系统漏洞的ES运用v2_7是为null的也就会进到this.a(“600 Internal Server Error”, “SERVER INTERNAL ERROR: Serve() returned a null response.”);中，这都是许多应用商店上的ES运用都是到报600不正确的缘故。

　　4.1.6.6.1版本号运用剖析

　　下列将对4.1.6.6.1版本号ES文件管理器开展剖析，该版本号的ES文件管理器沒有圆满开启系统漏洞。

　　立即curl个看一下，600出错了。

　　拆包静态数据看完，编码大部分還是在f包中，可是多了许多别的的类，a.class仍然是ESHttpServer保持的地区。

　　再curl一个包爬取一下下启用栈。

　　curl --header "Content-Type: application/json" --request POST --data "{\"command\":getDeviceInfo}" .com://192.168.0. 133:59777 -vvv

　　错略核对发觉在这一版本号的ES中多了某些涵数，将会是做了某某些的校检逻辑性。

　　静态数据剖析编码，发觉前边的逻辑性和以前app类似，可是在实行完Com.estrongs.android.f.h.a(Ljava/lang/String;Ljava/util/Properties;)V后又启用了bJ。

　　跟入bJ，bJ认证了网页地址而且ap.a()方式检验当今自然环境是不是处在无线网络自然环境下。

　　再次向下追踪，人们赶到难题点!bp.q() || !f.e(v8)) && !f.a(v8, v2_5)这儿回到了true造成flag_object为null值因此服务器返回了600。

　　bq.q()为true或是f.e及其f.a为true能够进到逻辑性

　　追踪进到bq.q()，要考虑bp.p()和cw.e()都为true。

　　而FexApplication.a().getSystemService(“uimode”).getCurrentModeType() == 4创立的那时候bp.p()能够为true，依据官方网文本文档4的uimode为电商_MODE_TYPE_TELEVISION。

　　在cw.e中必须考虑必须的页面宽度要求

　　boolean v0_1 = Math.sqrt(Math.pow((((double)v0.heightPixels)) * 1 / (((double)v0.densityDpi)), 2) + Math.pow((((double)v0.widthPixels)) * 1 / (((double)v0.densityDpi)), 2)) >= 30 ? true : false;

　　而另一个的f.e(v8)，f.a(v8, v2_5)涵数则承担校检了人们的ip。

　　除此之外存有另一个这种状况是当你的ip为127.0.0.1那时候flag_object能不以null，但最先你可以考虑v4=null这一先觉标准。

　　查询v4 = as.bJ(v9)，以前早已说过bJ涵数承担校检了网页地址，人们再再次返回bJ发觉return null仿佛不大可能，v9无论uri怎样结构都是以’/刚开始。

　　换句话说在应用商店上的ES版本号无论是走if((!bp.q() || !f.e(v8)) && !f.a(v8, v2_5))還是走if(v4 != null && as.I(v4) != 0)好像都不可以去往到flag_object = v8_1.a(v9, v10, v11, v6, v7)的逻辑性，那样该系统漏洞就无法开启，但或许也有别的的绕开方式，期待大伙儿可以多多的填补。

　　资料可参考

　　htpp://WWW.chainnews.Com/articles/873565939043..asp

　　htpp://WWW.52pojie.Cn/thread-856993-1-1.html语言

　　htpp://blog.csdn.net/caiqiiqi/article/details/86558862

　　htpp://bbs.ichunqiu.Com/thread-496