Activity Review#
Due to my lack of skills, the results of this activity within the key target range were minimal.
First, let's complain about the targets provided by the organizers. Not to mention that many of them are internal network addresses or inaccessible addresses (which may violate regulations and be taken offline), even if they can be accessed normally, they have temporarily added Chaitin Shield, which makes it difficult for me to test 😁. There are also strange rules that greatly reduce the value of the data, and the key is still the permission allocation (although I didn't get much data points).
In terms of web, limited by the targets, I basically tested weak passwords and concatenated some interfaces. Finally, I managed to get a shell on a peripheral asset, but there was no internal network at all /(ㄒ o ㄒ)/~~. In the end, I relied on the asset mapping engine to find a weak password on a certain OA and scored a lot...
In terms of mini-programs, most of them are protected and I couldn't find my beloved authorization vulnerability. Although I found a login interface that can be brute-forced, I couldn't crack it...
Data Analysis#
As shown in the figure, in the valid attacks:
web-weak password 34
authorization vulnerability 11
information leakage 10
login bypass 9
file upload 7
SQL injection 5
privilege escalation 2
file read 1
others 8
It can be seen that weak passwords are still the most important point to focus on. From another perspective, without weak passwords, the risk of system intrusion is greatly reduced.
Case Analysis#
Case 1: Weak Passwords#
There is a weak password vulnerability in the xx system. The attacking team obtained all user accounts through the weak password of the administrator, entered the background through the weak password of the user account, gained system permissions through file uploads, and obtained database account passwords through backup files. They were able to take control of more than 50 cloud hosts.
This is the most common operation and requires the red team to be proficient.
Case 2: Authorization Vulnerability#
The figure above shows that authorization can be bypassed through DevTools debugging. This train of thought is worth learning and referring to.
Case 3: Information Leakage#
The frontend JS file leaked the super administrator's account and password, allowing access and control of 15 cameras, and the ability to upload voice files, which can then be distributed externally.
Very detailed!
Case 4: Mini-program Risks#
Leaking the APPID and key allows direct control of the mini-program through WeChat debugging tools.
Why didn't I find it? It's all about the details!
Lessons Learned#
Information Gathering#
As we all know, information gathering is the most important part of the penetration process. Our asset collection process is as follows: filter the target assets and run them all through the lighthouse, and use plugins to search for interface leaks and other port services when testing individual websites.
Through this activity, I realized that there are significant shortcomings in my information gathering work. Taking a certain smart grid system as an example, the known internet access address is xx.xx.gov.cn. I only ran it through the lighthouse or other tools and didn't find many exposed surfaces, so I gave up in frustration. Unexpectedly, by checking the IP first and then running it, the attack surface expanded. As shown in the figure, the geoserver service was discovered, and it was possible to log in with the weak password admin/geoserver, and there were many things that could be done next...
Attack Techniques#
This time, I saw many experts using F12 to audit JS files, which I have seen many times but never tried. In the past, for JS, I relied solely on the Panda Head to automatically extract information, and sometimes I would simply search for interfaces. (Because I know that JS reverse engineering is not something a novice can do.) Now it seems that digging for vulnerabilities still relies on one word - details. Even if you are an expert, you don't just look at the JS code honestly, but eventually find the leaked administrator's account and password in the JS code and score a lot.
In the past, when it came to mini-programs, I would randomly click on some features and then look at the packets one by one in Burp. Often, I would give up in the end because I didn't have the patience. But the experts told me that this was too slow, and mini-programs can also be analyzed using DevTools for debugging. I learned something new, +1 experience.
Conclusion#
Although this attack and defense exercise was like being in prison, I gained a lot from it. Skills cannot be learned overnight, and progress can only be made through continuous practical exercises.