GitHub
Page cover

Week 5. Skyfall

TL;DR

This is an Ubuntu 22.04.3 LTS machine which provides a MinIO-based cloud storage service. The MinIO root credentials are disclosed using 403 bypass technique and exploiting CVE-2023-28432. Once we have access to the MinIO storage we can download a file system backup which contains an HashiCorp Vault token. This will be used to get a one-time SSH password which will provide us a shell to get the user flag. Escalation is obtained by enumerating the sudoers configuration and abusing a rule that allows the low-priv user to unseal the HashiCorp Vault without a password.

KEYWORDS

MinIO, 403 bypass, CVE-2023-28432, HashiCorp Vault, sudo escalation.

REFERENCES

https://book.hacktricks.xyz/network-services-pentesting/pentesting-web/403-and-401-bypasses#path-fuzzing

https://www.cvedetails.com/cve/CVE-2023-28432

https://min.io/docs/minio/linux/reference/minio-mc.html

https://developer.hashicorp.com/vault

https://developer.hashicorp.com/vault/api-docs/secret/ssh

https://developer.hashicorp.com/vault/docs/secrets/ssh/one-time-ssh-passwords

ENUMERATION

Port scan.

Fuzz for subdomains.

Enumerate the web site on port with Firefox, a login portal comes into view at http://demo.skyfall.htb/login

Try several common credentials, access is granted with guest:guest, and a dashboard comes into view.

If we continue to enumerate the site with Firefox, we make to following findings:

At this point, having found several points of entry, we can consider the enumeration phase finished and start the exploitation.

USER

Investigate ways to bypass the MinIO metrics 403 code here: https://book.hacktricks.xyz/network-services-pentesting/pentesting-web/403-and-401-bypasses#path-fuzzingFollowing the indicated procedure for path fuzzing, first download an unicode wordlist from here: https://raw.githubusercontent.com/danielmiessler/SecLists/master/Fuzzing/Unicode.txt

Trim the file to remove duplicate characters, resulting in a list of 1024 characters.

Prepare a request.txt file for fuzzing the "MinIO metrics" URI.

Fuzz the URI with ffuf to discover an unicode to bypass the 403 status.

So the unicode character %0A will allow us to bypass the 403 status. Entering the URI: http://demo.skyfall.htb/metrics%0a we reach a site with the server metrics and lots of server-related info.

This also includes the path of the production endpoint, which is running at: http://prd23-s3-backend.skyfall.htb/minio/v2/metrics/cluster. Entering this URL in Firefox displays additional information.

Now we know we are dealing with a MinIO server. Searching for MinIO vulnerabilities we come across this one: https://www.cvedetails.com/cve/CVE-2023-28432

To exploit this vulnerability, browse http://prd23-s3-backend.skyfall.htb/minio/bootstrap/v1/verify with Firefox and capture the traffic. A message is received "All access to this resource has been disabled". Send to repeater and change the method to POST, the application leaks the MinIO root user and password, just as stated in the CVE.

Looking at the MinIO documentation (https://min.io/docs/minio/linux/reference/minio-mc.html), it seems we can use a binary called mc to interact with the server from the command line.

Install the tool following the procedure depicted in the documentation.

Configure the client to use with the disclosed root MinIO and password.

Now we can use the client to dump MinIO info.

List the buckets and objects.

Here you can notice also a list of potential usernames.

Let's download the home_backup files and inspect the contents.

Unpack and inspect the contents of the V2 file home_backup.v2.tar.gz --vid 2b75346d-2a47-4203-ab09-3c9f878466b8, there is a .bashrc configuration file with an API address and an access token for an HashCorp Vault running on the host.

Vault is an engine to securely store passwords, certificates, encryption keys, etc. (https://developer.hashicorp.com/vault).

Having disclosed the API address and the token, we are in a position to get access to the secrets stored in the Vault, including SSH secrets and one-time passwords (OTP), as indicated in the SSH part of the documentation: https://developer.hashicorp.com/vault/api-docs/secret/ssh

Vault creates an OTP for each SSH authentication attempt instead of keeping a fixed password for each user. Every time a client wants to SSH into the host, he needs to request an OTP from the Vault server which is only valid for that particular SSH login. In order to supply the OTP, the server needs username/password or a token. We do not have user credentials, but we have obtained the token from the .bashrc file.

Following Vault documentation, first we enumerate OTP roles present in the host. We can do it with curl

Or from command line using the vault binary (download from https://releases.hashicorp.com/vault/1.15.5/vault_1.15.5_linux_amd64.zip and unzip). For this, we need to export environmental variables first, then request the Vault roles.

Next, request a key for dev_otp_key_role using the token (the token is not valid for getting a key for admin_otp_key_role).

Or with the vault command line binary.

The key provided is the OTP password for the SSH session. Notice the OTP expires very soon. As indicated in the API documentation, the token status can be checked by querying the OTP key against the endpoint /ssh/verify

In the documentation (https://developer.hashicorp.com/vault/docs/secrets/ssh/one-time-ssh-passwords) there is a way to automatize the process to request a key and immediately SSH into the host (had to install the sshpass package first), so you make sure the token does not expire between the two steps.

Also, note the user nobody is not actually a system user. If you try with the list of potential usernames disclosed before, you'll find user askyy is a valid username for SSH login.

Bearing all this in mind, the command to get an SSH session for user askyy is the following.

Which is valid to get the user flag.

ROOT

Start from an SSH session for user askyy

Take the opportunity to enumerate the user and the system.

Check if askyy is a sudoer.

It seems askyy is allowed to unseal the vault as root, no password will be prompted. Check unseal command help for options available.

So, according to sudo -l we can unseal the vault as root using the vault-unseal with verbose (option -v), debug (-d) or using a config file (-c /etc/vault-unseal.yaml).

Let's try to unseal the vault in verbose mode.

The application dumps the master key and says more info will be provided in debug mode. Let's repeat repeat in debug mode (option -d).

The debug info is stored in a log file called debug.log, but since it is created under the root context (sudo) we cannot read it.

However, if we run the command again the new results will be appended into any existing debug file.

Notice the debug.log file size has increased from 590 bytes to 1.2 KB, meaning the results have been appended to the existing log.

Delete the existing debug.log file and create a new one with touch, so it is owned by askyy

Unseal again, this time we are able to read the file debug log since it is appended to the existing one (owned by askyy).

Application dumps the vault master key, which we can use to generate an OTP and SSH in the same way as before. Just remember to update the role to admin_otp_key_role, and SSH as root.

You are root.

PreviousWeek 4. POVNextWeek 6. Crafty

Last updated