◻️SKYFALL
IP: 10.10.11.254 - Platform: Linux- Difficulty: Insane
RECON
Nmap
nmap -sV -sC -v -T4 -p- 10.10.11.254
Initiating Connect Scan at 00:46
Scanning 10.10.11.254 [65535 ports]
Discovered open port 22/tcp on 10.10.11.254
Discovered open port 80/tcp on 10.10.11.254
Host is up (0.045s latency).
Not shown: 65533 closed tcp ports (conn-refused)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 8.9p1 Ubuntu 3ubuntu0.6 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 256 6570f71247073a888e27e9cb445d10fb (ECDSA)
|_ 256 74483307b7889d320e3bec16aab4c8fe (ED25519)
80/tcp open http nginx 1.18.0 (Ubuntu)
|_http-favicon: Unknown favicon MD5: FED84E16B6CCFE88EE7FFAAE5DFEFD34
|_http-server-header: nginx/1.18.0 (Ubuntu)
| http-methods:
|_ Supported Methods: GET HEAD
|_http-title: Skyfall - Introducing Sky Storage!
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernelFFUF
ffuf ends up discovered a demo subdomain. Let add it into /etc/hosts file and access it.
GAINING FOOTHOLD
Enumerating on the website
No valuable points of exploitation were discovered using automation tools such as the Nikto vulnerability scanner. However, while searching for other directories, we come across skyfall.htb/assets and receive only a 403 code in response. Let's shift our focus to the other subdomain since we haven't had any luck breaking into it yet.
Well, there is no need to use any tools to get around authentication since we are presented with the default credentials. Let hop in and look around to see if you can find anything helpful.
Upon closer inspection, it appears that uploading a normal malicious payload does not give us any shell. We learn something about this system from the dashboard. It supposed to be a MinIO Object Storage System.
Notice that we have 403 Forbidden on MINIO Metrics. Fear not, because there are two ways around this.
403 Bypass - Path Fuzzing
The 403 Forbidden response code signifies that although the client is authenticated, they do not possess the necessary permissions to view the resource that they have requested. When a server wishes to block a client from accessing a resource, it usually uses this response. This can happen when the resource is being purposefully hidden or restricted. There are many ways to bypass this:
HTTP Methods Fuzzing: sending the request again using a different method, such as POST, PUT, or PATCH
HTTP Headers Fuzzing: sending a request with an altered HTTP header to the intended server. The most often altered headers are X-Forwarded-For, Referer, and Authorization.
Path Fuzzing: the method we intended to use. Work by adding symbols, spaces, tabs,... to bypass the filter.
HTTP Request Smuggling: manipulated HTTP requests that take advantage of differences in how various parts of the HTTP request processing chain handle request data.
In this case, by adding a simple %0A (or %20 should be working) to the URL, we would get access into the metrics panel:
Examining the Internal Metrics, we discovered a fascinating subdomain:
Adding it into our hosts file and see what in there:
Bypass by LFI
So, we discovered right away that this kind of system is a cloud storage system. And metrics, right? Possibly requires a cloud-native monitoring platform on the back? If we look at the official documentation for MinIO, it should be noted that:
MinIO exports Prometheus compatible data by default as an authorized endpoint at
/minio/v2/metrics/clusterMinIO exports Prometheus compatible data by default which is bucket centric as an authorized endpoint at
/minio/v2/metrics/bucket
Additionally, we can scrape per node metrics from MinIO in /minio/v2/metrics/node
Using the URL Fetch function, we can get LFI by modifying the request as followed:
or based on the previous info:
Leaking environment varibles through the use of CVE-2023-28432
It was discovered that MinIO has an information disclosure vulnerability (CVE-2023-28432) that can be used to view sensitive data in the following method:
Here is the modified request:
With both MINIO_ROOT_USER and MINIO_ROOT_PASSWORD in hand, we can now access the system's data by mc.
Proceed to create an alias for an S3-compatible service after installing the client.
Upon examining the content, versions, and archives for a while, I came across home_backup.tar.gz in the directory for askyy,which caught my attention. Use this command to download it:
Since that file contained nothing helpful, I looked up its prior occurrence:
After extracting the versions, get the file:
Within it is a file containing the SSH private key (You won't be using this to get your user flag anytime soon)
.bashrc gave us some interesting pieces in this puzzle:
Looking up on the internet, we discovered that this system uses Vault.
Gaining access through Vault OTP
With the provided credential, we could get access by Vault SSH. For SSH authentication on a network, Vault can generate a one-time password (OTP) each time a client wishes to SSH into a remote host.
So, basically, Vault server receives an OTP request from an authenticated client. An OTP is sent by Vault and returned if the client is approved. The client connects to the intended target host via SSH authentication using this OTP.
Download that tool and set the environment varibles:
Verify that the token value is valid:
Credentials can be supplied to the login endpoint to fetch a new Vault token via this method:
Then, log in with:
Boom! We got the user!
PRIVILEGE ESCALATION
I didn't expect this system to be fairly straightforward.
Just the normal sudo -l and look at the output. Run vault-unseal as root and we could see that:
The output states that the master token was found, but you need to start debug mode to view the details. So, the output option (-d) creates the debug.log but it's only readable by root. We can trick it to leak the token by create a debug.log file and change its permissions to askyy, then dictate the tool to output it into our file.
With that token, we can replicate the same way how we gain initial access to the machine.
Set the environment varibles:
Valid that token then obtain a new Vault token for the OTP:
And there you go! Root access, hooray!!!!!!!!!!!!!
Verdict
Undoubtedly, a challenging machine to take control of. However, I'm glad that I don't have to chain together several exploits to obtain a shell alone. Granted, an insane machine ought to be so difficult that you would need to create a unique payload or write a script to take advantage of a configuration error in order to obtain root access, but this need not always be the case.
In my opinion, the challenge with this machine lies solely in the amount of time you have to dedicate to studying every little detail and experimenting with ideas you would never have considered.
Last updated