Analysis of ES File Explorer Security Vulnerability(CVE-2019-6447)

• Z时代
• 2024-01-10
• 分类：IT

Author: 0x7F@Knownsec 404 Team

Chinese Version: https://paper.seebug.org/831/

0x00 Preface

ES File Explorer is a file manager application on Android, which supports functions such as skimming through and managing files. It has over 100 million installations, and is the most popular file manager application on Android.

In Jan. 2019, a security researcher released a security vulnerability in ES File Explorer (CVE-2019-6447).

Late in February, I read some articles related to this vulnerability and decided to learn reverse engineering on Android application, and I made a recurrence analysis of this vulnerability. Relating it to published analyses, I found its principle quite easy. So let's find out.

0x01 Vulnerability overview

The ES file browser creates an HTTP service bound to port 59777 at runtime, which provides 10+ commands for accessing data in user's cell phone and executing the application; however, the service does not check this request. Test, resulting in a security breach.

Influence Spectrum:

ES File Explorer v4.1.9.7.4

Repairing Methods:

Download the newest version on application mall. Version repairs this vulnerability is v4.1.9.7.4

Vulnerability Recurrence Environment:

• Windows 7
• OPPO R7
• ES File Explorer v4.1.9.4
• ADB (Android Debug Bridge)

0x02 Vulnerability Recurrence

1. Connect a mobile phone with a computer, and turn on USB debugging.

   

2. Check device connectivity via ADB, and install the ES file browser v4.1.9.4 onto the device.

   

3. On the mobile phone, you can see that the ES file browser has been successfully installed. Start the application. By viewing the current network port status through ADB, you can see that the port 59777 is open.

   

4. Configure the phone and computer to the same WIFI to conduct access tests.

   

5. Constructs an HTTP data packet, encapsulates the command into Json data, and requests for port 59777. Here, the getDeviceInfo command is displayed, and you can see that the device information was successfully returned.

   

0x03 Vulnerability analysis

Decompile dex file

Analyze the ES file browser v4.1.9.4. First extract the APK, you can see that it contains three *.dex files. Decompile these three files with dex2jar tool to get three *.jar files.

Use the jd-gui tool to load these three jar files. Search 59777, command, getDeviceInfo with keywords to quickly locate the logic vulnerability part, which is located at classes2-dex2jar.jar under path com.espans.android.f.a.

Commands ES HTTP Supports

In the figure above, you can see that in addition to the getDeviceInfo command, the HTTP service supports a lot of other commands:

In addition to the commands listed above, you can also directly access the url + system file path to access the file data:

curl --header "Content-Type: application/json" http://192.168.0.105:59777/etc/wifi_mos.sh

Command execution example (listing all files):

curl --header "Content-Type: application/json" --request POST --data "{\"command\":\"listFiles\"}" http://192.168.0.105:59777

Command processing

The command processing is roughly to perform the corresponding logic processing, encapsulate the result of the execution into Json data format, splice these Json data and return them as HTTP protocols. The following is the logic processing of getDeviceInfo:

As can be seen from the above function, the HTTP service is a built-in function of the ES file browser, which is used probably for sharing between different devices, but the security problem arises because the request is not verified.

0x04 Patch Analysis

Download the patched version v4.1.9.9.3, unpack the APK, decompile it into a *.jar file with dex2jar, and analyze the file.

POST request verification

The v4.1.9.9.3 version may have been obfuscated, and its decompiled organization is very different from v4.1.9.4; we still use keyword search to quickly locate the previous logic vulnerability. It is located under the es.qg path under classes3-dex2jar.jar.

As you can see from the above figure, the label is the patch added by the new version. When the request is to be processed, it will be checked first, and if the check fails, a 400 error is returned.

If we look into the ap.d() function, we will see two key functions:

1.Function 1

This function gets the UIModeManager object. When the type of the object is equal to 4, it returns true. By consulting the official document, the value corresponding to the value 4 is UI_MODE_TYPE_TELEVISION, which is the type of Android TV. This mean the official limited this feature to Android TV devices.

2.Function 2

Function 2 still checks whether it is Android TV. In the previous step, Function 1 gets the size of the screen and converted it into a value, and in Function 2 the value had to be greater than 20 to return true.

The Android TV will be threatened?

Based on the above patch, it seems that Android TV is threatened by this vulnerability, but it is not. Because the process flow of Android TV is different from the mobile version, it will not be affected by this vulnerability.

Install the vulnerable version (v4.1.9.4) on Android TV; we can see that launching a request under Android TV will directly return a 500 error.

The reason is that when the program judges whether the device is a TV, it will first perform a source IP check in advance (to determine whether it is a locally initiated request, and return a 500 error even though the check fails), and then check the accessible path using functions following (Classes3-dex2jar.jar/es.qj$a):

But after testing, I found that the value of the array is NULL, and the function directly returned false.

Eventually the program jumped to this statement and it return a 500 error. So Android TV will not be affected by this vulnerability.

Get Request Column Directory Repair

It is also mentioned above that sending a GET request can list files, and the new version has also been fixed.

When the request is initiated in GET mode, it will enter the ai.bK() function. In this function, HTTP can return to file list only if it started with http://127.0.0.1. But all HTTP protocols start with GET/POST/... and they certainly do not start with that. Although I did not quite understand this check, it solved the problem of listing directories.

0x05 Summary

Through the above analysis, we can get the whole picture of how the ES file browser security vulnerability is triggered and its patches. The main reason was that the developer ignored the check of the request when designing the shared access function, resulting in security vulnerabilities.

References:

• Github: https://github.com/fs0c131y/ESFileExplorerOpenPortVuln
• Twitter: https://twitter.com/fs0c131y/status/1085460755313508352
• techcrunch: https://techcrunch.com/2019/01/16/android-app-es-file-explorer-expose-data/
• Freebuf: https://www.freebuf.com/vuls/195069.html
• smwenku: https://www.smwenku.com/a/5c45ee68bd9eee35b21ef1db/zh-cn

About Knownsec & 404 Team

Beijing Knownsec Information Technology Co., Ltd. was established by a group of high-profile international security experts. It has over a hundred frontier security talents nationwide as the core security research team to provide long-term internationally advanced network security solutions for the government and enterprises.

Knownsec's specialties include network attack and defense integrated technologies and product R&D under new situations. It provides visualization solutions that meet the world-class security technology standards and enhances the security monitoring, alarm and defense abilities of customer networks with its industry-leading capabilities in cloud computing and big data processing. The company's technical strength is spanly recognized by the State Ministry of Public Security, the Central Government Procurement Center, the Ministry of Industry and Information Technology (MIIT), China National Vulnerability Database of Information Security (CNNVD), the Central Bank, the Hong Kong Jockey Club, Microsoft, Zhejiang Satellite TV and other well-known clients.

404 Team, the core security team of Knownsec, is dedicated to the research of security vulnerability and offensive and defensive technology in the fields of Web, IoT, industrial control, blockchain, etc. 404 team has submitted vulnerability research to many well-known vendors such as Microsoft, Apple, Adobe, Tencent, Alibaba, Baidu, etc. And has received a high reputation in the industry.

The most well-known sharing of Knownsec 404 Team includes: KCon Hacking Conference, Seebug Vulnerability Database and ZoomEye Cyberspace Search Engine.

以上是 Analysis of ES File Explorer Security Vulnerability(CVE-2019-6447) 的全部内容， 来源链接： utcz.com/p/199353.html