CODEWITHSUNDEEP
phpmagento
user2268642
user2268642

Reputation:

Magento Fatal error: Class' Varien_Data_Collection_Filesystem' not found

Checking the cause of the error, the Filesystem.php file is is renamed to Filesystem.php.suspected. Manually renaming it back to Filesystem.php fixes the issue but everyday we need to manually rename it since it is constantly being renamed back to Filesystem.php.suspected.

I've googled as to what causes the error but still no luck. I am quite sure that there is something that is renaming this file but don't know where to start since i'm fairly new to magento.

Magento ver. 1.9.1.1

Upvotes: 3

Views: 1689

Answers (1)

FactoryAidan
FactoryAidan

Reputation: 2594

The Problem

Basically a hacker got their code on your server. You either installed it unknowingly or there is a loophole in your server security that let them upload (maybe even PHP's cgi.fix_pathinfo issue).

The .suspected file extension is a good thing because it disallows the malicious code from continuing to use/abuse it. Your server thankfully has a service running on it that detected this for you. So the problem is not Filesystem.php, rather, that file is being abused by some other malicious file... and you need to find that file - and probably file(s).

How to Fix it

First, let me say there is no 'quick' solution for this. If your heart is set on salvaging your server, this is the process. You will need SSH access to your server.

My server setup is Ubuntu 14.04LTS using nGinX Web-Server with Exim4 for email sending. If you are not using those same services, try Google for equivalent commands suitable your server environment.

Before we get started:

[Have to say it]: If you copy-paste any commands listed here, make sure to replace things like 'YOUR_USERNAME' with a value that makes sense for your server environment.

Other bad things likely going on: I found that the hackers had gotten executable code on my server which created a .php file to act as a url endpoint to receive HTTP POST requests. Those POST requests would trigger the hacker's script to use my Exim4 email server to send their emails. When checking my Exim4 email queue, there were 54,000 emails being sent per week.

Let's Begin

Check if they are abusing your server's email sending

I checked & cleared my Exim4 mail queue with these commands:

exim -bpc

exim -bp | exiqgrep -i | xargs exim -Mrm

Install Magento SUPEE security updates

The Magento SUPEE security patches are intended correct this remote executable file vulnerability. Install all the Magento SUPEE updates (oldest to youngest) on your server:

Go here to download them: https://www.magentocommerce.com/download

They are at the bottom of that page at 'Downloads' ->> 'Magento Community Edition Patches'

There is a select box for you to select the patches that pertain to your version of Magento.

You 'should' download all the ones that came out after your 1.9.1.0 was released (after Nov. 24, 2014):

  • SUPEE-4829
  • SUPEE-5344
  • SUPEE-5994
  • SUPEE-6237
  • SUPEE-6285
  • SUPEE-6482

Put all of those downloaded .sh patch files into your root Magento directory. Mine was:

/home/YOUR_USERNAME/www

Then execute them one at a time:

  • cd /home/YOUR_USERNAME/www
  • sh PATCH_SUPEE-4829_EE_1.14.1.0_v1-2015-02-10-07-57-21.sh
  • sh PATCH_SUPEE-5344_CE_1.8.0.0_v1-2015-02-10-08-10-38.sh
  • sh PATCH_SUPEE-5994_CE_1.6.0.0_v1-2015-05-15-04-34-46.sh
  • sh PATCH_SUPEE-6237_EE_1.14.2.0_v1-2015-06-18-05-24-23.sh
  • sh PATCH_SUPEE-6285_CE_1.9.1.1_v2-2015-07-08-08-07-43.sh
  • sh PATCH_SUPEE-6482_CE_1.9.2.0_v1-2015-08-03-06-51-10.sh

Find the malicious file(s)

There are likely tons of malicious files. I found a dozen of them and they continued to re-spawn as the days went on.

  • /home/YOUR_USERNAME/www/include.php
  • /home/YOUR_USERNAME/www/get.php
  • /home/YOUR_USERNAME/www/MY_OWN_NON-MAGENTO_FOLDER/class.php
  • /home/YOUR_USERNAME/www/media/system/system.php
  • /home/YOUR_USERNAME/www/media/system/mail.php
  • /home/YOUR_USERNAME/www/media/system/admin-infos.php
  • /home/YOUR_USERNAME/www/media/wysiwyg/MY_OWN_FOLDER/system37.php
  • /home/YOUR_USERNAME/www/media/captcha/admin/error44.php
  • /home/YOUR_USERNAME/www/entreeBam/entreeBam/*

There's a whole chain of events the hackers had to follow to get their files spread through your server like swiss-cheese.

Basically, they needed a starting point. For me that was '/home/YOUR_USERNAME/www/include.php'

To find files like that one, I ran this command:

egrep -RI 'function.*for.*strlen.*isset' /home/YOUR_USERNAME/www

I knew that the hacker's script was allowing a file upload and that all file uploads require the use of move_uploaded_file() in PHP. So this command showed most Magento's GOOD files, but it also showed me one bad file. That was 'class.php':

egrep -RI 'move_uploaded_file\(' /home/YOUR_USERNAME/www

So after removing those more obvious hacker access-points in the root directory and possibly other directories, you now have to see what other files you can find that are malicious.

Check your Web-Server Access Log for POST requests to strange files

Your server shouldn't be receiving very many POST requests (if any) at all. So the hackers are basically drawing you a perfect road map leading directly to which files you need to delete. All you need to do is check for 'which' .php files are receiving POST requests. Then delete them if their file content is suspicious to you.

Hint: The IP address sending the POST request to your server can also help you decide if the file is suspicious. If you don't recognize the IP address, it should not be making POST requests to you.

I'm using nGinX as my web-server so make sure your access.log is enabled in your /etc/nginx/nginx.conf file. When you know your nGinX access.log is populated. Use this command to show all POST requests in it:

egrep -RI 'POST' /var/log/nginx/access.log

I found post requests to:

  • /media/system/system.php (obviously shouldn't be in media folder)
  • /conns.php (some experience tells you this is not a Magento file)

After deleting the files, your access.log will start showing HTTP 404 responses (no longer HTTP 200) for each POST request. That is good. It means the hacker's attempts to run their scripts are not working. Eventually the hackers will stop making POST requests when they see you have deleted all of their recipient .php files.

To see files with 404 responses to POST requests in your access log:

egrep -RI "POST\s.*\.php(\s|&).*\s[4][0-9][0-9]\s" /var/log/nginx/access.log

To see files with 200 responses to POST requests in your access log:

egrep -RI "POST\s.*\.php(\s|&).*\s[2][0-9][0-9]\s" /var/log/nginx/access.log

Make sure there aren't any PHP files in your media folder with this command:

find /home/YOUR_USERNAME/www/media/* -name "*\.php"

Looking inside the files, I could see a bunch of base-64 encoded stuff. No legitimate PHP script would be made of that much base-64 encoded stuff.

After finding all the malicious files and removing them you can fix the one problem that was causing the error you saw that made you post this question.

Rename the Filesystem.php.suspected to what it is supposed to be:

mv /home/YOUR_USERNAME/www/lib/Varien/Data/Collection/Filesystem.php.suspected /home/YOUR_USERNAME/www/lib/Varien/Data/Collection/Filesystem.php

Summary

The most crucial things were:

First, finding and removing the original access point(s), 'include.php' and (corrupted) 'get.php'. So that the hackers could not continue placing files on my server.

Second, continuing to check my web-server access log for POST requests leading me to strange files. Then checking and deleting those files.

Lastly, it would help if you maintain recommended Magento File & Folder permissions and keep your server up-to-date with the most current SUPEE updates.

For entertainment, you can run this command to see how many files were shut-down by your server's anti-malware due to this abuse. Some of these are Malicious files - some are just good files that were abused.

find /home/YOUR_USERNAME/www/* -name "*\.php.suspected"

Upvotes: 6

Related Questions