TryHackMe: Cooctus Stories Writeup

Learn about NFS, Python3 scripting, umount in This Medium THM Room.

coocuts clan, thm

Play

1. Scanning & Enumeration

We do the below scans in parallel.

1.1. Port Scanning

Info gathered:

  • SSH on 22 open
  • HTTP on 8080 open
  • NFS on 2049 open

1.2. Web Enumeration

Doing a basic enumeration, we get the pages: /cat and /login.

1.3. Web Exploration

The home page:

cooctus clan homepage

The login page:

login page cooctus clan

I tried some basic SQLI attacks, but they did not work. Recall that we had the 2049 port open with NFS running. Let’s explore that first then.

1.4. NFS

Let’s see what all do we have:

Amazing! Looks like we can get something. Follow the steps to mount shares using NFS service:

  1. Go to /tmp on your machine. (Or wherever you want. I prefer /tmp.)
  2. Make a directory where the files of the other system would be mounted. Call it whatever you want.
  3. Mount the shares using sudo mount --type nfs. Make sure to sudo!

And we have successfully mounted the files shared using NFS. Let’s explore them.

And we get the credentials for the login!

2. Foothold

2.1. Getting RCE

We finally get in. We see a page where we can put payload.

It took me a lot of experimentation and time to get RCE. Here’s what I figured.

  • Whatever you put in the payload gets echo-ed exactly as is, on the resultant page.
  • There may be php or python3 or whatever program running.
  • What if the input is not sanitised? How about using “;”?
  • Trying out wow”; echo “bruh” — does not work.
  • Checking for more, I get this page: OWASP Command Injection, how about “|” in the list?

I use reverse shells from Reverse Shell Generator.

BONUS:

  • I tried other revshells: bash and the mkfifo one. Did not work.
  • I tried using & and &&. Also did not work.

2.2. Exploring

I like to check a couple of things when I first get in any machine:

  • What all users exist?
  • All files having SUID bits set
  • crontab
  • Kernel version

Users

SUID bits

One of them pops out!

Kernel Version

Upto date.

crontab

Last line looks very interesting.

2.3. Info Gathered

  • /home/szymex/SniffingCat.py is running every minute, by the user szymex
  • /home/varg/CooctOS.py has SUID set Okay. We are ready for PrivEscs.

3. PrivEsc

3.1. szymex

Exploring inside szy, we get a file called note_to_para and SniffingCat.py.

Looks like szy has some password there. Let’s open it up.

What’s happening here?

  • Every minute (for eternity) the above script is run
  • The script opens a mysupersecretpassword.cat file and checks if the thing put in can be encoded to be same.
  • We need to find the string that encodes as the above. Python3 scripting time!

Here’s what I came up with:

After cracking this, maybe we can try directly sudo-ing into szymex?

Works!

3.2. tux

I was stuck here for a bit, before I tried id.

testers looks intersting. Let’s see what all do we have.

Woah. That’s a lotta files. Going through them,

Note 3:

Note 1:

Its C code, with a lot of #s. Compiling, we get:

Not helpful. Although, looking at the source more closely, we can see some hex strings. They are in the line which I have translated below.

... printf *** **** *** ; ...

We get the first string!

Note 2:

Looks like we are looking at a pgp key.

I initially tried breaking it, but then I saw the /media/tuxling_2/private.key file. Import the key and we are done!

We have all the fragments now! But now what? I tried breaking the cipher, but it didn’t work. What if it were a hash instead? Going to CrackStation we get the cracked hash!

3.3 varg

In this user I saw a .ssh folder. Good news! Here’s how to ssh into the tux user.

  1. Go to ~/.ssh on your machine
  2. Get your id_rsa.pub
  3. echo "{your_id_rsa.pub here} > authorized_keys"
  4. SSH in!

Exploring a bit, we see -

Game was nice (i got the easter egg too XD). But now what? There was a .git directory that I missed. Checking it out, we have:

Maybe something was hidden in the later commits? Let’s see the diff.

Ah yes! We get the creds.

3.4. root

I checked the sudo permissions:

GTFOBins only mentioned that of /bin/mount and not /bin/umount. What next? Realise that we may have something intersting mounted :D

Here’s what happened:

  • df reports file system disk space usage
  • -h flag is human readable, because we did
  • -a flag which displays everything

Going in however, we see only:

Its the same as what we saw before. But hold up! Recall the sudo permissions to umount? Let’s do it!

Wait what happened here?

  • We were allowed to run sudo /bin/umount or just sudo umount without a password
  • The /opt/CooctFS/root/ folder existed in the /opt/CooctFS/ folder beforehand
  • We were not able to see this because there was the other stuff listed out, which in effect, hid the /root/ directory till we lifted the mount.

You can explore more on the linux mount what exactly was happening. Look for the bind keyword! Thanks to @crazyjointje for the explaination and andother fellow hacker for pointing out the bind functionality (#room-hints, TryHackMe Discord).

Nice. Let’s see the contents -

But … we have the .ssh folder. Do you know dear reader, what that means? We can login as root! cat the id_rsa private key, copypaste it on your system

And … we are done!

Originally published at https://chaudhary1337.github.io on June 25, 2021.

Breaking in Pen-Testing

Love podcasts or audiobooks? Learn on the go with our new app.