Whole Process Tracking intrusion into JSP website servers

E-commerce websites made with JSP are like a haomu. But can JSP websites be securely secured? In the face of endless hacker and virus attacks, can JSP website servers be more secure than those of other websites? Some time ago, at the invitation of a friend, I tested the hosts of the three servers they hosted and found several problems with the JSP website.

Intrusion test Step 1: Scan

Scanning is the first step of intrusion. It gives you a comprehensive understanding of the target to be intruded. At the same time, scanning may also detect vulnerabilities in scanning objects, providing guidance for intrusion.

A friend's two servers are Linux, one is windows, and there is a Cisco PIX 525 behind the router to protect the three hosts, only allowing external users to connect some ports of different hosts, for example, 110.

According to the detection, the filtering rules of the Cisco PIX Firewall are strictly set. Basically, there are no redundant ports to allow access by external users. After careful analysis, I found that the host of the target network provides external access through address translation and uses the 192. 168. *. * address segment internally.

If you don't consider that much, find a scan software to check the security of the host. I found X-scan. After scanning the ports of these hosts externally, I generated a report about the ports. I found that there was a Tomcat server, the explanation is the JSP file.

TIPS:

Tomcat web server is an open-source free network server suitable for various platforms. Well-known websites such as ebay.com and Dell computers use or use Tomcat's container to execute Servlet and JSP.

It seems that only web services can be used for indirect attacks. First, check the TCP port 80 service. I found that the news search function is provided by port 8080. Enter http: // 202. 103. *. after 168: 8080/, A System Management logon page is displayed. After a simple test, enter "test/test" as the "user name/password". It seems that the authentication is successful, however, you cannot enter the next page.

Expert tips: for scanning, it can easily expose the weakness of our website. To cope with the scanning, we can set up a honeypot to mislead the scanner. The honeypot can make the system pretend to be a loophole everywhere, so as to mask the real vulnerability, or disguise it as no vulnerability, let intruders do not know where to start.

Step 2 of intrusion testing: vulnerability attempts

Try various known vulnerabilities in JSP. This is a method that is forced to use when the scan results cannot obtain any valid information to guide the intrusion. Although the effect of this method is not necessarily good, it can often achieve unexpected results, so that the intrusion can continue.

I tested the JSP case sensitivity. Because JSP is case sensitive, Tomcat only treats the file with the lower-case JSP suffix as a normal JSP file, if it is written in uppercase, Tomcat will change the index. JSP is a downloadable file for customers to download. After several tests, I found this method does not work. Maybe the Administrator has downloaded the latest patch on the server software website.

I found that most JSP applications have a WEB-INF directory under the current directory, which usually stores the class file compiled by ans. If you do not set normal permissions for this directory, all the classes will be exposed.

After the downloaded class file is decompiled using the Jad software, the original Java file and even the variable name will not change. If the Web Page Maker starts to write the database username and password in the Java code and decompile the code, it may be able to see important information about the database. So how can we get these files?

The default "/admin" Directory of Tomcat is easy to access. Enter http: // 202. 103. *. 168/admin/. The Administrator directory is in the column. By default, "User Name" should be admin, and "password" should be blank. after entering the user and password, click "login" to enter, several common passwords have been used one after another, which does not help.

By default, Tomcat enables directory browsing, which is easily overlooked by administrators. That is to say, when the required resources are directly mapped to a directory on the server, the default index is missing in the directory. for JSP files, Tomcat will not return the 404 error that cannot find the resource, but will return the directory list in HTML format.

After thinking about this, I opened the report file generated after scanning with X-scan, found the "Security Vulnerabilities and Solutions" column, and saw several directories that may have CGI vulnerabilities. Enter one of them in the address bar. Some typical JSP files and JS files are listed. In general, right-click a file and select "Download all links with flashget". As a result, all files in this directory are downloaded to the local device.

The most valuable one is dbconn. for JS files, it seems that the program designer has written some database connection passwords and connection addresses in it for convenience and convenience (this is a problem that many developers may ignore ). However, I am most concerned about the Tomcat administrator password.

After simple cracking, we found that the admin user in the Tomcat System uses a very simple password: web123456. With this password, the following work is relatively simple.

Expert tips: For website vulnerabilities, we need to immediately install various patches and then strengthen several known security vulnerabilities. For example, we can modify the "/admin" directory, make it difficult for intruders to find management paths. Disable Tomcat's directory browsing function to make the attacker's vulnerability attempt completely fail.

Step 3 of intrusion testing: injection attacks

Many websites do not have injection prevention measures in place. injection attacks can expose the website's database information so as to expose the Administrator account and password in the database table.

Log on to the Tomcat Management page again and click the "context (Admin)" link to list the names of some files and directories under the web directory. Now you can manage the Tomcat context, for example, view, add, and delete context.

Back to the Tomcat management field, I found a file upload component and the website has a forum. Therefore, I wrote an input. jsp file and used it as a general web application, and uploaded it to the other party's web directory through the uploaded components. Open the input. jsp page. The webpage does not perform any input verification on the query form, but the form for the user name will. Enter the data in the form to test the web page vulnerability, for example:

(1) Fill in the search field alert (document. Cookie) to display the cookie of the process with XSS.

(2) enter the search field to demonstrate HTML injection attacks.

Through these methods, I got some forum user information. Of course, these are all tests for JSP to verify all input fields in the Web application. What should I do if I have user information but no password? During login, I found a port 8888. What service will this be?

Expert tips: in the design of connecting websites to databases, webpage designers should add a review mechanism for some sensitive symbols to shield some symbols that are useful in the database, this can successfully defend against injection attacks to a large extent.

Step 4: Attack its weakness"

According to the gradual deepening of intrusion, the security problems in the system are gradually becoming clearer. The following is an attack on the website's security "weakness. Generally, attacks targeting security vulnerabilities can cause intrusion.

After opening the address, I found that this port is running Apache + PHP. That is to say, this host can also compile PHP. From the empirical analysis, the main purpose of the Administrator to install PHP on the JSP host simultaneously may be to manage the MySQL database. Therefore, this port may include the MySQL database management software phpMyAdmin. Will there be a database management directory on this port?

As expected, after entering this directory, I found that I entered a phpMyAdmin management interface to perform any operations on the MySQL database. It supports reading or writing data from the local operating system. What's even more incomprehensible is that the Administrator wrote the data in the database link with the root account and couldn't control the database.

Open a database and enter "select * From 'administer '" in "SQL". All the data in the administer table is displayed. This is roughly the same as the user type I tested with JSP.

The permission to delete and modify their tables and data is now completely under my control.