Introduction

Welcome back to another TryHackMe CTF write-up. I decided to go for an easy one today but it was still a lot of fun!

Link to room: https://tryhackme.com/room/jackofalltrades

Ports

Let’s start off by scanning which ports are open on the target machine.

nmap -p- --min-rate 5000 -oN allports IP

Ok so a standard SSH/HTTP box. Let’s see if there’s anything more we can learn about these open ports.

nmap -sCV -T4 -oN services -p 22,80 IP

Not so standard after all… The services seem to be on opposite ports.

Web Server

Checking out the website doesn’t work. Port 22 is for SSH connections by default so our browser has a bit of a fit.

A quick google search gives us a solution. (https://support.mozilla.org/en-US/questions/1083282)

Note: I am using Firefox. This method will obviously be slightly different on other browsers.

We can edit the network.security.ports.banned.override rule if it exists or create it if it doesn’t.

Note: Supply it a string value otherwise it won’t accept it.

Refreshing the website should let you see the page now.

Let’s get a gobuster scan going and see what directories are on this website.

gobuster dir -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -u http://IP:22 -x txt,py,php,js

So we have /assets which is a folder with images on the front page. /recovery.php isn’t standard however.

Let’s see if we can glean any information from the home page.

Immediately, we can see a very obvious clue given to us by the creator of the box that we will be performing some steganography:

Additionally, looking at the source code gives us even more glaring clues.

"If I ever get locked out I can get back in at /recovery.php!"

UmVtZW1iZXIgdG8gd2lzaCBKb2hueSBHcmF2ZXMgd2VsbCB3aXRoIGhpcyBjcnlwdG8gam9iaHVudGluZyEgSGlzIGVuY29kaW5nIHN5c3RlbXMgYXJlIGFtYXppbmchIEFsc28gZ290dGEgcmVtZW1iZXIgeW91ciBwYXNzd29yZDogdT9XdEtTcmFxCg==

This looks like a base-64-encoded string. Let’s put this through CyberChef to see what it says.

Remember to wish Johny Graves well with his crypto jobhunting! His encoding systems are amazing! Also gotta remember your password: 

u?WtKSraq

So we have more personal information!

Let’s make a list of potential credential information:

• Jack
• Johny Graves
• u?WtKSraq

Two usernames and a password. Let’s remember this as we enumerate and explore the website further.

Let’s take a look at that recovery.php page from our gobuster scan earlier.

A login page. Trying jack:u?WtKSraq doesn’t work. Let’s take a look at the source code for the login page.

GQ2TOMRXME3TEN3BGZTDOMRWGUZDANRXG42TMZJWG4ZDANRXG42TOMRSGA3TANRVG4ZDOMJXGI3DCNRXG43DMZJXHE3DMMRQGY3TMMRSGA3DONZVG4ZDEMBWGU3TENZQGYZDMOJXGI3DKNTDGIYDOOJWGI3TINZWGYYTEMBWMU3DKNZSGIYDONJXGY3TCNZRG4ZDMMJSGA3DENRRGIYDMNZXGU3TEMRQG42TMMRXME3TENRTGZSTONBXGIZDCMRQGU3DEMBXHA3DCNRSGZQTEMBXGU3DENTBGIYDOMZWGI3DKNZUG4ZDMNZXGM3DQNZZGIYDMYZWGI3DQMRQGZSTMNJXGIZGGMRQGY3DMMRSGA3TKNZSGY2TOMRSG43DMMRQGZSTEMBXGU3TMNRRGY3TGYJSGA3GMNZWGY3TEZJXHE3GGMTGGMZDINZWHE2GGNBUGMZDINQ=

Another base-like encoded string. Let’s head over to CyberChef and see if we can make sense of this.

Attempting to decode with the different “Base” ciphers through a tiny bit of trial and error gives us what looks to be hex when decoding from base32.

45727a727a6f72652067756e67206775722070657271726167766e79662067622067757220657270626972656c207962747661206e657220757671717261206261206775722075627a72636e7472212056207861626a2075626a20736265747267736879206c6268206e65722c20666220757265722766206e20757661673a206f76672e796c2f3247694c443246

Let’s decode this hex string.

Erzrzore gung gur perqragvnyf gb gur erpbirel ybtva ner uvqqra ba gur ubzrcntr! V xabj ubj sbetrgshy lbh ner, fb urer'f n uvag: ovg.yl/2GiLD2F

Ok this looks a lot like some sort of ROT-encoded string because it has the sort of spacing that English has and also contains punctuation. Only difference is that it’s gibberish at the moment.

Decoding this from ROT13 gives us the final human-readable string.

Remember that the credentials to the recovery login are hidden on the homepage! I know how forgetful you are, so here's a hint: bit.ly/2TvYQ2S

We’ll check this out later. I want to confirm if my hunch about steganography was correct.

Let’s head over to the image of the stegosaurus from the home page.

And transfer it to our local host.

wget http://IP:22/assets/stego.jpg

Now let’s use the steghide tool to extract any obfuscated information that this image holds.

steghide --extract -sf steg.jpg

If we think back to our list of credentials, we had what looked to be a potential password. Let’s supply that as the passphrase.

It worked! We get a file called creds.txt.

Damn. Let’s check out the other image on the home page.

Let’s download it and repeat the same procedure with steghide.

This one doens’t work either…

Let’s check out the shortened link that we got from that encoded hint.

bit.ly/2TvYQ2S

It just brings us to the wikipedia page for Stegosauria but we already know that we have to do some steganography.

Let’s go back to that list of credentials that we have.

• Jack
• Johny Graves
• u?WtKSraq

I wonder who this Johny Graves person is…

Looking him up on Google reveals a MySpace website that looks promising.

He has a post saying the following:

My Favourite Crypto Method:First encode your message with a ROT13 cipher. Next Convert it to Hex. Finally convert the result into Base32.It's uncrackable!

But we already know this…

Ok, so what do we know? The credentials must be in an image on the homepage…

Let’s check out the /assets directory.

We have the following jpg files here.

• header.jpg
• jackinthebox.jpg
• stego.jpg

Well I guess we only have one choice left although I sort of discounted that one at first…

Let’s download it and repeat the process of extracting information from the image.

And we get a cms.creds file which contains the credentials to the /recovery.php login page.

Using these credentials gets us through /recovery.php. We get the following message:

Adding a cmd search query at the end of the url with a command seems to work:

http://IP:22/nnxhweOV/index.php?cmd=whoami

This returns:

I went on a tangent here trying to get a reverse shell but couldn’t figure it out and ended up just sticking to viewing the command output from the page’s source code.

Let’s check out what users we have on this box.

?cmd=ls -l /home

We have a folder here for Jack which we can’t access at the moment. We also have a file called jacks_password_list which we can indeed read.

cat /home/jacks_password_list

Let’s copy this to our local host and use it as a word list.

echo "ContentsOfJacksPasswordList" > jackPasswordList

Note: A fairly obvious point but I am not actually supplying the password list and have just used a placeholder of sorts in the command above instead.

Let’s use Hydra to brute-force Jack’s SSH password.

hydra -l jack -P ./jackPasswordList ssh://IP:80

And we get Jack’s SSH password!

Let’s see if we can SSH in as Jack now with this password.

ssh jack@IP -p 80

And we’re in!

Let’s see what’s in Jack’s home directory.

ls -l

Oh wonderful. The user flag is in this image. We can’t view it from the target machine so let’s transfer it to our local host.

(On our machine)

scp -P 80 jack@IP:user.jpg /root/jack/web

Note: We can use SCP since we know Jack’s SSH password.

Now we open it:

xdg-open user.jpg

Note: xdg-open opens a file with it’s preferred application. It’s just a simple way of opening certain files through the command-line.

“Recipe for Penguin Soup”

PINGU MY BABY NOOOO!

Oh and the user flag is here too.

Now let’s look for ways to escalate our privileges.

Privilege Escalation: Root

Let’s see if Jack can execute commands as another user.

sudo -l

Nothing… Let’s check files with an SUID bit.

find / -type f -perm -u=s 2>/dev/null

The strings binary is vulnerable if it has an SUID bit. And lucky for us, root owns that binary!

Let’s take a look on GTFObins for the exploit.

So we create a variable with the name of the file we want to read and then we use the strings command to read it and since we’re executing strings as root, we can read any file we want.

LFILE=/root/root.txt

./strings "$LFILE"

And we have the root flag!

Conclusion

This was a very fun room! What I’ve noticed is that I’m usually on the right path but I sometimes overcomplicate it. But I will improve by learning from my mistakes and practicing more!

What to remember:

I need to remember that OSINT is of extrememe importance even if I am just doing a CTF and reverse shells are not the be-all and end-all as I can potentially get in through SSH or something else. I’m usually on the right line but get tunnel-visioned on the wrong things.

Commands to practice:

• xdg-open IMAGE.JPG
• scp -P 22 user@IP:file_name_to_copy /local/host/path/to/save/file

Until next time! 🙂