Introduction#
For learning and research purposes only, do not engage in any attack behavior that violates community consensus.
Analysis#
Frontend#
Through the console, it can be determined that the website uses version 0.15.4 of the GZCCTF project by GZTimeWalker. Although the website has not been updated to the latest release, which is version 0.15.5, the new release only fixes some minor bugs and there are currently no major security fixes, so the frontend is still considered secure.
Backend#
After reading the GZCCTF deployment documentation, it is known that the project is deployed using a combination of k8s and Docker. By analyzing the docker-compose.yml, it can be determined that the Docker image pulled for the project deployment is gztime/gzctf. The latest tag is selected for analysis and it is found that the image is packaged based on the Debian system, using ASPNET and .NET 7.0.9 as reverse proxies. This version of .NET was recently released and Docker escape is highly difficult, so the backend defense is considered secure.
Ports and System#
After testing, it is known that the server only opens ports 80 and 22, with port 22 used for SSH service, using OpenSSH 8.2p1 server. The reverse proxy on port 80 uses Microsoft Kestrel and ASPNET. Based on the details of TTL and other packet transmission and reception, it is speculated that the server system is Ubuntu 20.04.
Analyzing the CVEs that affect OpenSSH 8.2p1, two are focused on privilege escalation or code injection after obtaining SSH access or file write permissions (CVE-2020-12062, CVE-2020-15778), and four are focused on SSH proxy tunneling or uncommon configurations on the server side (CVE-2021-28041, CVE-2021-36368, CVE-2021-41617, CVE-2023-28531). These vulnerabilities cannot be exploited without SSH access as a regular user, but it is still recommended to update SSH as soon as possible.
IP Section#
According to the query, the IP is located in HK with a low risk level. It is expected to be hosted in a data center or provided by a relatively native ISP, but the possibility of internal network mapping cannot be ruled out. Due to the lack of domain binding, it uses a public IP and HTTP 1.1 plaintext. Due to special circumstances in certain regions, there is a possibility of triggering key blocking mechanisms through a large number of sensitive phrases, which may result in the server being inaccessible directly via IP in certain regions.
Conclusion and Recommendations#
-
The current security situation is still good, but there are still risks.
-
It is recommended to upgrade OpenSSH to prevent potential vulnerabilities in old versions from being exploited in the future. Measures such as restricting SSH access to specific IPs or using virtual LAN solutions can also be taken.
-
Keep in sync with upstream repositories in a timely manner and regularly check for escape prevention.
-
It is recommended to bind a domain and use Nginx or other reverse proxies for Docker or K8S ports. Apply CDN to hide the server's real IP, which can also mitigate DDoS attacks. Adopt HTTPS encryption to prevent man-in-the-middle attacks and data interception.