Preface#
For learning and research purposes only, do not engage in attack behavior that violates community consensus.
Analysis#
Front-end#
Through the console, it can be determined that the website is using version 0.15.4 of the GZCCTF project by GZTimeWalker. Although the website has not been updated to the latest release of the project, which is version 0.15.5, the new release only fixes some minor bugs and there are currently no major security fixes, so the front-end is still considered secure.
Back-end#
After reading the GZCCTF deployment documentation, it is known that the project is deployed using a hybrid approach of k8s and Docker. By analyzing the docker-compose.yml, it can be concluded that the Docker image pulled for the project deployment is gztime/gzctf, and the latest tag is selected for analysis. It is found that this 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 back-end defense is considered secure.
Ports and Systems#
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, and port 80's reverse proxy 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 of them focus on privilege escalation or code injection after obtaining SSH access or file write permissions (CVE-2020-12062, CVE-2020-15778), and four of them focus 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 obtaining 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 native ISP, but the possibility of internal network mapping cannot be ruled out. Due to the lack of a bound domain name, 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 future vulnerabilities that may be exploited in older versions. Measures can also be taken to restrict SSH access, such as limiting specific IPs or using virtual LAN solutions.
-
Keep in sync with upstream repositories in a timely manner and regularly check for escape prevention.
-
It is recommended to bind a domain name and use Nginx or other reverse proxies for Docker or K8S ports, and apply CDN to hide the server's real IP. This can also mitigate DDoS attacks. Adopt HTTPS encryption to prevent man-in-the-middle attacks and data interception.