Introduction
While monitoring a public Discord server, we came across a claim about an “unsecured government satellite” listed on Censys. That led us to a web application tied to a NOAA polar orbit ingestion system, where a simple issue quickly turned into command execution on a government-connected system.
This post walks through how we found it, how the vulnerability worked, and how we approached disclosure once we confirmed the impact.
Why this mattered
- The system was already being discussed publicly
- The issue exposed a path to command execution
- A niche operational system still carried real security risk
Sometimes the most interesting research opportunities find you, not the other way around. Once we saw the associated web application, its age and design immediately stood out. That was enough to make us take a closer look at something that could have caused real damage in the wrong hands.
Before going further, it is worth clarifying how we approached this. We did not have explicit written permission to test the system, so we moved carefully, kept impact to an absolute minimum, and focused on understanding exposure well enough to disclose it responsibly. The system was already being discussed publicly, and the relevant government body appeared to accept security reports, so our goal was to establish risk without causing disruption.
Initial Reconnaissance
Our review of the web application did not immediately reveal a critical security flaw. Instead, it raised a more fundamental question: how was this data being displayed, and what process was running in the background to fetch these underlying system details? While information disclosure was not the main vulnerability, it was our first major clue. It signaled that the application was interacting with the server in a way that it should not be, which pointed us toward a deeper issue.
Discovery
Our curiosity about the application’s backend paid off quickly. We began systematically testing the application’s parameters, and it was not long before we found something promising: an f parameter. Our initial tests showed that it allowed us to include local files from the web server.
What made this particularly interesting was the real-time nature of the data. We noticed that the file associated with this parameter was constantly updating. This suggested the application was not just reading static files but was actively pulling in dynamic data, likely from a system process on the server itself.
We quickly determined that the backend was running PHP on an Apache server. Our next step was to figure out how this specific function was implemented. We considered a few possibilities. One common method is using PHP’s file_get_contents() function to grab user input and display it. That can lead to vulnerabilities like path traversal or server-side request forgery (SSRF).
Another possibility was the include() function, which, when combined with user input, can lead to local file inclusion (LFI) and, in some cases, remote code execution (RCE) through techniques like log poisoning.
However, a much more direct and dangerous method involves system call functions like exec(), system(), or shell_exec(). These functions run commands directly on the server’s operating system. Our tests confirmed that by injecting shell metacharacters like a semicolon (;) or double ampersands (&&), we could break out of the intended command and execute our own.
We had successfully achieved command injection.
Responsible Disclosure
Upon gaining our initial foothold, our focus shifted from exploitation to responsible disclosure. Our goal was not to cause harm, but to demonstrate the severity of the vulnerability and ensure the system was secured before a malicious actor could abuse it.
We immediately compiled a detailed report of our findings, including a step-by-step breakdown of how we achieved command injection, the potential impact on the system, and recommendations for a proper patch.
Our initial contact with the relevant government body was made on October 28th, 2022, at 11:23 AM. We received a prompt and professional response on November 24th, 2022. The agency took the findings seriously and later confirmed that the issue had been patched.
Conclusion: From Discovery to the BSides Cymru Stage
This experience was a good reminder of the value of proactive security work and a functioning disclosure process. What started as a claim in a public forum turned into a real case study in how small clues can lead to meaningful findings.
Kudos to @0SPwn (James W.) and @xorjosh (Josh Allman).
We were later able to present this research at BSides Cymru 2023, which gave us the chance to walk through the discovery, disclosure, and the broader lesson: niche systems still deserve serious security scrutiny.