CVE-2023-47311: More XSS and Clickjacking in Yamcs v5.8.6

Written by: Andy Olchawa, Milenko Starcik

Vulnerabilities in critical systems like Yamcs can have far-reaching consequences. In this article, we’ll get straight to the point and delve into some technical details about security concerns we’ve unearthed: Stored Cross-Site Scripting (XSS) in ScriptViewer and Archive Browser and Clickjacking in Yamcs version 5.8.6. We’ll explore the technical aspects of these vulnerabilities and provide practical recommendations to bolster the security of your Yamcs deployment.

Three CVEs have been assigned and are discussed in this article:

• Stored XSS in the Script Viewer: CVE-2023-46471

• Stored XSS in the Archive Browser: CVE-2023-46470

• Clickjacking: CVE-2023-47311

Make sure to check the five vulnerabilities already discussed in our previous article.

Stored XSS in the ScriptViewer

The ScriptViewer component of Yamcs is vulnerable to stored XSS. The vulnerability can be triggered by loading a malicious script or by saving and reloading the script.

Figure 1 Location in the code of ScriptViewer that is vulnerable to XSS.

Figure 1 shows the location in the code that is vulnerable to XSS. The text variable (script content) is not sanitised for HTML tags. This makes it possible to embed a malicious JavaScript code in the script file, which, instead of displaying the snippet, the browser will execute it.

To demonstrate this, let’s create a script file that contains an image which triggers an arbitrary JavaScript code, as shown in Figure 2.

Figure 2 Example of the script containing malicious code.

Once we load the file to Yamcs and navigate to it, we’ll see that the code, instead of being shown, is executed by the browser, as can be observed in the figure below.

Figure 3 XSS being triggered.

Note that the malicious is not visible in the editor, which means that the user has no way of knowing that the malicious code is being executed on their browser.

This vulnerability is challenging to detect if the loaded script contains an extended, legit JavaScript code.

Theoretically, the user could review the script code before loading it to the ScriptViewer. However, it might be easy to trick the user’s eyes as the malicious part of the code can be disguised as a comment describing the valid JavaScript code and, therefore, harmless at first glance.

Figure 4 shows how the attack described above could be achieved. This becomes even more difficult to detect when the script is loaded to the ScriptViewer, as the malicious code will no longer be visible. Figure 5 demonstrates how the malicious code triggers the XSS, yet it is hidden once the script is loaded.

Figure 4 Embedding malicious JavaScript code in a valid script.

Figure 5 Loaded script that triggered the XSS.

We recommend that the script content should be sanitised, removing the HTML tags.

Stored XSS in the Archive Browser

The Yamcs Archive Browser is vulnerable to XSS when displaying the Telecommands uplinked to the spacecraft (in our case, a spacecraft simulator). The exact location in the code that triggers this vulnerability is shown in Figure 6.

Figure 6 Location in the code that triggers the XSS.

To exploit this vulnerability, it is possible to create (or modify an existing) Telecommand, setting its name to a malicious JavaScript payload. The mission database containing the telemetry and telecommanding definitions is stored in an Excel spreadsheet, which Yamcs reads.

Figure 7 Telecommand definition containing a malicious code in its name.

Figure 7 shows a malicious JavaScript code appended to the end of the name of a Telecommand. This Telecommand can then be loaded on Yamcs and released to a spacecraft or simulator it connects to, as demonstrated in Figure 8 and Figure 9.

Figure 8 Sending a Telecommand to spacecraft.

Figure 9 Successful release of the Telecommand.

The figures above show that the Telecommand name is displayed in many places when navigating through Yamcs, and it seems to be correctly sanitised – i.e., the command name is properly displayed, and the browser doesn’t execute the malicious code.

However, this Telecommand can also be displayed on the Archive Browser as a timeline. The Archive Browser content is drawn on a JavaScript canvas, so it shouldn’t trigger the execution of malicious code. However, the timeline component also implements a Tooltip functionality, which loads the HTML and executes JavaScript.

To trigger this XSS vulnerability, after the Telecommand is released, the user can navigate to the Archive Browser, zoom in on the timeline to review the Telecommands and hover the mouse cursor over one of the Telecommands containing the malicious JavaScript. This will display the mentioned Tooltip, which will trigger the XSS. This scenario can be observed in Figure 10.

Figure 10 Triggered XSS from the Archive Browser.

Recommendation:

To mitigate this vulnerability, the mission database values should be sanitised at the load time and before they are displayed.

Clickjacking

Yamcs 5.8.6 is vulnerable to Clickjacking. This means that an attacker can create a website that would encourage the user to perform specific actions (e.g., click on a button), thinking that they interact with an unrelated website, while instead, they would be unknowingly performing activities on Yamcs. This type of vulnerability can have an exceptionally high impact on control systems, such as Yamcs.

To demonstrate the impact of this vulnerability on Yamcs, we have prepared a scenario where a user can unknowingly send Telecommands to the spacecraft by interacting with a supposedly unrelated website. First, let’s create an example HTML page containing only a label component that encourages users to click on it (see Figure 11).

Figure 11 Clickjacking HTML

The HTML code above will create a hidden iframe that loads the Yamcs website and a simple div tag on top of it. We will then host it on our local machine (see Figure 12), and once the user loads it, it will look like a regular blank page with one label on it (see Figure 13).

Figure 12 Hosting a clickjacking page.

Figure 13 Loading a clickjacking page.

For the sake of demonstration, we will increase the opacity of the iframe to see what is happening under the seemingly blank page (see Figure 14).

Figure 14 Increased opacity of the iframe.

Once the page is refreshed, we should see the content of the Yamcs page below (see Figure 15).

One of the Yamcs functionalities is to release a Command Stack (a file containing a list of Telecommands) to the Spacecraft or a simulator. Figure 16 shows the content of the Command Stack that we have used for this demo.

Figure 15 Clickjacking page with higher opacity.

Figure 16 Command Stack used for the demo.

The content of the Command Stack doesn’t matter, but it’s important to note the Telecommand names, as we will compare them later to the archive’s content. Figure 17 shows an Archive Browser that is currently empty, i.e., it doesn’t contain any spacecraft Telecommands. As we saw in Figure 15, the “Click me” label overlays the “Run All” button. Once the user clicks the label, we should see how all Telecommands from the Command Stack are being released (see Figure 34).

Figure 17 Archive Browser with no Telecommands.

Figure 18 Telecommands being released.

To verify that the Telecommands were sent, we can navigate to the Archive Browser and observe the new entries showing the released Telecommands (see Figure 19).

Figure 19 Archive Browser containing the release of Telecommands.

We recommend implementing the Clickjacking defences by the OWASP.

Further readings

We have published a series of articles about our vulnerability assessment of NASAs Open MCT software. Make sure to read the first article about prototype pollution and the second on XSS. We cover more general space related topics on our blog.