> For the complete documentation index, see [llms.txt](https://n000b3r.gitbook.io/oscp-notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://n000b3r.gitbook.io/oscp-notes/htb/oscp-like-boxes/squashed.md). # Squashed ### Scanning Firstly, I started off with a full port scan on the host `10.10.11.191` using the command `nmap -p- 10.10.11.191 -T5`.

Fig 1. Nmap full port scan

As seen from figure 1, ports 22, 80, 111, 2049, 35099, 46369, 48809, 54277 were open. Next, I used the command `nmap -p 22,80,111,2049,35099,46369,48809,54277 -A 10.10.11.191 -T5` to conduct an aggressive scan.

Fig 2. Nmap aggressive scan part 1

Fig 3. Nmap aggressive scan part 2

From fig 2 and 3, SSH, HTTP and NFS were open on the system. ### Enumerating HTTP Heading to the webpage, I was greeted by a furniture company's landing page.

Fig 4. Furniture shop landing page

Next, I ran a `dirsearch` scan to uncover interesting directories or files but found nothing particularly interesting.

Fig 5. Dirsearch results

### Enumerating NFS NFS is a server/client system enabling users to share files and directories across a network and allowing those shares to be mounted locally. While both useful and versatile, NFS has no protocol for authorization or authentication, making it a common pitfall for misconfiguration and therefore exploitation. To start off, I ran the command `showmount -e 10.10.11.191` to list any available shares on the target machine.

Fig 6. List of available NFS shares

We can see two globally accessible file-shares, as indicated by the star. We can have a look at their contents by mounting the directories. The directories can be mounted using the commands `mount -t nfs 10.10.11.191:/home/ross /home/kali/Documents/htb/squashed/mapped -o nolock` and `mount -t nfs 10.10.11.191:/var/www/html /home/kali/Documents/htb/squashed/mapped_www -o nolock`

Fig 7. Mounting /home/ross share

Fig 8. Mounting /var/www/html share

Using the command `ls -ld` I was able to view the permissions for the 2 shares. For the `mapped` directory which maps to the `/home/ross` directory, it is owned by the UID 1001 and belongs to the group with the ID 1001. For the `mapped_www` directory which maps to the `/var/www/html` directory, it is owned by the UID 2017, and belongs to the group with the ID of www-data.

Fig 9. File permissions

### Exploit: NFS Imitation

Fig 10. Creating user dummy

Fig 11. Creating user dummy2

Switching to the user `dummy`, I was able to view the /var/www/html share.

Fig 12. Viewing /var/www/html share

Next, I copied the Pentestmonkey's php-reverse-shell.php file from `/usr/share/webshells/php/php-reverse-shell.php`.

Fig 13. Copied PHP reverse shell

Browsing over to the site `http://10.10.11.191/php-reverse-shell.php`, I was able to obtain a reverse shell.

Fig 14. Received reverse shell

Fig 15. Obtained user flag

### Privilege Escalation Switching to the user `dummy2`, I was able to view the /home/ross share.

Fig 16. Viewing /home/ross share

There's a `Passwords.kdbx` file but I was unable to run keepass2john successfully.

Fig 17. Keepass2john failed

Using the command `ls -la`, I was able to see that `.Xauthority` file was present. The presence of `.Xauthority` and `.xsession` files in the home directory indicate that a display might be configured, with ross potentially already authenticated.

Fig 18. .Xauthority file present

This theory is further supported by the fact that the display manager LightDM is found in the /etc/passwd file.

Fig 19. LightDM is present

The `.Xauthority` file is used to store credentials in the form of cookies used by xauth when authenticating X sessions. When a session is started, the cookie is then used to authenticate the subsequent connections to that specific display.

Fig 20. Base64 encode .Xauthority file

After encoding the `.Xauthority` file, I used the command `echo "AQAADHNxdWFzaGVkLmh0YgABMAASTUlULU1BR0lDLUNPT0tJRS0xABDP+dRpKdO/F+qG/DgGII9u" | base64 -d > /tmp/.Xauthority` to save the `.Xauthority` file in the `/tmp` folder. Next, I set the XAUTHORITY environmental variable to the newly created `.Xauthority` file. Then, I issued the command `w` to know which display ross is using. Lastly, I used the command `xwd -root -screen -silent -display :0 > /tmp/screen.xwd` to take a screenshot.

Fig 21. Save .Xauthority file on alex

Moving on, I set up a Python HTTP server on alex to transfer the files over to the attacker's machine.

Fig 22. Python HTTP server

I managed to download the screenshot using `wget`.

Fig 23. Downloading the screenshot

Since the screenshot is in the xwd extension, I used ImageMagick's convert tool to convert it to a `jpg` file.

Fig 24. Converting to jpg file

Upon opening, I was able to view the root's password in cleartext.

Fig 25. Password in cleartext

Switching over to the root account, I was able to obtain the root flag :)

Fig 26: Root flag