CVE-2023-45281: Yamcs v5.8.6 Vulnerability Assessment

Written by: Andy Olchawa , Milenko Starcik

Yet Another Mission Control System (Yamcs v5.8.6) is an open-source software framework for the command and control of spacecraft, satellites, payloads, ground stations and ground equipment developed by Space Applications Services.

Given that the software provides a wide range of monitoring and control capabilities and is used/supported by many public and private organisations (such as NASA, DLR, AIRBUS and Astrobotic), VisionSpace Technologies decided to perform a vulnerability assessment of the system and verify the overall security posture. The evaluation resulted in several security flaws, all of which have been reported to the software vendor as part of our responsible disclosure approach. The Yamcs team has fixed the reported vulnerabilities.

Selected vulnerabilities that have received CVE IDs for tracking purposes have been included in this report:

- Directory Traversal (1) - CVE-2023-45277

- Directory Traversal (2) - CVE-2023-45278

- Stored XSS (1) - CVE-2023-45279

- Stored XSS (2) - CVE-2023-45280

- Insecure Handling of Session Cookie - CVE-2023-45281

Yamcs Vulnerability Report****Directory Traversal (1)

Yamcs is vulnerable to directory traversal. The vulnerability is in the storage functionality of the API and allows it to escape the base directory of the buckets, freely navigate the system directories, and read arbitrary files.

The affected API endpoint is:

For instance:

To exploit this vulnerability, an adversary can make a GET request to the endpoint above and reference any file on the system, as shown in Figure 1.

Figure 1: Directory Traversal PoC - read /etc/passwd file.

This vulnerability can further lead to disclosure of user credentials. It is necessary to find where the current system instance is located to achieve that. However, the discovery of the base storage directory is relatively simple and can be achieved by making a GET request to the above endpoint, as depicted in Figure 2.

Figure 2: Base storage directory path disclosure.

Equipped with this information, requesting a GET to read the unencrypted users is now possible. The yaml file containing user credentials is shown in Figure 3.

Figure 3: Sensitive Information Disclosure.

Directory Traversal (2)

Using the same endpoint described in the previous section, it is possible to use the HTTP DELETE method to delete an arbitrary file on the server file system.

Figure 4 shows an HTTP DELETE request being made to a file located on the server file system, which results in a 200 OK response, effectively demonstrating an arbitrary file deletion.

Figure 4: Arbitrary File Deletion.

Recommendations

The most important recommendation for both directory traversal vulnerabilities is to update the server configuration to prevent it. This is already achieved in the POST request using the getCanonicalPath() Java method on the Path object, effectively removing the dots from the path.

Additionally, it is recommended to functionally split the role of ControlArchiving into at least two separate parts, one that allows one to read the archive and a separate one to control it. This is to mitigate the impact on the system in case new Directory Traversal vulnerabilities are discovered.

Stored XXS (1)

Yamcs comes with a Bucket as its primary storage mechanism. Buckets allow for the upload of any file. This, in principle, is not an issue. However, we’ve discovered a way to upload an HTML file containing an arbitrary JavaScript and then navigate to it. Once the user opens the file, the browser will execute the arbitrary JavaScript. To demonstrate this, we’ve created a simple HTML file containing <script> tags with some JavaScript code, as shown in Figure 5.

Figure 5: Simple HTML File with Arbitrary JavaScript code.

Once the file is uploaded to a bucket, it is possible to navigate to it and open it via Web Browser, as demonstrated in Figure 6.

Figure 6: XSS Execution.

Recommendations

To prevent this, ideally, the user should not be able to navigate to the file containing an arbitrary JavaScript code and execute it. Currently, the Yamcs system prevents the code execution for all file types except HTML.

Stored XSS (2)

Similarly to the previous example, uploading a display referencing a malicious JavaScript file to the bucket is possible. The user can then open the uploaded display by selecting Telemetry from the menu and navigating to the display.

To demonstrate this, we have crafted a simple JavaScript file (see Figure 7) and uploaded it to a test bucket (see Figure 8).

Figure 7: JavaScript executed via XSS.

Figure 8: Location of the xss.js script file.

The next step was to download an existing Display file and create a reference to the malicious JavaScript file we uploaded earlier. For this purpose, we decided to use the main.opi file since it contained only a small number of UI components we could easily modify. We then added a reference to our script to one of the widgets (see Figure 9) and uploaded the file to the Displays bucket under the location where other displays are (see Figure 10).

Figure 9: Updated main.opi display containing the reference to the malicious JavaScript file.

Figure 10: Location of the malicious display file.

Once both files are in place, the user can access and execute the new Display from the Telemetry Displays menu, as shown in Figure 11.

Figure 11: XSS via Display.

Recommendations

It is understood that JavaScript execution is one of the main features of Yamcs. However, the code is not filtered in displays and is left for execution in the broad context. It is recommended to restrict the JavaScript execution context as it is done for the JavaScript in other parts of the Yamcs system, e.g., Algorithms.

Session Cookie with Missing Flags

To exfiltrate sensitive information, the attacker can exploit the XSS vulnerabilities described in previous sections. This is possible by crafting a malicious JavaScript code that extracts the session cookies and sends them to the attacker’s system.

We used the XSS vulnerability via a malicious HTML file to demonstrate this exploitation technique. First, we have crafted a malicious HTML file that, upon execution, steals the session cookies and sends them back to the attacker (see Figure 12).

Figure 12: XSS used to exfiltrate session cookies.

Figure 13 shows the content of the script itself.

Figure 13: JavaScript code to exfiltrate the session cookies.

The exfiltrated sensitive data are URL-encoded, and once decoded, the attacker has both the access_token and refresh_token cookies, as shown in the listing below:

Recommendations

In this case, the attacker can use the existing XSS vulnerabilities to exfiltrate the sensitive data since the session cookies are not set with the proper cookie flags. This can be observed in Figure 14.

Figure 14: Missing cookie flags.

Want to know more?

To learn more about our Security Research, check our Article: Prototype Pollution in NASAs Open MCT CVE-2023-45282

References

Yamcs Website

Yamcs GitHub Page

Fixes for Reported Vulnerabilities

CVE-2023-45277

CVE-2023-45278

CVE-2023-45279

CVE-2023-45280

CVE-2023-45281