Ide

Ide

Room link: https://tryhackme.com/room/ide

Scanning

I ran an aggressive nmap scan to begin. It looked like there are 3 services running on the system, FTP, SSH, and HTTP.

ajread@aj-ubuntu:~/TryHackMe$ nmap -A [Remote IP]
Starting Nmap 7.80 ( https://nmap.org ) at 2022-03-14 20:17 EDT
Nmap scan report for [Remote IP]
Host is up (0.094s latency).
Not shown: 997 closed ports
PORT   STATE SERVICE VERSION
21/tcp open  ftp     vsftpd 3.0.3
|_ftp-anon: Anonymous FTP login allowed (FTP code 230)
| ftp-syst: 
|   STAT: 
| FTP server status:
|      Connected to ::ffff:10.8.1.236
|      Logged in as ftp
|      TYPE: ASCII
|      No session bandwidth limit
|      Session timeout in seconds is 300
|      Control connection is plain text
|      Data connections will be plain text
|      At session startup, client count was 3
|      vsFTPd 3.0.3 - secure, fast, stable
|_End of status
22/tcp open  ssh     OpenSSH 7.6p1 Ubuntu 4ubuntu0.3 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey: 
|   2048 e2:be:d3:3c:e8:76:81:ef:47:7e:d0:43:d4:28:14:28 (RSA)
|   256 a8:82:e9:61:e4:bb:61:af:9f:3a:19:3b:64:bc:de:87 (ECDSA)
|_  256 24:46:75:a7:63:39:b6:3c:e9:f1:fc:a4:13:51:63:20 (ED25519)
80/tcp open  http    Apache httpd 2.4.29 ((Ubuntu))
|_http-server-header: Apache/2.4.29 (Ubuntu)
|_http-title: Apache2 Ubuntu Default Page: It works
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 17.79 seconds

A full nmap scan showed a random high port as well.

Enumeration

I first looked into the anonymous ftp login. There was a file called - nested within a the ... directory.

I pulled the - file from the FTP server and it appeared to be a note. The note itself said the following:

So, I can infer that there are two users named john and drac. User john must have a simple password. Before looking back at the random open high port, I ran hydra against the FTP and SSH service with username john and a simple password list. I was unsuccessful so I knew the credentials must be used somewhere else on the system.

Initial Access

I checked out the random high port and found that it was a Codiad IDE interface running on port 62337. I tried to login with a default password for user john and authenticated! I found a Codiad RCE on exploitdb: https://www.exploit-db.com/exploits/49705 that requires authentication. The RCE appears to be able to write to Codiad within components/filemanager/controller.php and execute system commands like nc or /bin/bash that can be used to call back to a remote machine.

Before running the exploit, it required me to set up a VPS for the connection. So, in one terminal, I set up reverse shell in bash that would pipe to another listener on my machine from the remote connection.

In another terminal on my local machine, I set up the listener on port 10000 to receive the final reverse shell from the remote machine.

After everything was set up, I ran the exploit and pointed it as the Codiad IDE with the john:[REDACTED] credentials.

And, I received a shell!

But, I was only the www-data user. I needed to move to the drac user in order to see the user flag.

After some looking around, I found credentials within user drac bash history.

I used ssh to log in with the credentials above and found the flag!

Privilege Escalation

Using sudo -l it looked like I could restart vsftpd as root.

I looked at the vsftpd.service file and noticed that I had write permissions. Since ExecStartPre contains additional commands that are run after ExecStart, I added another ExecStartPre field to execute a reverse shell using bash after the original ExecStartPre. (This page was a great resource: https://www.freedesktop.org/software/systemd/man/systemd.service.html if interested).

I started a listener on my local machine to catch the elevated reverse shell on port 8888 above.

Then, I had to reload the daemon on the remote machine before restarting vsftpd.

Finally, I was able to restart the service as root on the remote machine.

And it called back to my local machine with an elevated shell!

Last updated