TryHackMe write-up: Overpass 3

 

Introduction



This is my write-up for TryHackMe's Overpass 3 Room

Enumeration

Using nmap, I found that this box had 3 ports open.


Checking port 80, it looked like a standard web site.


I then checked the FTP service and tried logging in anonymously.  However, anonymous login is not allowed here.



Running dirb, I found that there is a folder named backups.

Checking the contents of the backups folder, I found a zip file named backup.zip.

Downloading the file and extracting the contents,  I found what looked like an encrypted file and the decryption key.

To decrypt the file, I need to import the key first.  I did it using:
gpg --import <key file>

Once the key was imported, I proceeded to decrypt the file using:

gpg --output <output file> --decrypt <input file>

As shown below, I was able to successfully decrypt the xlsx file. 


Checking the file contents, I found it contained user credentials.


Exploitation

Going back to the ftp service, I tried to login using one of the credentials found.  After successfully logging in, I tried uploading the php reverse shell script found at pentestmonkey.net.




Going back to my browser, I tried accessing the php file.  I then checked the netcat listener I opened prior to accessing the php file.  There, I saw that I now have a shell back to the target.

The hint shows that the web "flag belongs to apache".  I found that the flag is in the $HOME directory.


Privilege Escalation

Finding a way to escalate privilege was a bit tricky.  Using the stolen credential used to login to the FTP service, I was able to su as the user paradox.  However, I couldn't run sudo as either paradox or apache, and passwords weren't available at accessible files.  To make matters worse, the hint showed that the user "flag belongs to james".

Running linpeas, I found that james' home folder is exported.


I tried mounting the folder, however, something seemed to be blocking access.

I then ran a full-port nmap scan, and it showed that the NFS port (2049) cannot be accessed from my machine.


I verified that from within the target, the port is accessible.


In order to access this, I needed to create a tunnel to forward the port to my attacker machine.  I did that by using:

ssh -R 2049:localhost:2049 <attacker user@attacker IP>


Now that I could access the port, I was able to mount the share.  Do note that according to https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/deployment_guide/s1-nfs-server-config-exports, for fsid=0 and NFSv4, there is no need to specify the full shared path.  Thus, I just ran the command:

sudo mount localhost:/ <mount point>

Note that I specified localhost since the target's port 2049 was "tunneled" over to my attacker's port 2049.  Once james' folder was mounted, I was able to access the user flag.


Given that I could also access james' ssh key, I then connected via SSH to the target.

Given that james did not have sudo permissions, I had to resort to more creative means for getting root privileges.

From my attacker box, I created an executable that would try to run bash with user id=0 (root).  To ensure that this executable will be able to run bash as root, it had to be owned by root also.  In addition, the suid bit should also be set.

I then went back to the SSH terminal and ran the executable as james.  I then got root privileges and was able to read the root flag.







No comments:

Post a Comment