Deployer

Gaining Access

Nmap scan:

$ nmap -p- --min-rate 3000 -Pn 192.168.157.158
Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-16 11:41 +08
Nmap scan report for 192.168.157.158
Host is up (0.17s latency).
Not shown: 65462 closed tcp ports (conn-refused), 70 filtered tcp ports (no-response)
PORT   STATE SERVICE
21/tcp open  ftp
22/tcp open  ssh
80/tcp open  http

FTP -> Subdomain + Source Code

FTP allows for anonymous logins:

$ ftp 192.168.157.158
Connected to 192.168.157.158.
220 (vsFTPd 3.0.3)
Name (192.168.157.158:kali): anonymous
331 Please specify the password.
Password: 
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> ls
229 Entering Extended Passive Mode (|||42744|)
150 Here comes the directory listing.
drwxr-xr-x    2 0        0            4096 Jul 16 03:41 bak
drwxr-xr-x    2 113      118          4096 May 11  2021 ftp
drwxr-xr-x    4 0        0            4096 May 11  2021 sec
drwxr-xr-x    8 0        0            4096 May 11  2021 site
drwxr-xr-x    5 0        0            4096 May 11  2021 web

The FTP access shows us quite a few subdomains that exist within the /web folder:

The dev file was the most interesting because it had PHP code, whereas the others just had HTML files that were static. The index.php file had this:

There was a deserialisation exploit here beacuse of how the page parameter is handled, which allows for LFI and execution of PHP files through the include() function. At least we know that this site is vulnerable.

The site directory contained Apache config files:

002.conf contained a hidden subdomain:

The DocumentRoot is where the vulnerable PHP files are located, so this hidden domain is the exploitable one.

The intended path seems to be using deserialisation for LFI and maybe to execute PHP files. We are unable to write to the almost all the directories accessible through FTP except for the ftp one:

Deserialisation -> LFI + RCE

To exploit the LFI, I used some PHP code to generate the serialised objects needed:

We can then add the exploitable subdomain to our /etc/hosts file and view it:

We can then test our PHP code and find that it works:

Using this, we can attempt to read the FTP configuration files to find out where the FTP directory is:

The FTP Root is at /srv, meaning the reverse shell I uploaded is at /srv/ftp/phpreverseshell.php. We can then execute it using this serialised object:

I had to put the file there again since something cleared it, but I did get a reverse shell in the end:

Privilege Escalation

I upgraded the shell by dropping my public SSH key into the user's authorized_keys folder for easy access in case I lose this initial shell.

Sudo Docker Build -> Root

The user could run sudo with some commands:

We can first view the images present:

I read the documentation for docker build, and learned that we need a Dockerfile to run it:

Logodocker buildx buildDocker Documentation

The /opt directory also had a id_rsa.bak file present:

I think the goal is to read this file somehow. Here's the Dockerfile I used:

Then, we can run sudo /usr/bin/docker build . within /opt where the Dockerfile is.

We can then ssh in as root:

PreviousCookieCutterNextDepreciated

Last updated