OverPass3

This one had an interesting privilege escalation that i wanted to make note of. I am too lazy to do the whole write-up so I grabbed a public one that was done well.

https://book.hacktricks.xyz/linux-hardening/privilege-escalation/nfs-no_root_squash-misconfiguration-pe

https://www.aldeid.com/wiki/TryHackMe-Overpass-3-Hosting

TryHackMe-Overpass-3-Hosting

Jump to navigation Jump to search

You know them, you love them, your favourite group of broke computer science students have another business venture! Show them that they probably should hire someone for security…

After Overpass’s rocky start in infosec, and the commercial failure of their password manager and subsequent hack, they’ve decided to try a new business venture.

Overpass has become a web hosting company! Unfortunately, they haven’t learned from their past mistakes. Rumour has it, their main web server is extremely vulnerable.

Warning: This box can take around 5 minutes to boot if you’re not a subscriber. As a subscriber, it will be ready much faster.

Contents

Web Flag

Hint: This flag belongs to apache

Initial foothold

Nmap detects 3 ports: 21 (FTP), 22 (SSH) and 80 (HTTP).

Web

Let’s start with the web service, as the FTP service doesn’t allow anonymous access.

The web page reveals a few potential usernames:

  • Paradox

  • Elf

  • MuirlandOracle

  • NinjaJc01

Enumerating with gobuster allows to discover a hidden /backups directory.

The backup archive

The /backups/ contains a backup.zip file.

Import the key and decrypt the file:

Opening the CustomerDetails.xlsx spreadsheet shows the following information:

Customer Name
Username
Password
Credit card number
CVC

Par. A. Doxx

paradox

ShibesAreGreat123

4111 1111 4555 1142

432

0day Montgomery

0day

OllieIsTheBestDog

5555 3412 4444 1115

642

Muir Land

muirlandoracle

A11D0gsAreAw3s0me

5103 2219 1119 9245

737

FTP

Connecting as paradox with ShibesAreGreat123 as password against the FTP service works.

We have access to the website’s sources, and the directory is writable. Let’s upload a PHP reverse shell:

Reverse shell

Start a listener (nc -nlvp 4444) and browse the shell that has just been uploaded (curl -s http://10.10.158.2/shell.php). We now have a reverse shell:

Web flag

After failing to find the flag by searching for files owned by the apache user or group, I eventually found the flag by searching for files matching *flag*:

Web flag: thm{0ae72f7870c3687129f7a824194be09d}

User Flag

Hint: This flag belongs to james

Lateral move (www-data -> paradox)

There are 2 users listed under the /home folder. Let’s try the password found previously.

We can connect as paradox with the password found previously (ShibesAreGreat123) in the xls spreadsheet.

At this stage, you can add your SSH public key to /home/paradox/.ssh/authorized_keys to connect via SSH directly.

NFS service

I checked the user privileges but found nothing interesting. Same for files owned by the user. The user doesn’t belong to any particular group either.

Running linpeas.sh on the target will reveal an interesting NFS share (/home/james), with the no_root_squash option set. We’ll come back to this later for the privilege escalation, but at this stage, we only care about the NFS share.

We confirm that NFS is running on port 2049:

I tried to mount the NFS share but it failed, because NFS is only accessible to localhost.

To make NFS available to us, we’ll use a port forwarding as follows:

Now, NFS is available to us, which we can confirm with the below Nmap scan:

User flag

And now, we can access the NFS share and get the user flag:

User flag: thm{3693fc86661faa21f16ac9508a43e1ae}

Root flag

Lateral move (paradox -> james)

As we have access to james’s home, we can add our SSH public key to connect as james via SSH directly.

Now, connect as james:

Privilege Escalation

Remember that linpeas.sh reported the following lines:

The presence of the no_root_squash option is a good news for us (see below explanation).

By default, NFS shares change the root user to the nfsnobody user, an unprivileged user account. In this way, all root-created files are owned by nfsnobody, which prevents uploading of programs with the setuid bit set. However, if the no_root_squash is used option is used, remote root users are able to change any file on the shared file system and leave trojaned applications for other users to inadvertently execute.

I first tried to copy the bash binary from my Kali box to the NFS share, but it failed to execute on the target:

I then tried to copy the version of bash to james’ home and it worked. On the target, as james, I first copied the bash binary to the home folder:

Then from my Kali box, I abused the NFS permissions to change the owner and to set the SUID bit:

Now back on the target, we have a bash binary owned by root with the SUID bit set:

Root flag

We can now be root and read the flag

Root flag: thm{a4f6adb70371a4bceb32988417456c44}

PreviousGhostcatNextJoker

Last updated