Registry
Overview
Registry was a pretty interesting Linux box. Not much to say here without spoiling this walkthrough, but the approach I found to be successful to own it did not exactly rely on the typical approach but exfiltration. Something I had not seen until I decided to do Registry; my very-first Hard-difficulty HTB box. I hope it is as insightful as it was for me.
Resources
2) Anatomy of a hack: Docker Registry
4) Restic.net
5) Create a REST server repository
6) SSH Port Forwarding Example
Initial Enumeration: Footprinting and Scanning
First of, we need to identify how to reach the system. In other words, we need to identify what are the services available from this machine.
Let's start by adding this machine's IP address to the hosts file and create an alias:
My go-to tools in this phase, which are typically used by many to start enumerating, are:
masscan: very nice port scanning tool that allows finding open ports quickly. To me this is a tool to narrow down the scope of the enumeration so we can focus on open ports only when using nmap.
The options I used are the following:
Similar to this, you could also run something like:
nmap -p- --min-rate=1000 -T4 <hostname>
nmap: I think most people in the information technology and security space know what nmap does. It is a very versatile Port scanning tool which also allows you to use scripts to further target the services found. Just like anything, it can be a useful tool while it can also be damaging if the user is not careful.
What I typically start with when using nmap is:
MASSCAN
NMAP
TCP 80 is accessible as well as TCP 443. TCP 443's certificate gives us some good information in how to approach this one, as well as the CN being docker.registry.htb, which is also a clue. It might be related to Docker Registries. See below the certificate content pulled by nmap.
TCP80 doesn't give me much other that default webserver information:
BUT TCP443, as mentioned above, it gave us the certificate information, and a blank page:
Let's try to enumerate the directories going straight to HTTPS (TCP443), but first let's add this into the hosts file as well.
GOBUSTER
After running gobuster, we found a /v2 directory, which seems to be related to docker registry api. According to the Docker API Documentation, if a 401 Unauthorized is returned, it is related to authentication not being handled properly (well something like that); in other words, accessing it requires you to provide credentials.
When trying it on the browser it prompts for authentication which seems to be using a default admin:admin credentials but only a empty json response comes up.
Looks like we need to do some research on Docker APIs and there is also a good document available on how to hack on Docker APIs and interact with them (see the resources provided).
After interacting with the Docker API a little, we find the repositories, tags, and list of blobs which are important. For this, instead of using the browser, I used curl to see what was available but in a textual format and to possibly determine what I can do with it (scripting?!)
CURL
As the Repository and Tags seems to be bolt-image and latest, let's try pulling a list of Blobs and see what's in there.
Exploitation and Gaining Access
The output is what we need, but we need to download each one as a tgz file and then uncompress to see if there is anything important. To do this I created a simple bash script that will download them as tgz, create logs files to make sure the download goes through as we need and uncompress in the process.
The script can be found HERE!
With this script, we can dump all the blobs we need so we can dig deeper into the files contained on each blob.
Script Output:
While digging through the blob directories, we found the following:
1) SSH key pairs in the 2931a8b44e495489fdbe2bccd7232e99b182034206067a364553841a1f06f791/root/.ssh/ directory.
2) Some scripts of interest (01-ssh.sh and 02-ssh.sh) under 2931a8b44e495489fdbe2bccd7232e99b182034206067a364553841a1f06f791/etc/profile.d/
Inspecting the second scripts gives us the passphrase for the id_rsa private key we found.
Private key passphrase: GkOcz221Ftb3ugog
Let's try these two together:
Listing files in the bolt's user home directory gives us the user flag file (WOOT WOOT!)
Privilege Escalation
Well, so far we tried finding any files/directories where the bolt group has access to but not much came up, but if we try what files are world-readable under /var we see some interesting things:
Basically we can read to the index.php file in the install directory inside /var/www/html and also there seems to be another directory called bolt(?!) where we can read basically all the files inside.
These files look like quite something and by looking at the changelog.md, we find Bolt related to Bolt CMS and its database uses SQLITE and stored in bolt/app/database/bolt.db.
The first lines gives us the version of Bolt so we can look at some exploits if needed, but we need to also move bolt.db locally to use SQLite Browser and find out what is in there.
Retrieve bolt.db using SCP.
Once you retrieve it, open it locally SQLite Browser, try and see what items of interest like the users table could be found and if any create a new file containing the credentials found: sqlite_hash.lst.
See below the content of the file where I copied this hash along with this user:
At this point, we should try and crack these credentials using JohnTheRipper:
JOHNTHERIPPER
WOOT WOOT! We have now credentials to access Bolt CMS.
The credentials are: admin:strawberry
Let's try and enumerate web directories and php files so we can't find out how to access BOLT CMS from this box.
The index.php page should give us (possibly) a login page. This doesn't give us much, but as BOLT CMS is deployed under /var/www/html/bolt, it is possible we are looking at this incorrectly.
Looking at BOLT CMS documentation, the login should be under /bolt, but it isn't the case.
Let's do a test and use https://registry.htb/bolt/bolt as Bolt CMS was not deployed inside /var/www/html as it normally would:
My guess was right so let's access the CMS through the browser.
While looking briefly in the CMS, I noticed File Management is up. After doing some check-ups we notice php files cannot be uploaded, and anything we upload normally goes away (gets deleted) very quickly, but if we upload any files as templates, they stay in perfectly.
One place to check is the configuration (Main Configuration), we can find that the file extensions to upload can be modified (line 240), so we can add php and in a different tab
We can then refresh (Ctrl+F5) twice and upload a simple shell by opening a port we can bind to, and in another tab access this shell.
The sample shell to use is:
NOTE: From testing, it's worth noting that outbound communication is restricted. Let's keep this in mind.
After adding the php file extension to in the main configuration, as explained above, and uploading the rce2.php file as a theme to then load it in the browser, let's quickly run netcat to registry.htb on port TCP4444 in a NEW terminal windows and try to connect.
When connecting:
Let's proceed run sudo -l to check on what we can run as sudo:
Data Exfiltration
Something else we need to look at, restic for backups. From the sudo permissions www-data user has, we see we can run anything through restic to ANY rest repository (a remote restic backup server):
Command available as sudo:
/usr/bin/restic backup -r rest*
While looking into this, we found out we must set a restic server locally in Kali and initialize the repository (see the resources section).
This whole process tells me one way we can approach this is by "exfiltrating data" from registry.htb. We can't do anything else here other than running the restic backup command on anything, as explained above.
Let's setup the restic server (rest-server) in a separate terminal window, locally:
Having done this, if we try to run the backup command, we cannot connect to the rest-server on TCP 8000. Remember we can't connect outbound from registry.htb to almost anything
At this point, we could also attempt to do SSH Remote Port Forwarding to bind a new service to registry.htb from a NEW terminal window:
SYNTAX:
Let's move forward and try this:
Before we do anything let's check on what registry.htb is listening to as remote port forwarding will open TCP 61234 through SSH which is allowed.
Below is exactly what we were looking for:
As TCP 61234 is now being used by registry.htb and rest-server is running on TCP 8000 on my localhost, let's try and run restic from registry.htb.
We need to run the restic command as www-data using http://127.0.0.1:61234/ and try to exfiltrate the root.txt file using the port opened previously through SSH Remote Port Forwarding (used in the Restic Server URL).
AND we were successful at this, but not done yet!
After doing all this, we now need to restore the "backup" of the root.txt file locally so we can access the root flag.
SYNTAX:
restic restore <snapshot_ID> -r rest:<Local_Rest_Server_URL> --target <path_to_restore>
Let's read root.txt and get the Root Flag!
AND WE GOT THE ROOT FLAG!!
If you enjoyed my Walkthrough, thought it was useful AND you are a member of Hack The Box, feel free throw a 'Respect'. Thanks!
Last updated
Was this helpful?