Actual offensive and defensive combat | Record the entire process of breaking through a certain car company

0x00 Preface

This article introduces the detailed process of how the author penetrated from the external network into the intranet of a car company during an attack and defense drill (in order to protect sensitive information, all data has been desensitized, and some screenshots are incomplete, please forgive me).

This network attack and defense drill is divided into two phases for a total of fourteen days. The first seven days are the private resource phase, and the last seven days are the public resource pool phase. A total of 12 teams participated in the competition, and only two players from our company participated in the whole process. Since the company never provides some auxiliary tools and human resources, and we have participated in many competitions recently, we were both very internally consumed after each competition.

0x01 Information collection

The referee only gave the name of the target company and asked us to find other information on our own. This was a test for our team with poor resources.

Fortunately, the author previously wrote a set of auxiliary scripts for information collection, which can now be put to great use.

First, use the subsidiary collection script to search for first-level subsidiaries. The script searches based on specific criteria and rules for subsidiaries that have a 50% ownership relationship with a Tier 1 company. We then ran a script search again on these first-tier subsidiaries to find subsidiaries with which they had a 50% ownership relationship. This process keeps looping until there are no more qualified subsidiaries, so you see below that the deepest reaches level four companies.

picture

Next, use the asset collection script to perform a series of operations on the ICP results of the subsidiary collection script. The script includes subdomain name matching, port scanning, web path search, service identification, etc. The final result will be the following three files, among which The IP file can be handed over to the lighthouse for information collection, the url file can be handed over to the POC scanner, and the detailed file can be manually searched for some vulnerabilities that are not found in the POC scanner (such as weak passwords, manual dog heads) when scanning the POC.

picture

0x02 web management

I first used a POC scanner (Xray Youth Edition, POC-bomber and other open source works) to scan the asset collection results. The results did not find an exploitable vulnerability (there are few people and the company does not provide some management resources. What should I do? , the dog’s head saves his life).

There is no other way but to manually analyze which URLs may contain surprises one by one.

After flipping through a lot of boring pages, I locked my eyes on a URL. The title of this URL is XXConfluence.

picture

picture

When I found out that this website uses Confluence, I think many masters knew what to do. I immediately checked whether RCE existed in it. After some attempts, I found that RCE did exist in this version, and confirmed that the server's operating system was Linux.

Next, I bounced the shell to the server and found that I had obtained unlimited shell access. Immediately made a remote control horse and uploaded it to the target server. After MSF went online, I checked the network card and found that the server had a network card of 172.32.0.30, and then uploaded the proxy tool.

picture

picture

0x03 Intranet information collection

After using the frp tool to expose the intranet, we successfully entered the 172.32.0.0/24 network segment.

Next, my teammates and I started formal intranet information collection work.

picture

picture

As usual, use the fscan tool to scan to see if you can find some weak passwords or exploitable vulnerabilities, which will make our attack smoother. However, the scan results disappointed me. There was no exploitable vulnerability in network segment 32. I had no choice but to use fscan to continue scanning the network segments from 172.16 to 172.31, hoping to gain something. However, I was afraid that scanning too hard would trigger some alarms, so I proceed cautiously. Fortunately, I found an F5 BIG-IP file upload vulnerability while scanning section 172.16.

In order to verify whether this vulnerability really exists, I constructed a URL to test it, and found that it can be successfully executed and echoed. I was secretly happy, now I have something to play!

https://172.16.0.11/tmui/login.jsp/..;/tmui/locallb/workspace/fileRead.jsp?fileName=/etc/passwd
 

picture

The next steps became relatively simple. I uploaded the rebound shell code to the F5 server and executed it through the local NC monitor. In this way, I successfully obtained the rebound shell of the F5 server and found that it has root permissions, which means that we can collect more information on this server and broaden the attack surface.
 

picture

picture

picture

In order to further explore the vulnerabilities of this server, we tested whether it could log in to other servers via SSH without a key, and checked historical command records and some running services, but no valuable information was found. Later, I thought that since this server mainly runs many Java programs, I used a configuration file search command, hoping to find some breakthrough points from the configuration file.

find / -name "*.properties" -o -name "*.yaml" > ret.txt

After carefully searching multiple files, I finally found the passwords for Redis and MySQL in a file called base_config.yaml. However, when I tried to log into these services, I didn't find any sensitive data. And the latest data has only been updated to 2022 (the password in this screenshot was randomly generated by the author, but it is the same length as the original password).
 

picture

Just when I was thinking about whether I should stop, I suddenly had an idea and thought that since the passwords for Redis and MySQL are the same, is the password for SSH also the same? I immediately used the Xshell tool to try to connect, and to my surprise, I successfully connected! Then, I started to wonder if other servers would use the same password, because on the intranet, many administrators think the password is strong enough, so they will reuse the same password on other services.

Here, the IPs of the 172B segment servers scanned by fscan are summarized into a list, and a blasting tool is used for password blasting. In the end, I successfully cracked the passwords of 47 servers. When using Xshell to log in manually, I have to admit that when the number of assets is large, my fingers will feel tired (manual dog head). Add hackctf55 to the penetration communication group on WeChat.

The following is a successful login on the server

picture

0x04 Breaking through logical isolation

I was manually logging in using Xshell when I received a great message from a teammate. When he tried to log in to 172.32.0.81, he found that the server had multiple network cards.
 

picture

And in the historical commands, we found that the administrator added a soft route on the server to forward traffic to the 10.54.0.0/19 network segment
 

picture

We immediately decided to build a proxy on 172.32.0.81 so that we can access the resources on the 10.54.0.0/19 network segment.
 

picture

After completing the preparatory work, we then used fscan to scan the 10.54.0.0/19 network segment. We found a weak password for the MySQL database:

[+] mysql:10.54.15.233:3306:root P@ssw0rd

In this database, we found some sensitive data, including basic configuration files, Internet of Vehicles information, car registration file information, etc. In particular, the basic configuration file contains sensitive data such as various service accounts and passwords, nacos configuration, cloud service secretId and secretKey.

0x05 Cloud intranet penetration

Now that you have obtained the cloud service secretId and secretKey, use CF, the cloud penetration artifact, for further detection. After configuring the AK, you will find that the permissions are administrator permissions.
 

picture

Then create a sub-account and take over the console.
When logging in to the console, I found that there are 64 cloud servers, 13 mysql cloud databases, 3TB object storage, 17 vpc networks and other information.
 

picture

These 64 servers have root privileges when executing commands in cf.
 

picture

In addition, Shenxian teammates also found highly sensitive information such as tens of thousands of people's contact information, home addresses, driver's licenses, photos of the front and back of ID cards, and license plate numbers from the storage bucket. Add hackctf55 to the penetration communication group on WeChat.

In this way, this penetration is basically completed. With 48 physical servers plus 64 cloud servers, as well as a large amount of configuration file data, development environment configuration, and a large amount of customer sensitive data, the score has far exceeded the online score.

0x06 Summary

  1. Pay attention to the cleanup traces: After my teammates and I saw that the scores were down, we continued to infiltrate other assets. We did not go to the spring machine in time to clean up the traces. As a result, the unit that was traced to the source was successfully resurrected. We also had points deducted accordingly, resulting in heavy losses. ;

  2. When the intranet is running horizontally, the speed must be increased, because especially for win hosts with security services, generally alarms are delayed, but the delay may be only 2 hours, 4 hours, 6 hours, etc., so assets must be transferred as soon as possible. Sort it out clearly and get more path points;

  3. To summarize the attack process:
    Confluence application on the external network RCE --> F5 application RCE on the internal network --> Obtain the database password from the F5 server configuration file -> Password blast the database password to SSH -> Successfully blasted server Logically isolated 10 network segments were found in the history record --> Find the database weak password --> Obtain the AK and SK with administrator rights for the cloud service from the nacos configuration of the database --> Enter the core business intranet --> Find core data;

  4. Try more password spraying, you may get unexpected results;

  5. In the future, I will make more use of social engineering phishing techniques to obtain the target's sensitive information, because it is no longer easy to attack the target's vulnerabilities through traditional technical means.

- end -

Guess you like

Origin blog.csdn.net/ab6326795/article/details/131957042