Loaded Commerce Community

Hi there,
Over the last 2 weeks there has been unsolicited spam mail being sent to all my customers on my website which appears to originate from our website.

The emails come from sales or support etc @(mywebsite).com.au.

We have tried to disable all our customers from our newsletter subscription, but this didn't work, so we have now altered all the email addresses in our website, but this is only a temporary fix as the customers won't be able to log in to the website without an accurate email address.

We are currently on v6.2 [13.2(sp1)] - I haven't updated the site since we got it going a couple of years ago as I'm too scared to break anything.

Any advice on how to stop the spam mail originating from our site would be appreciated!

Danielle

You need to look at your exim mail logs and apache logs to determine how they did it and then fix the problem.

I just patched a dozen osC sites for the same problem last week.

There is an update for CRE 6.2 that is later than the version you're running so you might look there for a fix.

Best regards,

Jody

Hi Jody,
Thanks for your reply - are those logs in Cre admin section or on Cpanel. Not sure I'd really know what to do with the info once I found it though...

With regards to updates- I think I see 2 after my version - CRE Loaded 6.2 Standard patch 13.2 (SP1) (White Label) and CRE Loaded 6.2 Standard Patch 14 - is that correct?

Cheers,
Danielle

Yes I believe there are 2 and viewed the patch 14 and it's for the PHPSELF exploit which is exactly the same problem I saw last week with the osC sites. You probably only need to install that one to settle the sendmail problem. I haven't looked at the files but for osC it was just changing a few lines of code in application_top file. I'm sure CRE is similar.

The log files would be from Cpanel (apache log) but I doubt you have access to exim logs unless you have your own dedicated server. The apache log will tell you what they typed to gain access to your site and send mail. Sometimes helpful in closing security holes. You'd need to know when the mails sent to narrow down the line. The apache logs can become quite long.

Trying installing patch 14 and see if it fixes the problem. From what I saw last week the hacker will return once a day to resend another message. Make sure you have an email account you monitor in your customer list so you can see exactly when an email bomb occurs (you'll get the message also).

Actually surprised to see this PHPSELF exploit with CRE - I guess I better get to patching more sites

Best regards,

Jody

I just found some time to download patch 14 and it doesn't have the patch to stop the exploit.

You need to download the security fix from another page

http://www.creloaded.com/fdm_folder_fil ... fPath=0_69

I hope I caught you before you started that update. It's a mess for a modified site.

Best regards,

Jody

Or just modify your application_top.php files in admin\includes and catalog\includes

For 6.15 and 6.2 sites, find line:
$PHP_SELF = (isset($HTTP_SERVER_VARS['PHP_SELF']) ?
$HTTP_SERVER_VARS['PHP_SELF'] : $HTTP_SERVER_VARS['SCRIPT_NAME']);

Replace with:
$PHP_SELF = $HTTP_SERVER_VARS['SCRIPT_NAME'];

The instructions are wrong BTW, you have to remove a bracket ). My version is correct and I've tested the fix with a known exploit URL for sending mail and this fixes the site. A former developer says to replace all instances but I haven't had time to track them all down. I'm sure someone will find the other holes soon enough and more instructions will come.

Thank you Jody!

This problem just cropped up December 2009 for the last week or so, and to make it easier for others to find this thread:
Email addresses from customer list being used for spam, actually being used to send spam to our customer list.

I downloaded the official patch and there is a syntax error which will break your admin login if you use it as supplied in the file entitled README SECURITY FIX FOR CRE.txt. This should be fixed by Cre Loaded, on the code change recommendation for both 6.15, 6.2 and 6.3, 6.4, remove the second to last character ")".

The patch files looked fine, it is just the customized application_top.php advice that is incorrect.

Jody's advice above has the right syntax.

Question: If the PHP_SELF exploit is used to send email to the store's customer list, does that also allow access to the admin backend?

Since the patch also includes \includes\modules\payment\paypal\application_top.inc.php, you can replace line 46 manually with the exact same code replacement, or replace the entire file with the patch if you haven't modified that file previously.

Danielle, the offending log entry I found was in the raw server log downloaded from Cpanel:
173.9.234.93 - - [27/Dec/2009:12:07:05 -0800] "POST /admin/mail.php/login.php?action=send_email_to_user HTTP/1.1" 302 - "-" "-"

This IP was sitting all by itself, as opposed to other benign entries for other IPs which request several page items such as images. The one above didn't come and revisit the page, they just made a single request.

If this is what I think it is, then look for action=send_email_to_user, that's what I'll be looking for.

Same thing we saw last week with osC sites.

Once you fix this you'll see the url won't work any more.

I can't confirm they have access to full admin but I have found 3 sites so far that have accessed banner_manager.php and created banners on the sites with links to a php file that didn't upload and the .htaccess file in images folder. Check your marketing area in Admin and make sure no mysterious banners have been created. 3 of our sites were hit 12/11/09. I tried to access the logs to find the url they used to exploit the banner_manager but I had the domlogs set to rotate out every 24 hrs. I fixed it to rotate only once a month so if they return I'll see the urls they used to gain access.

Best of luck,

Jody

Take that back - one site the php file did upload. Look for q_boot.php in your images folder and a modified .htaccess file in the same images folder.

Another note - some users report fly.php in the root of hacked sites. This isn't from banner_manager access but rather admin_files access. I haven't seen it yet but I have another 30 sites to patch. It's becoming very obvious that starting Dec 09 a malicious attack is on osC and CRE sites. Threads are popping up everywhere with multiple admin files being accessed by this PHPSELF exploit. Even if you think nothing is wrong with your site, I'd suggest you look in your logs and folders for strange php files. Most of the hacked sites I'm fixing haven't had any signs of mass emails or failure, but they've definately been hacked.

Thank you so much for the info!

Jody I'll edit the application_top.php files as advised and see if that helps. We had another spam mail go out this morning, but thankfully our temporary 'fix' stopped them from going out to our customers.

I asked our web hosting support about it and they were telling me it was spoof mail and if I enabled SPF
records in Cpanel that this would stop it - unfortunately it did not...

Where do I look for "action=send_email_to_user" - is that in log files on cpanel or within the site files itself?

Danielle

It will be in Cpanel access logs. To test your site you put your domain url in front of the link.

Really no reason to search for it because if you're still sending mail then you're not secure. Just fix the application top file and test. Depending on the size of your customer list, even 2 bulk mail sends can put you on blacklists (RBL) because of the speed your server is sending all those emails.

The spf thing won't do anything to prevent this sort of problem. It's just a verification process that major ISPs look for to authenticate the email came from your server. Obviously it is coming form your server so if nothing else you improved deliverability of the spam message to your customers.

Also check your banner manager for new banners (Admin >> Marketing >> Banner Manager). If you have banners in there that you didn't add then you need to look at your images folder for php files. Also look in the root for fly.php file. If they accessed your site through other files then they most likely uploaded files so they can run scripts remotely from your server.

I worked all night on sites and found the majority had some sort of problem and many multiple problems.

Best regards,

Jody

You're right Jody, I found 2 new banners added called 'Google'.
One added something under images q_boot.php and the other .htaccess

What a nightmare...

Great work Jody!

Will save store owners who are not patched up.. a lot of time

Just a brief followup. I scanned our Apache server logs for 3 servers and found almost 70 attempts in the last 2 days. I won't post all the scripts they used (don't want to encourage others to follow) but they are indeed using mail.php, banner_manager.php and file_manager.php (CRE uses admin_files.php so last one applies to osC sites).

If you have access to Cpanel I'd advise blocking these IP addresses. I added them as blocks to all my servers.

Block following
173.9.234.93
66.96.128.62
85.12.18.61
188.165.65.173
75.101.218.47
85.133.206.110
207.115.80.2
70.164.70.82
213.91.132.84

All of those IPs are in our Apache logs with multiple hack attempts using various scripts. I'm sure they have a million IPs to chose from but I know for sure that 3 of those are listed on many threads including this one from another member. If you change the last digits to 0/24 you can block the whole class from that IP string

173.9.237.0/24 would block any IP from 173.9.237.*

That is how we add them to our server firewall. We consider the whole class tainted. I'm also reporting 173.9.234.93 to Comcast for abuse. I'm sure they'll address this issue quickly with logs in hand.

Best regards,

Jody

On our servers.. we had luckily only found the images/q_boot.php on 2 accounts
found fly.php in one root.. which did not have the above

I couldn't find the php files in the image folders - guess that's a good thing. So I just deleted the banners that had been created.

I also changed the application_top.php files but the test link still seems to work, ie "POST /admin/mail.php/login.php?action=send_email_to_user HTTP/1.1" 302 - "-" "-"

With regards to blocking the IP addresses in Cpanel - is that done in IP deny manager? Just wanted to make sure I was doing it right.

Cheers,
Danielle