CVE-2023-45885: XSS in NASAs Open MCT v3.1.0

Written by: Andy Olchawa, Milenko Starcik

We continued our review of NASA’s Open MCT software (v3.1.0) and discovered a stored Cross-Site Scripting (XSS) vulnerability. Its impact can be significant since the examined version lacks CSP flags and CSRF protection.

Two new CVEs have been assigned and are discussed in this report:

- XSS: CVE-2023-45885

- CSRF: CVE-2023-45884

Stored XSS

The flexibleLayout plugin of Open MCT is vulnerable to an XSS. Depending on the system’s configuration (i.e., whether the persistence is enabled), the vulnerability is either Stored Client XSS or Stored Server XSS. The vulnerability is currently in the frame.vue:162, see Figure 1.

Figure 1: XSS vulnerability is shown in the code of flexibleLayout.

As the screenshot above shows, the domainObject.name is assigned to another component’s innerHTML property. Given that the domainObject.name is controlled by the user input (i.e., it is set by the user by creating a widget or component), exploiting this functionality to trigger a Cross-Side Scripting vulnerability is possible. The affected component (element id: js-fl-drag-ghost) is dynamically updated when the flexibleLayout component is in edit mode, and the user drags its element between the columns.

Steps to reproduce:

a) Create a flexibleLayout

Figure 2: flexibleLayout contains a couple of columns.

b) Create a new component and inject the XSS payload.

In our case, we create a new clock within the flexibleLayout and set its Title to a simple XSS payload (as shown in Figure 3):

XSS Payload:

Figure 3: Creation of a new Clock and set its Title to an XSS payload.

c) Edit the flexibleLayout

Figure 4 shows the flexibleLayout in edit mode with one component included (the previously created clock).

Figure 4: flexibleLayout in edit mode.

d) Drag and drop the clock component between the columns.

Drag-and-drop action will trigger the XSS, as shown in Figure 5.

Figure 5: Trigged XSS.

Recommendations:

Consider using a sanitisation method, such as the one already used in the Notebook plugin (NotebookEntry.vue:246).

Missing CSP

Open MCT doesn’t set the CSP, leading to much more severe exploitation of XSS vulnerabilities. To demonstrate this, we’ve used the earlier described XSS vulnerability to call the attacker’s server, fetch a malicious JavaScript code and execute it on the user’s Web Browser.

Steps to reproduce:

a) Create a remote payload XSS payload. This code will be hosted on an attacker’s server:

b) Create the XSS payload that exploits the lack of CSP.

An on-error event triggers this code if the browser fails to load an image from the specified source. It then creates an HTML script tag, loads the script from the source (hosted on the attacker’s server), and appends it to the DOM.

c) Create a new clock and set its title to the XSS payload, as shown in Figure 6.

Figure 6: New Clock with XSS payload set as its Title.

d) Edit the flexibleLayout and drag and drop the clock component.

Figure 7: Triggered XSS.

The console log presented in Figure 7 shows how the XSS payload first fetches from the attacker’s server and then executes the malicious payload.

Figure 8: Python HTTP server hosting the malicious payload.

Figure 8 displays the incoming connection from the Open MCT to retrieve the malicious JavaScript file. We recommend including CSP based on the OWASP cheat sheet.

CSRF

Open MCT doesn’t have any protection against CSRF. Combined with XSS and the lack of CSP described earlier, it creates more opportunities for system exploitation. Below, we demonstrate how chaining these vulnerabilities can lead to a CSRF, such as calling the backend database.

Steps to reproduce:

a) Create a CSRF Remote Payload.

The payload above will call the backend database, which will then be followed by another call to the attacker’s server to exfiltrate the returned data.

b) Create CSRF Payload and set it as Title in the Clock component.

As before, the CSRF payload will call the attacker’s server to retrieve and execute a malicious JavaScript file.

c) Edit the flexibleLayout and drag and drop the component.

Figure 9: Triggered XSS

As shown in Figure 9, once the XSS is triggered, the browser fetches and executes the malicious script. The script calls the database to retrieve all entries and sends it back to the attacker’s server.

This can be observed on the attacker’s console hosting the malicious script, as shown in Figure 10.

Figure 10: Exfiltrated data shown on the attacker’s console.

Further, decoding the exfiltrated data (URL-encoded to avoid any transmission issues) can be seen as the actual content of the database (see Figure 11).

Figure 11: Decoded data exfiltrated from the database.

We recommended implementing the CSP to minimise the flexibility of the payload that can be executed and to consider implementing the CSRF countermeasures recommended by OWASP.

Further readings

Our previous report on a Prototype Pollution vulnerability in Open MCT is here. If you like this work, check our review of YAMCS or pass by our blog, where we have more space-related content.