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

This article will explain in detail how the dynamic analysis of any file upload vulnerability in two places of LOGY is. The content of the article is of high quality. Therefore, Xiaobian shares it with you for reference. I hope that after reading this article, you will have a certain understanding of relevant knowledge.

0x01 Preface

CNCERT announced a few days ago that it found a remote upload vulnerability in Oracle's JavaEE structure-based middleware product, which was confirmed by the manufacturer and scored 9.8 points. Since the manufacturer has carried out security fixes, the author conducted an analysis of the vulnerability.

There is an arbitrary upload getshell vulnerability in two unauthorized pages on the WebLogic management side, which can directly obtain permissions. The two pages are/ws_utc/initi.do,/ws_utc/config.do respectively; the scope of vulnerability Oracle Logic Server, versions 10.3.6.0, 12.1.3.0, 12.2.1.2, 12.2.1.3; related links: http://www.oracle.com/technetwork/security-advisory/cpujul2018-4258247.html#AppendixFMW, the author starts from these two files to find out the principle and location of vulnerability generation.

0x02 Introduction and Principle

The author first visited config.do and modified the default directory WSTestPageWorkDir to user_projects\domains\base_domain\tmp\sd\as shown below:

When a new directory is set up on the workbench, weblogic will move subdirectories and files from the original directory to the new directory, but the old directory will remain. Because it is not the point, the author's analysis of this piece is skipped. The author simply draws a sketch from the attacker's dimension. Initially, the attacker must configure the working directory, because the default working directory is unreachable when accessing the URL. Then the attacker considers whether to upload the keystore file from the config.do page or upload it from the begin.do page. In the end, it is successful to upload the pony, but the access format and path of the pony are different. As shown below:

If you want to thoroughly understand the process of weblogic vulnerability generation from the principle, you need to look at the following figure. After the attacker starts the attack, Weblogic makes a lot of judgments on the server side. If a new working directory is set, then the program will automatically copy all the subdirectories and files under the old directory to the new setting directory, and set the new directory as the working directory. If the attacker uploads through Begin. Do, Weblogic will judge whether there is an upload directory on the server side. If there is no automatic creation, then create Rs_Upload_formatted as the directory name in the upload directory, and then get the import_file_name field name as part of the subsequent file name concatenation; if you upload via config.do, get the timestamp parameter in the GET request as part of the file name of the subsequent webshell, or see the following figure:

0x03 Begin.do page upload vulnerability

First set up a good Logic environment in the IDE, run the application and click the folder button at the top right of the page, where an import function is implemented.

Select any file to upload, I choose to upload jsp file:

Grab the data packet and you can see that the address where the upload vulnerability really exists is:

http://IP:7001/ws_utc/resources/ws/config/import? timestamp=1532403983779

Because it is vulnerability reproduction and analysis, the author grabbed the data packet while uploading, and got the HTTP in the figure below:

This is nothing more than a simple upload stream, the form fields import_file_name are key values, and detecting them is one of the key features from a product defense perspective.

Next, you need to dynamically locate the trigger point of the vulnerability in the IDE, because most of the vulnerabilities in weblogic are associated with the T3 protocol. According to the debugging breakpoint located by the weblogic vulnerability analyzed earlier, it is in the com.bea.core.weblogic.rmi.client_4.0.0.jar package. After debugging for many times, you jump step by step to the core package triggered by the vulnerability.

And found the corresponding trigger vulnerability class location: \com\oracle\webservices\testclient\ws\util\RSDataHelper.class

Locate the method convertFormDataMultiPart, code as follows:

The code checks whether there is an upload directory in the current working directory, and if there is no upload directory, create it, and call the cleanObsoleteFile method to force all files in the directory to traverse once, and delete the files if they are found. The debugging process is as follows:

A directory with a formatted time beginning with the string Rs_Upload_is created and saved as a directory for uploading files.

Next, the program obtains the form-data of the uploaded form, and obtains all the form fields and corresponding values through loop traversal. The data is stored in two pieces, one in the kvMap collection, and the obtained attachments are saved to disk through the saveAttacheFile method. The code is as follows:

The red circle in the figure below is the physical pathname after splicing:

Then trace the debugging to the execute method, which is located in the ImportTestCaseAction.class class. The actual path is: \user_projects\domains\base_domain\servers\AdminServer\tmp\_WL_internal\com.oracle.webservices.wls.ws-testclient-app-wls_12.1.3\cmprq0\war\WEB-INF\lib\ws-testpage-impl.jar!\ com\oracle\webservices\testclient\ws\action\ImportTestCaseAction.class

Because the file format and data imported by the author are not processed by weblogic, the program throws a null pointer exception error at the context.createUnmarshaller method, which causes the status code of the Response to be 500 after successful upload, which can also be used as one of the characteristics of defensive product detection. Dynamic debugging exceptions are shown as follows:

An arbitrary file upload vulnerability caused by unauthorized access to this Begin. Do page is already apparent, and defensive policies can detect form fields

0x04 config.do page upload vulnerability

After visiting config.do page, click the "Security" menu on the left side, add a Keystore, arbitrarily set the name and password, of course, the file is also uploaded in any format, which is really arbitrary here.

After clicking Submit, grab the trigger address: http://IP/ws_utc/resources/setting/keystore? timestamp=1532400069848 ; the captured packages are as follows

As with the previous routine, IDE debugging is enabled when uploading. After breakpoint, locate RSDataHelper.class file, as shown below.

The form field obtained this time is ks_filename, which is worth collecting and added to the category of feature detection; then follow up and see the key shell generation step.

The uploaded shell is located in/config/keystore/directory under the workbench configuration directory. The format of the file name is relatively simple. It uses the timestamp value carried on the URL address in the POST request and the filename spliced by underscores. What makes the author surprised is that weblogic, as a well-known software provider, has such a low-level vulnerability. Coupled with a series of deserialization bypass vulnerabilities, it can only be said that weblogic products can be used without using them. It is better to use them less.

0x05 Defensive measures

1. Set Config.do and Begin. Do pages to be accessed after login authorization;

2. IPS and other defense products can add corresponding features;

3. Upgrade to the latest official version.

About the two arbitrary file upload vulnerability dynamic analysis is how to share here, I hope the above content can have some help for everyone, you can learn more knowledge. If you think the article is good, you can share it so that more people can see it.

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.