VulnNet: Internal Write-Up
VulnNet: Internal is a boot2root room on TryHackMe. It has Easy difficulty. After getting the Redis password from NFS, it was possible to get the password for Rsync. With that password it was possible to upload a authorized_keys file. After connecting to the machine over SSH, there was a Teamcity instance running behind the firewall. The Teamcity port was forwarded to the attacker machine. This allowed connecting to the instance. Login was possible with authentication keys, which could be obtained through logs. After loggin into Teamcity, a malicious build pipeline was created. This pipeline has set the SUID bit on /bin/bash. This allowed elevated privileges to root.
After running the Nmap scan
sudo nmap 10.10.37.188 -p- -vv -oN nmap/all_ports a lot of ports were discovered:
First of all connection to SMB was tried. Running
smbmap -H 10.10.37.188 showed
shares was readable without authentication:
Connecting to the share showed two directories: temp and data.
The directories were further inspected. The data directory contains two text files called “data.txt” and “business-req.txt”. The “temp” directory contains a text file called “services.txt”.
All three files were downloaded to the attacker machine and inspected further. “services.txt” contains the first flag:
Next NFS was further inspected. It allowed access to the directory /opt/conf:
Next this directory was mounted to the attacker machine with the command
sudo mount -t nfs 10.10.37.188:/opt/conf ./conf_mount. The directory structure is as follows:
Interestingly, the redis directory contained the redis.conf file:
With this file it was possible to recover the Redis password:
With that password it was possible to connect to the Redis instance.
The next flag was inside the “internal flag” key. It was also possible to obtain the authentication credentials for the Rsync service.
Next the Rsync service was inspected. First of all a Nmap scan with the script “rsync-list-modules” against port 873 was run. This revealed the directory name “files”.
It was possible to copy the files with
rsync -av rsync://email@example.com/files ./rsync_files. Inside the directory there was the user flag.
Next it was time to upload an authorized_keys file. First an SSH key was generated:
Next the public key was copied to
sys-internal/.ssh/authorized_keys. After uploading the .ssh directory with the previously obtained password and the command
rsync -av sys-internal/.ssh/ rsync://firstname.lastname@example.org/files/sys-internal/.ssh , it was possible to connect via SSH:
During enumeration there was an interesting directory called “TeamCity” inside the root directory (“/”). TeamCity is a CI/CD Server build by JetBrains. These build server often run as root. So it is a good point for privilege escalation.
The README revealed that TeamCity is running on port 8111:
Next it was checked if anything is listening on port 8111. And indeed there was a service listening.
So next port 8111 was forwarded to the attacker machine with the command
ssh -i vulnnet email@example.com -L 8111:localhost:8111. This allowed the attacker to display the web app in a browser.
The attacker chose the “Log in as a Super user” option. The web app asked for a authentication token.
The authentication token could be found inside the logs on the machine:
With this token, it was possible to login to the web interface:
Next a new project was created with the name “test2”:
After the project was saved and a new build configuration was created by clicking the button “Create build configuration”:
“test build” was chosen as the build configuration name:
Next a build steps was added by navigating to “Build Steps” and clicking on the button “Add build step”:
The build script contained the command
chmod +s /bin/bash. This will add the SUID bit to the
bash binary. This was used to elevate current privileges on the machien to root.
Finally the build pipeline was run:
After the pipeline finished successfully, the SUID bit was set on
bash. This allowed for root privileges. The privileges were used to obtain the root flag at
First of all the SMB share should be protected by authentication. Especially if it contains sensitive data and anonymous login is not needed. It is also recommended to protect the NFS. It contains configuration files with passwords.