Web

Nmap discovered a web server running on the target port 8080

Webroot i got re-directed to a login page to a gitbucket instance

BitBucket

GitBucket is a web-based Git repository manager that allows users to host and manage Git repositories. It is written in Scala and runs on the JVM. GitBucket provides a user-friendly web interface for managing Git repositories, as well as features such as pull requests, issue tracking, and wiki pages. It is open source software and can be self-hosted, making it a popular alternative to other Git repository managers like GitHub and GitLab.

I tried some default/weak credentials and nothing worked

The instance supports sign-in feature.

While I was attempting to create a testing account, I found out that it also supports file upload for a profile image This could be an attack vector

The web application checks for username during the registration. This error message feature can be abused for username enumeration

There is the root user

admin is reserved

I signed-up with the information above

Although it says that Not Found, I seems to be successfully signed-in as the tester user

I can see that there are 2 repositories within the GitBucket instance made by the root user While I am unsure of the 2nd repo, the 1st one, root/seal_market, appears to be the web application running on the target port 443

/root/seal_market

While it is pretty much confirmed that this repo contains the web application running on the target port 443, I see some interesting information in the ToDo section. There is also a issue highlighted.

Another thing to note here is that alex is the user that authored the repo

app

The app directory is contains the web application on the target port 443. I can also see the /admin/dashboard directory within that I was unable to enumerated

I will check the index.html file

index.html

I downloaded the index.html file and opened it up using Firefox. It just shows registered user information such as their user-agents. It doesn’t seem to have any code execution

Moving on

nginx

The nginx directory contains configuration files and sub-directories for the nginx instance It looks like they just copied and pasted and the /etc/nginx directory

site-enabled/default

┌──(kali㉿kali)-[~/archive/htb/labs/seal]
└─$ cat ~/Downloads/default
 
ssl_certificate /var/www/keys/selfsigned.crt;
ssl_certificate_key /var/www/keys/selfsigned.key;
ssl_client_certificate /var/www/keys/selfsigned-ca.crt;
 
server {
	listen 443 ssl default_server;
	listen [::]:443 ssl default_server;
	root /var/www/html;
	ssl_protocols TLSv1.1 TLSv1.2;
	ssl_verify_client optional;
	
	# Add index.php to the list if you are using PHP
	index index.html index.htm index.nginx-debian.html;
 
	server_name _;
 
	location /manager/html {
		if ($ssl_client_verify != SUCCESS) {
			return 403;
		}
		proxy_set_header        Host $host;
		proxy_set_header        X-Real-IP $remote_addr;
		proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header        X-Forwarded-Proto $scheme;
		proxy_pass          http://localhost:8000;
		proxy_read_timeout  90;
		proxy_redirect      http://localhost:8000 https://0.0.0.0;
	}
 
 
	location /admin/dashboard {
		if ($ssl_client_verify != SUCCESS) {
			return 403;
		}
		proxy_set_header        Host $host;
		proxy_set_header        X-Real-IP $remote_addr;
		proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
		proxy_set_header        X-Forwarded-Proto $scheme;
		proxy_pass          http://localhost:8000;
		proxy_read_timeout  90;
		proxy_redirect      http://localhost:8000 https://0.0.0.0;
	}
 
        location /host-manager/html {
                if ($ssl_client_verify != SUCCESS) {
                        return 403;
                }
                proxy_set_header        Host $host;
                proxy_set_header        X-Real-IP $remote_addr;
                proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header        X-Forwarded-Proto $scheme;
                proxy_pass          http://localhost:8000;
                proxy_read_timeout  90;
                proxy_redirect      http://localhost:8000 https://0.0.0.0;
        }
        
	location / {
                proxy_set_header        Host $host;
                proxy_set_header        X-Real-IP $remote_addr;
                proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header        X-Forwarded-Proto $scheme;
                proxy_pass          http://localhost:8000;
                proxy_read_timeout  90;
                proxy_redirect      http://localhost:8000 https://0.0.0.0;
	}	
}

The site-enabled/default file shows the SSL configuration for the Nginx web server The configuration above explains why I was getting a code 403 upon visiting /manager/html because the server requires clients to go through that $ssl_client_verifty in order to present the resource at /manager/html

It uses TLSv1.1 and TLSv1.2 ssl_verify_client is set to optional

The configuration also specifies both private and public (certificate) key

tomcat

Tomcat stores credentials in the tomcat-users.xml file

Authentication with a credential doesn’t seem to be configured as those lines are commented out

issue

The issue is opened by the alex user

Clicking into the issue itself reveals the context. It’s about implementing the mutual authentication feature in the target Tomcat instance Another user, luis, replied that it’s viable and suggested to have Nginx

The mutual authentication in this context must be the SSL certificate that I enumerated earlier

root/infra

Clicking into the root/infra repository reveals what appears to be Tomcat related data The comment shows those are added by Tomcat playbook

A Tomcat playbook is a set of instructions or a script that automates the deployment, configuration, and management of Apache Tomcat servers. It is used with configuration management tools such as Ansible, Chef, or Puppet to manage the installation and configuration of Tomcat instances across multiple servers.

A typical Tomcat playbook might include tasks such as the following:

Installing Java on the target machines
Downloading and installing the appropriate version of Tomcat
Configuring Tomcat’s server.xml file
Creating and deploying web applications to Tomcat
Setting up SSL encryption and configuring HTTPS
Configuring Tomcat to run as a service
Managing users and access control for the Tomcat Manager application
Monitoring Tomcat’s performance and health

By using a playbook, administrators can ensure consistent and reliable deployment and management of Tomcat servers, which can save time and reduce errors compared to manual configuration. Additionally, playbooks can be version-controlled and shared among team members, allowing for collaboration and reproducibility.

site.yaml

The site.yaml file shows the general configuration for the playbook It notes that the playbook deploys a simple standalone Tomcat 9 server

The main.yaml file inside the /role/tomcat/tasks sets the detailed configuration for the Tomcat instance

It seems to be using the java-1.8.0-openjdk package for the backend and apache-tomcat-8.0.61 I am unsure why it shows apache-tomcat-8.0.61 when the earlier enumeration shows the playbook is for Tomcat 9

Commits

Since this isn’t a static deployment, but a development made over a course of time, I see many changes made

CLEARTEXT Credential

One of the commits made by the luis user had the tomcat-users.xml files changed. the previous version had a credential in it; tomcat:42MrHBf*z8{Z% They must have removed it as they went for the mutual authentication, but they forgot to delete the history

So while I think that this credential itself at this point would be rather irrelevant to the Tomcat instance for 2 reasons

The Tomcat instance had its authentication updated
Still unable to access /manager/html due to the mutual authentication set by the Nginx configuration file

However, I can still test it out for password reuse

Password Reuse

While password spraying attack failed against the target SSH server, the password belongs to the luis user, valid for the GitBucket instance Much expected result given the fact that the commit was made by the luis user

InfoSec LAB

Explorer

Seal_Web_8080

Web