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 combined some interfaces. It was not easy to finally get a shell in the side station, but it turned out to be an edge asset, not the internal network. /(ㄒ o ㄒ)/~~. In the end, I relied on the asset mapping engine to find a certain OA with weak passwords and scored a lot...
In terms of mini programs, they are basically well protected, and I couldn't find my beloved privilege escalation 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 passwords: 34
privilege escalation vulnerabilities: 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 pay attention to. From another perspective, without weak passwords, the risk of system intrusion is greatly reduced.
Case Analysis#
Case 1: Weak Passwords#
The xx system has a weak password vulnerability. 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 upload, and obtained database account passwords through backup files, thus taking control of more than 50 cloud hosts.
This is the most common operation and requires the red team to be proficient.
Case 2: Privilege Escalation Vulnerabilities#
As shown in the figure, a privilege escalation vulnerability was discovered through DevTools debugging. The 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 deficiencies 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 just 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. There are many things that can be done next...
Attack Techniques#
This time, I saw many experts using F12 to audit JS files, which I have seen many times but have 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 that novices can do.) Now it seems that digging for vulnerabilities still depends on one word - details. There is no need for fancy debugging. Even for experts, they don't just honestly look at the JS code, but ultimately 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 is too slow. Mini programs can also be analyzed and debugged using DevTools. I learned something new, +1 experience.
Conclusion#
Although this attack and defense exercise was like being in prison, I gained a lot from it. Technology cannot be learned overnight, and progress depends on continuous practical exercises.