Title: Record the process of obtaining target background permissions through the supply chain once

0x00 Long Exploration

One day, I received a task asking for a security test of the information system of a certain hospital to see if problems can be found. After preliminary information collection, it was found that the hospital did not have an official website, and only one WeChat official account provided functions such as reservation registration and payment. It seems that the breakthrough point can only be placed on this official account.

The following picture shows some functions of the WeChat official account:

When I clicked on these functions and caught the packet, I saw that all requests pointed to the domain name a.test.com, as shown in the figure below, forgive my thick code.

After searching the domain name test.com, I found that it is a local company that provides medical information systems, but I wonder why the hospital system is placed in the supplier company? How do they synchronize data? With these questions, I started testing the domain name a.test.com.

After seeing this familiar page, I confirmed that this system was probably developed by Sing boot. After a series of regular operations, I only found a swagger-ui page.

Since our goal is to obtain permissions, we focused on testing the interface of this page such as SQL injection and overriding rights, but it was fruitless and there was no file upload interface, so we started to get stuck here.

Looking back, the domain name a.test.com is a subdomain of test.com. Can it be made through test.com?

Visit test.com and open the official website of the supplier company.

After collecting information on the domain name of test.com, I found that several subdomains were resolved to a certain cloud server, but the IP was different.

First of all, the domain name git.test.com caught my attention, and after opening it, it was a gitlab service.

gitlab has historically been composed of several vulnerabilities:

Unfortunately, this system version is relatively high and all vulnerabilities are fixed.

Will it be subject to a weak password? I used several commonly used user names and top passwords to blast it, but it was fruitless. I also found a way to add it to a QQ group of this company and tried to get some valid information in the group file.

As expected, there is a form in the group file that records the detailed information of the employee

With this information, I started to use a name and work number to combine it into a gitlab username, and used a commonly used weak password to target the explosion. I hoped to have one or two results, but it was still fruitless. It seems that this gitlab has requirements for password strength, and weak passwords cannot be used.

0x01 Liu'an Huaming Yeyi Village

When searching for this gitlab using Google hack syntax, several public repositories that can be accessed without authentication were found.

I began to pin my hopes on these publicly accessible warehouses. Looking through these warehouses carefully, most of them were interface documents, which were of no use for this penetration.

Finally, I found the connection username and password of an oracle database in the rabbitmq installation introduction document:

During the previous information collection process, I have found that the IP address corresponding to the subdomain x.test.com has opened the oracle database port. I quickly connected to this database and found that the username and password are correct and I can connect.

Since this database version is low and sysdba permissions are in time, I can execute the command directly with system permissions.

Then add the user to log in and get the server that takes the oracle database.

And the mysql configuration file was found in this mysql folder.

Since the server test.com opens the mysql database, using this information, I successfully logged into the mysql database.

The user name and password of the supplier's official website test.com backend was successfully obtained in the mysql database.

When I went to log in with joy, I found that I could log in, but the background functions after logging in were all abandoned, and there was only one big thinkphp error.

What to do? The idea of using the background getshell was also lost. (I have also tried the exploit using Thinkphp3, but all failed)

0x02 Survival in a desperate situation

At this point, I think I can only put my hope on this mysql database. Since it is a Windows system, the UDF power upgrade is likely to not be successful, so I can only try to write a webshell. When writing a webshell, you need to know the absolute path. I tried to use various methods to make test.com report an error to see if there is an absolute path contained in the error message. A series of operations have no results, and there is only a 404 page.

There is no other way, I can only guess blindly. I suddenly thought about whether the table name of the mysql database table is the directory name of the website?

Use these two table names to construct the following absolute path

c:\\hs_web

c:\\hsweb

d:\\hs_web

d:\\hsweb When trying to c:\\hs_web, the webshell prompts that the write has been successfully done.

Connect successfully with ant sword:

Because the current user permissions are small, the permission is successfully raised using potato:

Adding user to successfully log in to the remote desktop:

A proxy rule was found in the nginx configuration file on the server, involving dozens of hospitals:

It turns out that the WeChat official account business of these hospitals first access the test.com server, and then transfer from nginx on this server to the real servers of each hospital. Then this is too unsafe. Once the supplier's server goes down, their business will also be lost.

Then, the WeChat official account backend source code was found on this server, and it was thrown to the companion for audit. After discovering the backend login bypass vulnerability, you can log in to the background directly.

Then change the information at will.

At this point, this penetration is over. In fact, after getting the real IP of the hospital, you can also conduct in-depth testing.

0x03  Summary 

1. Catch the public account of the target hospital and found that all requests pointed to the a.test.com domain name

2. Through the domain name registration query of test.com, I found that it is a supplier, and when I visit a.test.com, I prompted the error message "whitelabel error page"

The system is developed by sprint boot framework. It scans its directory through dirsearch and finds that there is a swagger-ui page.

Testing SQL injection and file upload are fruitless

3. Scan test.com through the subdomain scanning tool and found that www.test.com, git.test.com and hc.test.com exist.

At the same time, the nmap port scans the three domain names and finds that the corresponding IP of hc.test.com has opened port 1521 and www.test.com has opened port 3306.

4. Found git.test.com, and testing several gitlab vulnerabilities and blasting were fruitless.

5. After joining the after-sales QQ group provided by the official website of test.com, download an employee information form in the group.

Blasting git.test.com through the combination of employee names and work numbers was fruitless.

6. Search the subdomain name site:git.test.com through Google hack, and found that several public libraries of gitlab can be accessed. Some interface documents were found, but they were useless. I found that the user name and password of the oracle database were leaked in the rabbitmaq library.

7. Here, we connect to hc.test.com through oracleShell.jar through the user name and password of the leaked database. After entering, we found that it is sysdba permissions, executable commands, add users and to the administrator, and open port 3389 through the registry, and log in to the hc.test.com database host on the remote desktop.

8. On the database host, the mysql directory path is found, which contains the mysql database configuration file, and the file contains the database link username and password.

9. Since the server www.test.com opens the mysql database, Navicat is used to remotely connect to the database through the leaked database username and password, and obtain the username and password for the website login.

10. Enter www.test.com/admin to display the background login page, enter the user name and password, and find that the background function is not used, prompting the thinkphp3.13 error

11. Try to get the shell through thinkphp3.13 vulnerability, but it's fruitless

12. Here you need to write to the shell through the mysql log, but the path cannot be found. The table name of the database contains two tables hs_web and hsweb. I guess you are the directory name of the website. The physical path to the guess website is the following directory:

c:\\hs_web

c:\\hsweb

d:\\hs_web

d:\\hsweb

13. When trying to c:\\hs_web, a sentence is successfully written through mysql's log

14. Link a sentence through the ant sword and execute the whomai command to display ordinary permissions. Here, the authority is successfully raised through potato

sweetpotato.exe -a 'whoami'

15. Add users under the command terminal and enable remote desktop

16. After logging in to the system, I found that there was nginx configuration. Finally, I found that the hospital's WeChat official account business first visited the test.com server, and then transferred from nginx on this server to the real servers of each hospital.

17. Then, the WeChat official account backend source code was found on this server, and the local source code audit was conducted. The background login was discovered bypassed login, so you can log in directly to the background.

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