The London Bridge: A Vulnerability Analysis
The TryHackMe machine 'The London Bridge' presents a compelling challenge centered around a Flask web application designed to showcase London. This application, served via Gunicorn, contains a critical Server-Side Request Forgery (SSRF) vulnerability that, when chained with other misconfigurations, allows for a full system takeover. This writeup details the steps taken to identify and exploit this vulnerability, culminating in root privileges.
Initial Reconnaissance and Endpoint Discovery
The primary attack surface is a Flask 'Explore London' gallery application. During initial reconnaissance, a hidden endpoint, /view_image, was discovered. This endpoint accepts form-encoded data and is designed to fetch URLs server-side. This immediately signals a potential SSRF vulnerability.
The visible parameter for the URL fetching was image_url. However, direct attempts to use this parameter to access internal resources or exploit SSRF proved fruitless. The application actively blocks requests to localhost, 127.0.0.1, and 0.0.0.0 via simple string matching on the URL. This is a common, albeit easily bypassed, defense mechanism.
Bypassing SSRF Filters and Discovering the Real Parameter
The first hurdle was bypassing the IP address filtering. The application’s string-matching is naive. Instead of relying on proper network-level controls, it checks the URL string. This allows for exploitation using alternative loopback representations. The successful bypass was achieved by using http://0/ as the target URL. This alternate representation of the loopback interface is not caught by the simple string checks.
The second challenge was identifying the correct form field for the URL. The image_url parameter was a red herring. Through fuzzing the form field names submitted to the /view_image endpoint, the actual parameter used by the application was discovered to be www. This highlights the importance of not taking visible parameters at face value and employing robust fuzzing techniques when analyzing web applications.
Exploiting SSRF for Local File Inclusion
With the SSRF filter bypassed and the correct parameter identified, the next step was to leverage this vulnerability. The goal was to point the SSRF to a service running on the target machine that could expose sensitive files. The key insight here is that the application is served by Gunicorn, and the target machine is running a Python http.server as the root user from the target’s home directory.
This http.server, running as root, is susceptible to path traversal and can serve files regardless of standard Unix file permissions. By crafting a request to the /view_image endpoint with the www parameter set to http://0/, we could instruct the server to fetch resources from itself. The critical discovery was that this root-owned server was accessible via the SSRF. The SSRF essentially allowed us to browse the filesystem as if we were the root user, but through the web application’s request.
Gaining Root Access via SSH Key Exfiltration
The ultimate prize within the root-owned directory was the SSH private key. By using the SSRF to request the file located at .ssh/id_rsa (relative to the directory from which the Python server was launched), the private key could be exfiltrated. The SSRF vulnerability, when pointed at the local root-owned HTTP server, effectively acted as a local file reader for any file the root user could access.
Once the id_rsa private key was obtained, the next logical step was to attempt to use it for SSH access. The machine's authorized_keys file, typically located in ~/.ssh/ for the target user, would contain the corresponding public key, allowing for passwordless SSH authentication. By attempting to SSH into the machine using the exfiltrated private key, and targeting the user whose home directory contained the Python server, root access was achieved.
Conclusion and Lessons Learned
The London Bridge machine serves as an excellent example of how seemingly simple vulnerabilities, when chained together, can lead to complete system compromise. The SSRF vulnerability, combined with naive IP filtering and the presence of a root-owned local HTTP server, created a perfect storm. Developers must be acutely aware of the dangers of SSRF, especially when dealing with user-supplied URLs. Robust input validation, including proper network-level checks and avoiding string-matching for security controls, is paramount. Furthermore, understanding the context in which applications run – particularly user privileges and accessible services – is crucial for both defenders and attackers.