A failed app business penetration test

Whoamiecho

Source: Ichunqiu

This article participates in I Spring and Autumn Community original article reward plan, without permission prohibition reprint!
I. Process
1.1. Cause: Brute Force
The test is given to a regular user account and can be logged in. The app will be landing, encounter this situation can only catch a landing packet to see what is the situation, the landing when the data packet crawl is as follows:

The verification code is verified locally and is not sent to the server. That's good to do, apart first Test.

Demolition of a half-day and no blasting site can log on users. After a while found that the user name into the quotation marks when actually error. Such a situation is either intercepted or injected. Unfortunately the latter. It seems that after the demolition of the dictionary inside to bring in a few commonly used fuzzing statements ah.
Login point Injection First try the universal password. The results failed to log in, only to go into the path to take the password. Let's take a look at the injection point:

get/appbusi/login.jsp?jsoncallback=jquery16407473715976811945_1478502187123&logincode=admin ' & loginpass=111111&pf=1&_=1478502216927 http/1.1
Host: *.*.*.*:*

Add a single quote test after the Logincode field to find an error.

Use Sqlmap to inject the Logincode parameter into the test:
Sqlmap.py-r C:\users\echo\appdata\local\temp\\1478502827550.req–dbs

Get many databases:

Find the Administrator table for the current database, and when I see 1762 tables, my legs are soft. I still pretended to find the next, not found. Mechanism of the administrator will be several sites of the database are placed in this, what OA system, BBS ah. Mushrooms!

Can't sit like this. Log in with the normal test user first to see what the situation is. A bit of a crazy grab bag test. The server does really suck, a bunch of SQL injections, XSS. The rest is not much to say.



1.2, focus on-Any file download vulnerability

In order to see what the app has, open fidder a crazy point, grabbed all the bags, one by one look, when I see this package, my mouth slightly rose 45 degrees.
Http://*.*.*.*:*/appbusi/flow/sat_down.jsp?filepath=e:/apache-tomcat-6.0.41/webapps/jxzmcc/files/satflow27/ 9d102ebd32dca338053c49ea1d015b37.txt
Obvious arbitrary file download vulnerability, and an absolute path is also included.

Construct link Download website source code:
Http://*.*.*.*:*/appbusi/flow/sat_down.jsp?filepath=e:/apache-tomcat-6.0.41/webapps/jxzmcc/index.jsp

Hint is a background management. Access to Http://*.*.*.*:*/jxzmcc/index.jsp discovery cannot be accessed. Guess these things:
1: The access port is not correct.
2: Websites can only be accessed by apps.
3: In the intranet.

First use Nmap to sweep the port to see what some external services: Nmap-vv-p 1-65535 *.*.*.*

Discover the only 8080 ports that can be accessed or forwarded by the agent. Prove the website inside the net. Now you can only download the file to find something else. The first thing to think about is to download Web.xml,server.xml, Tomcat-users.xml. But WTF, the administrator really is too lazy, incredibly have not configured.
In order to prove that the site in the intranet, think can download HTTP access logs. So I looked at the format of the local Tomcat log store:

Construct a good file name: Localhost_access_log.2016-10-31.txt. Access:
Http://*.*.*.*:*/appbusi/flow/sat_down.jsp?filepath=e:/apache-tomcat-6.0.41/logs/localhost_access_ Log.2016-10-31.txt.

Not expected, access is from the intranet. Download a few more logs, are the same situation. It seems that this station is not to be taken, I thought here will be the end.

1.3, the transfer appears
Suddenly think of the previous app error when the Tomcat version is not 6.0.41, and here Download the version of the site is 6.0.41. This station is not in the directory of the app interface station at all.
Http://*.*.*.*:*/appbusi/login.jsp121212 Error Displays the middleware version information by accessing a link that does not exist. tomcat/7.0.54

If the installation directory of the two Tomcat is the same, the e:/apache-tomcat-7.0.54/directory should be present, and the other is constructed with a tried-and-true attitude:
Http://*.*.*.*:*/appbusi/flow/sat_down.jsp?filepath=e:/apache-tomcat-7.0.54/logs/localhost_access_ Log.2016-10-31.txt
The miracle happened. I admire myself, seemingly see through the routines of the administrator. There are three things found in the log:
An external management background: Http://*.*.*.*:*/jxc/login.jsp

Current app interface: Http://*.*.*.*:*//appbusi/login.jsp
Another app interface: Http://*.*.*.*:*//jxzxapp/xtgl/login.jsp


1.4, Accidental harvest-Background login password to retrieve the vulnerability
If you can choose the app or the web I will try the Web site first. Is the management of the background no verification code, and tried to burst, each request is 302 jump, blasting failure.


Luck really doesn't work. There is nothing to inject. Shencanzhijian I did not miss a link, click on the "Get password".

The website prompt did not find the Admin user's phone number.

Fill in your phone number and contract with local element debugging.

Grab Bag:


I'm tired of hurting my brother. See the password in the second packet: S3M1KZ

Successfully logged in backstage with dynamic password.

But there's no luan to use. There are no functions in the background. Getshll failed.


1.5, the last struggle


In the heart of the case, look for another app to find the interface situation. The first thing to think about is what the app is, see if there's a breakthrough, and find out that the app and the app are basically the same. Looks like it's over. An unauthorized access to an upload point was also found in the log:

Visit: Http://*.*.*.*:*//jxzxapp/gdsl/upload1.jsp

No matter what you upload the box, upload failed. The road is dead. SQL injection also failed to find the backend landing address, compared to a futile. Oracle has DBA authority, but fails to getshell directly.

two. A young lady (knot)
A few things to say:
1:jsp Any file download does not contain files like PHP. To take advantage of the current better way is to download the middleware configuration files, log files. Liunx words can try to download/ect/passwd and so on.
2: Information disclosure is still useful from finding the tomcat/7.0.54 version to determine the directory exists, thereby widening the attack surface.
3: Recover password, brute force sometimes can have unexpected harvest.

More security technology, good quality, white hat hack big guy in: http://bbs.ichunqiu.com/portal.php

A failed app business penetration test