Cover photo by https://unsplash.com/@kikesalazarn

Enumeration

Our target’s IP address is 10.10.11.191.

Let’s begin with port scanning.

We can see that SSH, HTTP, and NFS is running.

HTTP

Firstly, checked the website, but there was nothing interesting or vulnerable. Links were redirections to current page. (#)

NFS

From the scan result, we can see port 111 and 2049 opened, which means the NFS protocol is running. Let’s check the list of available exports.

There are two exports allowed to anyone (*). Create two directories and let’s mount them respectively to our local system.

As we can see above in the screenshot, it seems like the /var/www/html directory is owned by a user whose uid is 2017, and the user ross’s uid is 1001 on their system. Let’s check the common vulnerability vector, no_root_squash.

no_root_squash is not set. Then what about normal users? Let’s make two new users with the uid 2017 and 1001.

With these two users, checked if any of these are writable and yes, we can write stuffs in mnt1 share which is web root.

Foothold & User flag

If we can write something into the /var/www/html, this is such a big red flag and this is a way to get the initial foothold to the target system. We can upload malicious php payload in this directory to spawn a reverse shell. We will use one of the most famous payload, pentestermonkey’s php-reverse-shell.php (https://pentestmonkey.net/tools/web-shells/php-reverse-shell).

Setup a netcat listener on port 9999 and execute the payload with the curl command or directly accessing through the web browser.

We got in. It seems like the user alex is the one whose uid is 2017. We should upgrade our shell first.

Navigated to alex’s home directory and found the user flag.

Privesc & Root flag

After basic enumeration with linpeas, user ross is currently logged into the system, running on the gnome session on tty7.

Let’s go back to the NFS share of /home/ross mounted on mnt2 on our local system since alex doesn’t have permission to fully view ross’s home directory. But remember that we can impersonate ross due to misconfiguration in NFS service.

There are many files but we have to focus on the files that are only readable by the user ross which cannot be seen with the alex’s user account inside the target system. The most intriguing one of them is .Xauthority file, since we know ross is running a graphical environment.

https://askubuntu.com/questions/300682/what-is-the-xauthority-file

Also looking into .xsession-errors, we get some more information.

Ross is running lightdm and it is likely that ross is running on DISPLAY:0. We can verify it by taking a screenshot using the credential cookie from .Xauthority.

Copy .Xauthority to target machine so that alex can import it.

1
2
3
4
5
6
7

# On Attacker's machine in ross's nfs share
cat .Xauthority | base64

# On Target's machine
echo COPIED_BASE64_STRING | base64 -d > copied_cred
export XAUTHORITY=/home/alex/copied_cred
xwd -root -display :0 -out screenshot.xwd

Exported the ross’s Xauthority cookie and tried to take screenshot. (Had some trouble with the xwd syntax)

Once the screenshot is taken, let’s transport it back to our local machine and see the picture.

Copied the file remotely with the python simple web server and converted the xwd image to png. This time, instead of base64, we use python webserver because the base64 on image data could yield too much text output.

1
2
3
4
5
6

# On Target's machine
python -m http.server # host the server

# On Attacker's machine
wget 10.10.11.191:8000/screenshot.xwd
convert screenshot.xwd png.png

Open png.png

We got root password. “cah$mei7rai9A”

We got the root flag.

It is easy to fall into a rabit hole when people are investigating the ross’s home directory via NFS share and find the KeePass database file. I also spent a lot of time on trying to crack the KeePass database. However, ross was actually running this program on the GUI and the way to get this was to steal ross’s Xauth cookie to see ross’s screen.

Machine pwned.