Jump to content

Title: Remember a security test for a client

Featured Replies

Posted

0x00 Cause

The project received this time is to conduct security tests on a certain client. In addition to occasionally testing apps, most of the testing goals were mainly based on B/S architecture Web. This is the first time to test a client of C/S architecture, so I was also distorted and could only follow the conventional ideas of testing the web.

0x01 Catch the packet

First check whether the target client has proxy configuration function (mostly do not) 1049983-20220112165300525-811630463.png

You can see that there is only a simple login function and no proxy configuration function.

Proxifier + BurpSuite

View the proxy address and port configured in BurpSuite 1049983-20220112165301160-1350397900.png

Add a proxy server in Proxifier (ip and port are the proxy addresses and ports configured in BurpSuite) 1049983-20220112165301716-1441305015.png

After configuration, check and test connectivity with BurpSuite (there is traffic in BurpSuite that is successful communication) 1049983-20220112165302269-1798238801.png

Add proxy rules in Proxifier 1049983-20220112165302895-1418935946.png

BurpSuite successfully intercepts the client's login request 1049983-20220112165303584-270157212.png

0x02 Packet Analysis

After successfully intercepting the data packet, he planned to analyze it. The result was desperate at first glance. Both the request packet and the response packet were encrypted 1049983-20220112165304516-19916912.png 1049983-20220112165305262-348139652.png

Try Web Access

When testing the app, I encountered a situation where the mobile phone traffic was encrypted but the PC was not encrypted. So I copied the request link to try to access the web, but did not get valid information 1049983-20220112165306029-925588883.png

Since the request parameters of related functions in this client are transmitted in POST mode and the traffic is encrypted, it is temporarily abandoned and changed its thinking to start from the server.

0x03 The dark willows and bright flowers

WebSphere scans the target server and found that there are quite a lot of open ports. 9043 and 9060 are the default management console security ports and management console ports of WebSphere respectively.

The default login address is /ibm/console, here the default user ID is admin successfully logged in 1049983-20220112165307024-536088840.png

Twist and twists

Replace jsp file content

It is natural to successfully enter the WebSphere management console and get the shell, but things are not as easy as I imagined. First, use the war package I made before to upload 1049983-20220112165307550-894715545.png

Select the war package, fill in the context and report an error 1049983-20220112165308151-1929645713.png

Regarding this error, I searched the Internet for a long time and finally summarized several reasons and solutions, namely, restarting WebSphere, the file contents contained in the war package are incorrect, the jdk used when typing the war package is inconsistent with the jdk version of the target WebSphere, and modifying some WebSphere configuration files.

Modify the jsp file content in the war package to print string (harmless content), repackage and upload, and still report an error

Replace jdk version

From the data packet captured above, we can see that the jdk version used by the target is 1.5.0_21, so download the corresponding version of jdk and use the jar command to upload the harmless jsp file and then upload it, and still report an error 1049983-20220112165309237-224143831.png 1049983-20220112165310203-1987621632.png

Myeclipse constructs war file

Through many previous attempts, this error was not resolved, so I was stuck in this step for a long time. Finally, I learned from the information that the default supported web application in WebSphere 6.x version is 2.3 (web-app_2_3.dtd configured in web.xml), so I chose to use Myeclipse to generate the war file.

Myeclipse Create a new web project. Put the jsp file in the WebRoot directory and export the project as a war file 1049983-20220112165311490-623774130.png 1049983-20220112165312230-288898744.png

The generated war file directory structure is as follows 1049983-20220112165312720-1805505908.png

Select the generated war file and fill in the context to upload 1049983-20220112165313199-902598587.png

Step 1-4 No operation is required, click Next Step 5 After clicking to complete, remember to select Save to main configuration 1049983-20220112165313745-1109284724.png

After the installation is completed, the application status is stopped. Click Start to start successfully 1049983-20220112165314266-401746263.png 1049983-20220112165314657-1887140362.png 1049983-20220112165315061-470388678.png

0x04 Summary

The jsp file needs to be used to generate webshell from Godzilla. It is just starting to use the horse generated by Behinder v3.11. Although it can be uploaded successfully, it will prompt that the page exists and the key cannot be obtained. It is speculated that it may be related to the target jdk version being too low, and the specific reason is unknown.

1. First set the proxy ports of bp and proxififter to 127.0.0.1 8081 respectively, and add the software of the target customer service to proxififter and capture it.

, found that the post packet transmitted by the target has been encrypted, and the displayed JDK is 1.5.0-21.

2. Scan the IP of the customer service software to port and find that 9043, 9060 and WebSphere service ports are opened.

3. Access the WebSphere backend (/ibm/console), enter the user name admin/admin to enter the system, and the version is 6.x

4. Here, through a sentence Trojan generated by Godzilla, it is made into a war package (from application - enterprise application - installation - path to new application - local file system - select WAr package)

5. Uploading WAR packages shows an error. The reasons for the error are as follows:

Need to restart WebSphere

The file contents contained in the war package are incorrect and need to be modified.

The jdk used when using the war package is inconsistent with the jdk version of the target WebSphere

Modify some WebSphere configuration files

5. Install jdk1.5 version locally here, then modify the war package through the jar command and upload the waf package. I found that it still cannot run

jar -cvf time.war time.jsp

6. The default supported web application in WebSphere 6.x version is 2.3 (web-app_2_3.dtd configured in web.xml), so choose to use Myeclipse to generate the war file:

new --web project-project name(getshell)-Drag the Godzilla generation sentence into the getshell project. Then export export-

java EE --war file --export getshell.war package

7.getshell.war package can be uploaded directly

(From the application - Enterprise application - Install - Path to the new application - Local file system - Select the WAr package, and the context root (test directory))

8. Then save the configuration and start.

Final visit:

http://www.xxx.com/test/getshell.jsp

Original link: https://xz.aliyun.com/t/10253

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

Important Information

HackTeam Cookie PolicyWe have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.