narancs's blog

TryHackMe – IDE walkthrough


TryHackMe IDE room logo

In this post I am showing how I solved the IDE room on TryHackMe. The task was to get the user and root flags from the target.


Nmap scan results:

We can see that there are 3 services running on the target:

  • FTP on port 21, and Anonymous login is allowed
  • SSH on port 22
  • HTTP on port 80

I logged into the FTP server and checked what files are available.

I found that there was a directory called ... (triple dots). Inside this directory I found a file named - (dash).

The file from the FTP server contains some hints for us.

					Hey john,
I have reset the password as you have asked. Please use the default password to login. 
Also, please take care of the image file ;)
- drac.

2 possible usernames are: john and drac. We can also assume that we will need to login to somewhere as john using an easy password, as it has been set to default.

This was the only file I found on FTP, so I moved on to enumerating the HTTP server. I used gobuster to find directories or files (html, php, txt). However, I was not able to find anything, except the default Apache page.

At this point I was stuck, so I used nmap again to scan all ports. There was another HTTP server running on port 62337.

From the HTTP title, we can already see that it is running a web application called Codiad and the version is 2.8.4.

If we go to the website on port 62337, we see the login page of Codiad. Since I knew the username that we need to use is most likely john, I started checking few of the easy passwords before using hydra to brute-force. The password that was accepted is ‘password’.

Codiad page after login


After logging in, I checked whether there are any known exploits for this particular version of Codiad. I found an RCE exploit on Exploit DB:

The exploit code is relatively long, so I quickly checked how it actually works. I found that if we do not provide the required number of arguments, it will print help about usage and examples.

For the URL we need to provide the URL of the web application running on port 62337. The IP and PORT parameter is required for a reverse shell that the script will trigger. So the IP parameter has to be the IP that we have on THM network. The PORT parameter has to be an unused port on our machine, where we will need to start a listener.

If we run the script with the correct parameters, it will actually provide us the 2 commands that we need to run to start the 2 listeners required for the exploit. Once the 2 listeners are started, answer ‘Y’ and the exploit will start.

I received a shell as www-data user, then I started enumerating the target. There was only 1 user who had home directory: drac. The user.txt file was in there, but www-data user did not have the permissions to read it.

User flag

I had to find a way to escalate privileges to drac user. When I checked other files in drac’s home directory I noticed that the .bash_history file is readable by anyone (it should only be readable by the user). It contained only a single line, that was a mysql command.

					www-data@ide:/home/drac$ cat .bash_history 
mysql -u drac -p '*****HIDDEN*****'

The command revealed a password that was used for the mysql user ‘drac’. The password of the Linux user was the same, so we can switch to drac user with the password we found and get the user flag.

Root flag

I checked sudo privileges for drac user.

					drac@ide:~$ sudo -l
[sudo] password for drac: 
Matching Defaults entries for drac on ide:
    env_reset, mail_badpass,
User drac may run the following commands on ide:
    (ALL : ALL) /usr/sbin/service vsftpd restart

The user has permission to restart the vsftpd service with sudo. If we could modify the unit file of vsftpd, we could specify what command should run when the service is started.

We can find out the location of the unit file if we check the service status with the following command:

					/usr/sbin/service vsftpd status

The unit file is in the output:

					Loaded: loaded (/lib/systemd/system/vsftpd.service; enabled; vendor preset: e

The service file is located at /lib/systemd/system/vsftpd.service. Check the permissions of the file:

					drac@ide:~$ ls -l /lib/systemd/system/vsftpd.service
-rw-rw-r-- 1 root drac 248 Aug  4 07:24 /lib/systemd/system/vsftpd.service

The drac group has write permission of the file, so we can modify it. The contents of the file:

Description=vsftpd FTP server
ExecStart=/usr/sbin/vsftpd /etc/vsftpd.conf
ExecReload=/bin/kill -HUP $MAINPID
ExecStartPre=-/bin/mkdir -p /var/run/vsftpd/empty

We can modify the ExecStart= option to any command. Then if we restart the service with sudo, that command will be executed as root user.

I used chmod command to change the permissions of the /etc/shadow file, so I can change the password of the root user.

					ExecStart=/bin/chmod 777 /etc/shadow

Then I restarted the service:

					systemctl daemon-reload
sudo /usr/sbin/service vsftpd restart

The permissions of the /etc/shadow file were set to 777, so I was able to modify it.

First I generated a new password hash with openssl:

					openssl passwd -1 password123

Then I edited /etc/shadow, and changed the password hash of root for the output of the openssl command. Finally I switched to root user using ‘password123’ as password, and got the root flag from /root/root.txt.


I was able to root the machine in the IDE room on TryHackMe. During the enumeration phase I found a file on the FTP server that contained critical information, including 2 possible usernames. I found a web server running a web application called Codiad. Using the information found on FTP I was able to login to the web application.

Then, I found an exploit for a remote code execution vulnerability in Codiad. With the exploit I gained initial access to the target. There was only one user account (drac) who had home directory. The .bash_history file of the user was readable by anyone. The file contained the password of the user, so I was able to escalate my privileges.

With drac user I had permission to restart the vsftpd service with sudo command. The unit file of vsftpd was writable by drac. So I was able to modify the unit file to run chmod on /etc/passwd when I restart the vsftpd service as root. Then I gained root access by updating the password of root in /etc/passwd.

Table of Contents

Notify of
Inline Feedbacks
View all comments

Related posts

Would love your thoughts, please comment.x