Registry
Gaining Access
Nmap scan:
$ nmap -p- --min-rate 5000 10.129.89.161
Starting Nmap 7.93 ( https://nmap.org ) at 2023-03-08 05:23 EST
Nmap scan report for 10.129.89.161
Host is up (0.021s latency).
Not shown: 65532 closed tcp ports (conn-refused)
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp open httpsBoth the websites point towards a nginx default page.
Web Enum
I ran a gobuster scan on both of these, and found an /install directory with some random characters.

There was also a /bolt endpoint that shows a basic sample site.

Bolt CMS was a possibility of exploitation here. A feroxbuster search reveals this is the case:

Based on the Bolt CMS Repo, we can check changelog.md to see the version and find that this is Bolt 3.6.4.

This was a rather old machine, so there were RCE exploits available if I could find the credentials for the administrator. However, there were no credentials for me to exploit, and I could not do much with this. I was clearly missing something.
I went back to the /install directory and downloaded the output as a file, only to find that it was a gzip file.
There was something in here, but it kept having a unexpected EOF error when trying to decompress it. To overcome this, we can use the zcat command to extract its contents. This was the output:
Interesting, we have a private docker registry hidden on this server. I tested out the docker directory endpoint, and eventually found it as a subdomain at docker.registry.htb.
docker.registry.htb
I ran a gobuster scan on this and found this interesting endpoint:
When trying to access it, it requested for credentials:

Using admin:admin worked. I was forwarded to what looked like a web API. I didn't have any commands to use, so doing some basic research for Docker Registry API commands was the next step. As usual, Hacktricks had some commands.
So we have one repository here. We can pass the credentials we used earlier to view more information.
This confirms that we can download one of the blobs and perhaps find some files in it.
When viewing the file contents, we will find a file at /etc/profile.d/01-ssh.sh.
I downloaded the other files to see if there were any other interesting things. Eventually, I did find a SSH private key

With these, we can SSH in as bolt.

Privilege Escalation
Bolt SQLite
With access to the machine, I wanted to enumerate the bolt config files to see if I can find anything new. There was a database file bolt.db at /var/www/html/bolt/app/databases. I transferred this over using scp.
We can then use sqlite3 to enumerate this.
We have a hash here that is cracked to give strawberry.

Now, we can login to the bolt CMS and continue our enumeration.
Bolt Dashboard
We can login with admin:strawberry to the admin dashboard.

Great! Within the password hash, we saw another hint in the form of shell.php. As the administrator for bolt, we can actually create PHP files in the File Management tab. We can drop in a webshell and easily get an RCE as the next user.
Originally, this is not allowed since .php files are not included in the allowed types of files. However, as the administrator, we can change the config.yml file in Configuration > Main Configuration.

Then we can upload whatever files we want.
However, I was unable to get a reverse shell through conventional means...
Reverse Shell Attempt #2
The first reverse shell using a simple bash one-liner did not work for some reason. Probably was blocking all forms of remote connections.
To circumvent this, we can simply have the reverse shell connect back to a listener port on localhost using the SSH shell we got earlier.

Restic
Within the files earlier, I did see a backup.php file that was probably being used.
This file was using restic to store encrypted backups of files onto a certain directory.
I also found that the www-data user could execute sudo commands using restic.
Based on docs, it seems that this was using a REST repository to host the files. Here's a Git Repository to explain what a rest server is:
Since the sudo privilege had a wildcard in it, the exploit was to create a basic rest-server and backup the entirety of the machine onto it. We can host the rest-server on our Kali machine and port forward it to this machine to make it accessible.
First, we can start rest-server on our machine and do the port forwarding:
Then we need to create a repository on our rest-server for restic and backup the /root directory there:
Then we can access this repo from our machine easily.
From here, we can dump the private SSH key of the root user.
Then we can SSH in as root.

Cool machine. Really good despite being like 3 years old.