cPanel 10.9.x - local users could overwrite any file on the box via a symlink attack in /etc/cron.hourly/modsecparse.pl



DESCRIPTION


modsecparse.pl is a utility that comes with the cPanel mod_security addon. Its purpose is to place the modsec logs from /usr/local/apache/logs/audit_log into the /var/lib/mysql/modsec database, then truncate the audit_log. It runs from cron, via /etc/cron.hourly. On older cPanel builds it copied the audit_log to /tmp via the system command 'cp -f'.

Below were the relevant lines of code from modsecparse.pl which illustrate this:


22 $audit_log = "/usr/local/apache/logs/audit_log";
23 $tmpfile ="/tmp/audit_log";

29 system("cp","-f","$audit_log","$tmpfile");

83 system("rm","-f","${tmpfile}");



IMPACT


Every hour local users could destroy any file on the machine by overwriting it, or create a new file anywhere on the filesystem as root via a symlink attack:

[user@host ~]$ ln -s /root/newfile /tmp/audit_log


Since the contents of the audit_log are partially controllable from remote by sending requests to the webserver that mod_security would generate logs for, other attacks may have been possible. The problem I ran into is that modsec always added certain characters (I don't recall which) to the beginning of every line of its log. This may or may not have prevented someone from getting root via crafted log entries. I suspect a nice local root was possible.

27 Oct 2017 - Overwriting /root/.accesshash with user-controllable content is a local root. If the modsec audit_log hadn't been written to yet, a remote user could've issued a request to Apache that caused modsec to block the request, thus writing known content to the audit_log. modsec comes with default rules, so triggering a rule would've been trivial. Therefore, this was possibly a local root, no auth required.