Jupiter | HTB | Grafana | raw SQL Query | Shadow Simulator RCE | Sattrack

10/30/2023

Jupiter is a medium-level challenge that kicks off with a Grafana dashboard. The journey begins with the quest to pinpoint a potential entry point within Grafana, allowing for the execution of raw SQL queries by the PostgreSQL database, ultimately leading to code execution on the host. Further exploration involves the exploitation of a cron job within the Shadow Simulator to pivot towards the next user. Subsequently, the path to success includes gaining access to a Jupyter Notebook, providing additional opportunities for advancement. Ultimately, the culmination of this endeavor leads to achieving a root shell through the exploitation of a satellite tracking program called sattrack.

First, add “jupiter.htb” to our hosts file:

/etc/hosts

Enumeration

nmap -p- -sCV — min-rate=1000 10.10.11.216

nmap

Two ports are open: 80,22. let’s browse port 80.

let’s scan for directories:

nothing fancy.

let’s fuzz for additional subdomains:

ffuf

We use the `-fs` flag to filter out HTTP responses based on their size. Specifically, we’re filtering responses that have a size of 178 bytes to limit false positives. The `-mc` flag allows us to match specific HTTP status codes. By default, it matches status codes 200, 204, 301, 302, 307, 401, 403, 405, and 500.

Let’s add this subdomain to our hosts file:

Browsing to this subdomain, we can see that it is loading Grafana:

dashboard

Let’s poke around with the application and intercept the requests. Click on the dashboard:

initial requst

second request

next request

At the “/api/ds/auery’ endpoint, There is a POST request that includes a ‘rawSql’ field and specifies the database type as PostgreSQL.

What will happen if we edit the ‘rawSql’ field and send raw queries into the database?

It returned all the details about the database version. Attempting to fetch the username and database name:

database name

name

Now, it is time to get RCE using this link:

#PoC
DROP TABLE IF EXISTS cmd_exec; 
CREATE TABLE cmd_exec(cmd_output text); 
COPY cmd_exec FROM PROGRAM 'id'; 
SELECT * FROM cmd_exec; 

RCE — fetch id

RCE — fetching whoami

Shell

shell

When I send this, I get a shell. Let’s make our shell interactive:

interactive shell

There are two users in the /home directory but user postgress can not access these directories.

Let’s see processes:

ps auxww

It is running Jupyter notebook as jovian with notebooks in the /opt folder.

postgres user can’t access that notebook.

pspy

To further examine the processes, I’ll use pspy to monitor any cron jobs:

It seems to be running shadow-simulation.sh and using the network-simulation.yml file from /dev/shm. What is shadow simulator? I searched for it and found The Shadow Simulator github repository.

Shadow is a discrete-event network simulator that directly executes real application code, enabling you to simulate distributed systems with thousands of network-connected processes in realistic and scalable private network experiments using your laptop, desktop, or server running Linux.

Let’s look at its content:

It sets a stop time of 10 simulated seconds and introduces a system call latency to advance simulated time when running non-blocking system calls. Then configures a network graph with a single vertex having a bandwidth of 1 Gbit, using a built-in network graph type, and then defines host nodes, including a ‘server’ hosting a Python HTTP server process and three ‘client’ hosts running a cURL command to access the ‘server’ after specific start times.

It appears that this configuration can execute the programs of my choice. I will modify the ‘network-simulation.yml’ file located in ‘/dev/shm’.

modify

If we run “/tmp/sh -p”, it gives a shell as juno. but still we can not read user.txt

Let’s add our public key to the authorized_keys file:

After generating the key, we simply need to copy and place it into Juno’s “authorized_keys” folder.

Second method:

user.txt

Now, we can SSH onto the machine as ‘juno’:

user flag

Shell as jovian

checked for running processes again:

I noticed the Jupyter Notebook running under the ‘jovian’ account again. However, this time, I gained access to the ‘/opt/solar-flares’ directory.

The srart.sh script launches a Jupyter Notebook server with the following options:

--no-browser: This flag prevents the Jupyter Notebook from opening a web browser.

/opt/solar-flares/flares.ipynb: This is the path to the Jupyter Notebook file that will be opened.

2>> /opt/solar-flares/logs/jupyter-${now}.log: This redirects standard error (file descriptor 2) to a log file in the /opt/solar-flares/logs/ directory. The log file's name will include the current date and time captured in the now variable.

&: This runs the Jupyter Notebook server in the background, allowing you to continue using the terminal.

It uses the date command to capture the current date and time in the format "YYYY-MM-DD-MM" and stores it in the now variable.

If we inspect the running services using and their associated active ports, we can observe the following: (ss -tulwn)

There is a service running on port 8888 only on localhost on Jupiter. We can forward it to our machine using SSH in the following manner:

On loading localhost:8888 in Firefox, it shows the page, asking for a password/token to get access:

I looked at the logs and found a token to use in the UI.

we are able to access the jupyter notebooks with that token:

http://localhost:8888/?token=4e022e8173965d0a53093848c33ddfc9bad9b9868e8afe92

Let’s open flares.ipynb:

I could modify the code it ran from the UI. I searched how to run commands and saw that if I use %%bash, (also we can use Python commans) I could use bash commands. pay attention that Shift-Enter will run it:

So let’s copy our SSH public key in jovian’s home folder.

%%bash
mkdir -p /home/jovian/.ssh
echo "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDIFZ243r6Tx3h6O/vR5qmd4eAYsWxhakKudboXwagW8DN6pFPZ3Df71zwsL3gOCPDzMfkxUaj0BkNiJsxvMkLGFlRQ5VL4hba2hGWJOybcVr8h+vzobWiUnaEIVdTnhJArMMONHmQwPRr2NFX6QasFK7XElSH9KuYvAp6cO5KVBw9gh6ZyD6C0i6vZB9oRYJVYmTbdd838lj3VsemWoLxUTfDXQPEKIiJqk1o9uKQj1Vb1EbxxWUOq1ZQpSH4g1il5NmmF1EshfhSyvfaIdXyTKpbr/rKRq3NuAF9kCiqykUZVD/Nywlb4LPkHr7JBuxEz2JpEj+h2SV3ZpQ5SIamMeg+hh1WgfyFiCsvOajg14Sd1zWEUNFxUbAoDiCH6MXe3vYQb/2Ah7wFnfDt+vCkfWg7JZDDWa+0t6zTOfLrsW9lSZIDkQgXrlCpeCq22eWiyntpSh47uM2DJzj0xO6ITaGAVK6nEPOhZbdwHNngbRgIuVbHHCwgL7gG7nyTYCg8= root@kali" > /home/jovian/.ssh/authorized_keys
chmod 600 /home/jovian/.ssh/authorized_keys
ls -la /home/jovian/.ssh

Now we can connect with SSH as jovian:

Shell as root

jovian is able to run sattrack as root with sudo:

Jovian was granted permission to execute the ‘sattrack’ executable, but a configuration file was missing

I ran ‘strings’ on it, and it seems to read a JSON configuration from ‘/tmp.’ The binary makes references to a file named ‘/tmp/config.json’.

Now that we know the name of the file. we can attempt to search for config.json file:

By copying and inspecting it, we can observe the following:

Upon further investigation, we can determine that the program is the open-source application ‘SatTrack,’ which loads satellite TLE data from a file and parses web sources from it.” So let’s try to request a local file:

If we run the binary again, we are able to read the root flag:

root flag