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:

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:

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:

This would print base64 encoded payload, which we can submit like so:

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:

There are other files in the /var/www file present as well:

We can find credentials inside the server file for the user james.

We can then su to james:

Sudo Privileges

Since we have the password for james, we can check our sudo privileges:

This file is owned by www-data and we can write to it:

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:

PreviousSplodgeNextSybaris

Last updated