Shulou(Shulou.com)05/31 Report--

ES file browser CVE-2019-6447 vulnerability analysis is how, many novices are not very clear about this, in order to help you solve this problem, the following editor will explain in detail for you, people with this need can come to learn, I hope you can gain something.

Vulnerability name

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

Brief introduction of vulnerabilities

The ES file browser creates a HTTP server when it starts, opening port 59777 locally. Attackers can obtain users' mobile phone files, install apk and other operations by constructing a specified payload.

Scope of influence

4.1.9.7.4 and below (some versions may not support it, or it may be related to the application market)

Loophole analysis

According to the information given by fs0c131y, the version of ES applications affected by CVE-2019-6447 is less than 4.1.9.7.4, but this vulnerability cannot be exploited in some versions. For example, ES downloaded from Huawei and google play stores cannot successfully reproduce the vulnerability. Sending payload to port 59777 will always reply to a 500ERROR error. The vulnerability will be analyzed in detail below.

Application Analysis of version 4.1.9.4

The following is a selection of version 4.1.9.4 of the ES file browser for analysis, this version of ES can successfully exploit this vulnerability.

First of all, after unpacking APK, it is found that there are three DEX files.

First, take a brief look at the library in lib and find that the application is not shelled. Use grep to screen the following 59777 to determine that the relevant code may be in classes2.dex.

After decompiling the classses2.dex, a global search for command finds that the vulnerable class is in com/estrongs/android/f/a, and the function that triggers the vulnerability is com/estrongs/android/f/a.a.

In a nutshell, a. Classreb. Classrec. Class may be related to the service of this vulnerability, where a.class inherits c.class.

Let's take a look at the whole trigger process of the vulnerability. because the obfuscation code is difficult to read no matter it is thrown into jeb or smali, we can dynamically run the program aside and record trace, analyze the android trace file to view the function call stack (read by TraceReader).

The method to record trace is as follows:

After successfully opening Trace on DDMS, we need to construct payload to trigger the vulnerability. For more information on how to exploit payload, see github (https://github.com/fs0c131y/ESFileExplorerOpenPortVuln).

Curl-- header "Content-Type: application/json"-- request POST-- data "{\" command\ ": getDeviceInfo}" http://192.168.13 7.10 VR 59777-vvv

Throwing the tracer file onto the TraceReader call stack shows that the program enters com/estrongs/android/f/c$a.run () V to process our request. Notice that the instantiated object of the class here is actually a.class rather than c.class. :

First accept socket and then read to buffer to extract data

Then determine whether it is post data, and if it is a post request, parse the content-type. When all the pre-parsing is completed, the last program will come to label_189.

In label_189, v2x7 = this.a.a_parse_url_other_data (v9, v10, v11, v6, v7); is executed to further parse and execute the corresponding command.

There is a problem here: if JEB directly double-clicks to track the function, it jumps to the function in its own class, and what is actually called is the function a_parse_url_other_data in a.class (com/com/estrongs/android/f/a) (here I renamed the confusion function name is actually a).

The following figure shows where the JEB error jumps to the function. In fact, we should analyze the a_parse_url_other_data in a.class:

As we continue to trace it, we come to the com/estrongs/android/f/a.a where the vulnerability was triggered in the first place:

As a matter of fact, there are many articles and works on the analysis of this place, so I won't mention it too much here.

Json is returned after parsing the corresponding command calling the corresponding function:

Finally, enter com/estrongs/android/f/c$a.a (Ljava/lang/String;Ljava/lang/String;Ljava/util/Properties;Ljava/io/InputStream;) V and write response back.

This function writes the output to OutputStream and returns it.

The trigger process for the entire vulnerability in this version of ES is roughly as shown above.

One thing to note here is that if there are no vulnerabilities in ES applications, v2x7 is for null, then it will enter this.a ("500Internal Server Error", "SERVER INTERNAL ERROR: Serve () returned a null response.");, which is why many ES applications in the application market report 500errors.

Application Analysis of version 4.1.6.6.1

The following is an analysis of version 4.1.6.6.1 of the ES File Manager, which did not successfully trigger the vulnerability.

Take a look at curl directly, 500 wrong report.

Take a static look at the unpacking and see that the code is basically still in the f package, but with a lot of other classes, a.class is still where ESHttpServer is implemented.

Curl another package to grab the call stack.

Curl-header "Content-Type: application/json"-request POST-data "{\" command\ ": getDeviceInfo}" http://192.168.0. 122PUR 59777-vvv

Misalignment found that there are some more functions in this version of ES, which may be due to some check logic.

Static analysis of the code shows that the previous logic is similar to the previous app, but bJ is called after the execution of com.estrongs.android.f.h.a (Ljava/lang/String;Ljava/util/Properties;) V.

Following the bJ,bJ verifies the url and the ap.a () method detects whether the current environment is in the WIFI environment.

As we continue to trace down, we come to the problem point! bp.q () | |! f.e (v8)) & &! f.a (v8, v2: 5) where true is returned and flag_object is null, so the server returns 500.

Bq.q () is true or f.e and f.an is true to enter logic

Trace into bq.q (), satisfying that both bp.p () and cw.e () are true.

Bp.p () can only be true when FexApplication.a (). GetSystemService ("uimode"). GetCurrentModeType () = = 4 is established, and the uimode according to official document 4 is UI_MODE_TYPE_TELEVISION.

It is necessary to meet certain requirements of interface length and width in cw.e.

Boolean v0room1 = Math.sqrt (Math.pow (double) v0.heightPixels)) * 1 / ((double) v0.densityDpi)), 2) + Math.pow (double) v0.widthPixels)) * 1 / ((double) v0.densityDpi), 2)) > = 20? True: false

The other functions, f.e (v8), f.a (v8, v2q5), are responsible for verifying our ip.

In addition, there is another situation where flag_object can not be null when our ip is 127.0.0.1, but first you have to meet the premonition condition of v4=null.

Look at v4 = as.bJ (v9). It has been said before that the bJ function is responsible for verifying url. When we go back to bJ, we find that return null seems unlikely. No matter how the uri is constructed, v9 will start with'/'.

In other words, the ES version in the application market, whether it follows the logic of if ((! bp.q () | |! f.e (v8)) & & f.a (v8, v2room5)) or if (v4! = null & & as.I (v4)! = 0), does not seem to be able to proceed to the logic of flag_object = v8room1.a (v9, v10, v11, v6, v7), so the vulnerability cannot be triggered, but there may be other ways to bypass it. I hope you can add more.

Is it helpful for you to read the above content? If you want to know more about the relevant knowledge or read more related articles, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.